Hardware security and healthcare

Today, readwrite brings some attention to the dangers of data without security in a growing market. According to the article, we’ve passed the inflection point in security incidents where malicious attacks now out-number the classic PEBCAK, with healthcare as the most-targeted industry. From the article:

[C]oncerns are increasing that current data management and security among both private and public organizations are woefully ill-prepared to defend private data from hackers increasingly targeting sensitive personal health information.

A good warning to be thoughtful about with whom you share your data. 

When IoT subscription service turns shady

The Internet of Things! It allows us to connect nearly every device in our lives in a meaningful and useful way, glean new insights from sensors, and utilize hardware as never before. What could go possibly wrong?

Today, Kit Walsh from the EFF provides that answer with a review of a disappointing update from Nest/Google. From the article:

"...[B]ricking the Hub sets a terrible precedent for a company with ambitions to sell self-driving cars, medical devices, and other high-end gadgets that may be essential to a person’s livelihood or physical safety."

This news is frustrating on many levels, but I will stay in my wheel house of hardware, data, and privacy.

• Hardware: once you purchase a device, it's your's and you own it. End of story. With this decision, Nest/Google effectively went into the homes of every lifetime member and poured water on their laptop. Sure, you could reclaim some parts, but your home isn't a chop shop and customers aren't scavengers.
• Data: certainly the people who purchased a Hub are interested in their data, but after the shutdown date, the data will be deleted.
• Privacy: getting back to the laptop analogy -- borrowing from Newton, every possession in your home remains in a state unless acted on by an outside force. Most customers probably wouldn't be happy about Nest/Google entering their homes.

So what recourse to consumers have in the emerging field of IoT? In general, you can count on me to be against compelling an entity to "do the right thing" through regulation or similar means. But  how can we react against behemoths like Alphabet at al when they make decisions against the interests of **paying** customer base? Again from the article:

"But there's another way to push back against untrustworthy devices, and that's refusing to buy electronics and software that prioritize the manufacturer's wishes above your own."

In the Internet of Things, who really owns hardware after purchased? Without a doubt, the customer. However, stripping people of their right to use their property as they choose and denying access to their data shows people in this case don't actually own said hardware and data -- they've subscribed to it! While subscription works fantastically well in some cases (Netflix, Spotify, etc), it's counter-intuitive and wrong for this use case in IoT. Something to keep in mind the next time you're building out your smart-home.

Hackathon insights: roles on teams

Recently, I had the opportunity to help with a hackathon. Over the course of three days, students would connect data end-to-end from hardware APIs, through a Hadoop backend, to a Hive Server end point for downstream analysis and viz in Tableau.  My role was designing the backend, introducing and instructing on the technology used (Linux and Hadoop), and troubleshooting with students during the process. There were six teams, comprised of five members with various combinations of hardware, data backend, and Tableau analysts.

One of the main things I noticed was how well everyone worked together. There were aspects of it that reminded me of teams I have enjoyed working on in the past and currently. Some common threads:

• Interested in team success.  Seems like a no-brainer, but probably everyone has been part of team where at least one person wasn't interested in the product. That sort of indifference doesn't necessarily lead to tension, but it can lead to an uninspired product or worse, the entire team slowly running off the rails. It can be hard to come back from that.
• Unique roles in the team. Even if your role has wide breadth (hardware wizard, dev ops guru, front end master), having a role in a team gives you an identity, ownership, and accountability. While it's possible to have more than one person within a role on a team, a larger role overlap comes with a greater risk from personality conflict.
• Sense of individual ownership. In general, if people feel like they own a part of the project or product, they feel invested and included.

Most interesting was observing the same themes that I experience in the past, this time outside looking in.