Ask HN: I’m an FCC Commissioner proposing regulation of IoT security updates

I care more about my privacy than I do about the security of my device, but an architecture that supports the second almost always supports the first (my neighbours hacking my zigbee isn’t a threat model almost anyone should be concerned about, unless there’s a pattern of hacking en masse).

I found out my smart lights literally have a microphone in them the other day, under the guise of ‘plays light to your music’ or something.

I architect my IOT by implementing a network without internet, fronted by home assistant - that way my devices can’t ‘phone home’ which who knows what privacy infringing crap.

I know that botnets driven by iot is a real and ongoing problem, but it’s a problem that is probably not going to get much vendor buyin without regulation, but what I’m pointing out is that it’s not the only threat facing these devices.

I want:

- clear guides on what data is collected, I don’t trust they’d only use it the way they say they will so I wouldn’t bother reading that part, if it existed

- the ability to opt out of any data collection aside from anything required to do technical updates. I want any data transfer to occur in a clear and auditable way (e.g the ability to inject a root CA and perform a mitm if I wish)

- enough protocol spec that at least basic functions can work offline via a system like home assistant

These won’t directly solve the ddos vectors, but they will solve the problems that come shortly after on the timeline.

Yes, we should. But alas, the incentives run the exact reverse today. Today they get to monitor your usage of the lights, resell the data, etc.

You are part of the product.

OTOH: If I look at this as a vendor, where else where the light switch go for updates?

I'd be VERY hesitant to direct wire any IOT device into my house, if I wasn't comfortable ripping it out in 6mo, when the company decides to desupport it and kill the app.

For me this is a the exact opposite problem: I won't adopt until I know that these issues are ironed out, or I accept that the device is 100% disposable.

There's cases where I can't avoid it, TVs, Cars, etc. It is pushed on me, like it or not. For those, I truly do want safe mode, so I can pick how it networks.

To me this generation is lost. I accept that. It is sad. I want to win the NEXT one, or the one after. And only by making the life cycle EXPLICIT will we do that.

When a customer goes into Home Depot and says "My lightswitch stopped working in 2 years, you got something that will live longer this time?" The problem is self solving.

For a labelling program for this type of company, you could require additional disclosure to consumers at the time of sale, along the lines of "We can't guarantee that we'll provide security updates." Or you could require open-sourcing of firmware if a company goes defunct. Or perhaps device manufacturers could be required to hand the technology of to some third party maintainer if they go under.

Any regulation at end-of-support-life has the "company disappears" problem, so probably disclosure at time of sale is the only thing that could be reliably enforced.

The issue with software OTOH, is that a security hole in one trivial component (e.g. resize images to make thumbnails) can often lead to a full system compromise. Even if you don't get full root, you can still use a compromised system to your advantage: steal personal data, use it in a botnet, serve malware, mine proof of waste, etc.

On top of that, adding a dependency is often made very easy by modern package managers, and as the number goes up it gets rather difficult even to vet your direct dependencies, let alone transitive. Installing brakes in a vehicle doesn't automatically pull in a kitchen sink, but in the software world it's widely accepted, almost inevitable. You can spend your time removing the 90% of that library that you don't need, and rewriting the remaining 10%, or you do the "reasonable" thing and just ship.