Main Site Documentation

TechnoCreep and IoT


#1

I’ve known Dr. Tom Keenan for sometime as he is/was a professor at the University of Calgary when I was there many years ago, but the other night I went to a presentation he put on for a local ITPro User group and it was rather good. A lot of the material he presented was from his book Technocreep which would be an good read for anyone interested in how technology is invading your privacy and frankly controlling you.

www.greystonebooks.com/book_deta···71641227

Now we talked about all sorts of things like data mining, tracking folks, Audio Spot Lights, Scent Cannons, facial recognition, drones, and all sorts of devices and data collection etc that all might sound somewhat legit (well some maybe not), but they all have another side which perhaps unintended is be used for perhaps not the best reasons. This stuff is all the stuff of IoT, for example all those cool fitness devices that people where that brag about their exercise accomplishments well you might be bragging about more then your exercise levels. Now granted Fitbit fixed this

but it is a great example of something that really wasn’t thought about when the device was first designed.

So when you design a device or IoT system, think about what your trying to measure and what you might inadvertently measure, or who else might see that data, or what else might be in your data, like that very energetic calorie burn session at 2:30 AM that ends up on twitter.


#2

This isn’t just an IoT thing. It’s also true for any software interfaces that are exposed to others, particularly for public-facing APIs.

Troy Hunt has a great set of videos on Pluralsight called Hack Your API First, in which he shows some of the dangers of bad API design, where an API returns everything for a given object, instead of just the minimal set of values necessary for a given call.

Much as I’m a fan of technologies like ASP.NET Web API, they make it really easy to over-share with many of the tutorials showing how to just grab everything from a SQL table using Entity Framework, and then just expose the whole entity on your API. That makes for easy development and demos, but also has the potential to reveal more than is ideal.

Defaults for sensor data, APIs, and PII should be to share as little as possible, and for anything personal, only with explicit permission/opt-in from the user.