Simple. Give the manufacturers the choice: either they must provide full (FLOSS) source code and documentation (full schematics) to the user to enable them to maintain, patch and thus secure their devices (see also: right to repair), OR they are liable for all damages (direct, indirect) for a 30 year expected lifetime that arise from security issues with the device AND must have insurance to cover those damages (so t…
30 years of expected support is pretty unreasonable. Stating a requirement like this makes the discussion about competing dogmas. Rather, it's about the right way to keep devices operational as long as possible while also allowing companies to remain possible. 30 years of support expectations immediately makes the cost of any device go up to hedge against the risk of fines during the entire 30 years. It also makes it…
Ask HN: I’m an FCC Commissioner proposing regulation of IoT security updates
401–410 of 944 posts
Re: Ask HN: I’m an FCC Commissioner proposing regulation of IoT security updates
#402It does absolutely nothing. It will simply be ignored. At most it will be an excuse for manufacturers to increase the price of a product simply because it has some "FCC APPROVED" sticker, while not costing any more to manufacture.
Re: Ask HN: I’m an FCC Commissioner proposing regulation of IoT security updates
#403Re: Ask HN: I’m an FCC Commissioner proposing regulation of IoT security updates
#404What about industrial IoT? Even if a manufacturer publishes updates, the clients would likely not want to change anything, often. If you have a plant with 1,000 units of gizmo-A and update them during a week-end and now 200 of them do not do the thing they used to do anymore... you have a big problem. There is a genuine fear to update anything in many industries and I am not sure how this can be overcome.
Re: Ask HN: I’m an FCC Commissioner proposing regulation of IoT security updates
#405One thing that regulators need to be very careful about is how "security updates" are defined, and exactly what manufacturer obligations for issuing security updates should be. CVEs are a notoriously terrible representation of actual security risks, so a measure like "manufacturer must issue new releases that include any released patches for CVEs with a severity rating greater than 9" would be a clear non-starter. Th…
> There are also often practical issues related to security patching embedded devices: for example, a downstream supplier's driver can make it impossible to upgrade a kernel unless/until the supplier provides a fix. Of course, strong regulation here could help to drive bad practices like that out of the industry, but I'm not going to hold my breath on that one. The effect of regulation like this would make it harder…
Re: Ask HN: I’m an FCC Commissioner proposing regulation of IoT security updates
#406Earlier quoted context omitted.
> These regulations put us on the path of trusting religious-like in government. We don't need to have religious-like faith in government because we can vote for people who will do what we want them to and we can vote out the people who refuse to do their job. It doesn't happen without the people getting involved and holding their government accountable though. You don't have to pray when you can vote. Without regula…
How well did that work for bank oversight in 2008, and again in 2023 with SVB? The accountability of "my one vote will remove government's failed regulators" fails on the scale of $billions.
Re: Ask HN: I’m an FCC Commissioner proposing regulation of IoT security updates
#407Earlier quoted context omitted.
I'm not sure it should be overcome. Updating software is not a panacea and not always the best thing to do. In industrial hardware it's often better to have a known quantity. Especially with equipment that can cause damage or even kill people. Even if it isn't quite that high stakes, dealing with constant random updates is a cost factor with no clear commercial gain. This doesn't mean there can't be updates, but they…
Yeah, I don't operate software controlled heavy machineries, but it's not comforting when I update a physically moving machine and it makes different sounds than before due to altered algorithms and parameters. Also, it's not considered a huge issue in smartphones and laptop computers, but updating firmware on Flash ROM degrades its performance such as data retention periods. Firmware updates are not always a rocket…
Re: Ask HN: I’m an FCC Commissioner proposing regulation of IoT security updates
#408Re: Ask HN: I’m an FCC Commissioner proposing regulation of IoT security updates
#409I think this is a bad idea which will lead to fewer and more expensive devices. I do not want the FCC regulating this. It is much more reasonable to have the market impose some discipline on manufacturers and their level of support. Plenty of consumers would favor less costly, less-supported devices.
Re: Ask HN: I’m an FCC Commissioner proposing regulation of IoT security updates
#410As a firmware engineer, I'm one of the people who actually writes the code that goes inside the IoT devices. I'm very interested in what the FCC might be able to do here. How does the FCC define a security flaw? Would updates only be distributed when there is a flaw that needs fixing? Remote update mechanisms can themselves present security problems in some domains. Thus, some devices should only be updatable if the…
+1 for this at the consumer level. My oven may have a critical update, but - for right now - *nothing* is more critical than finishing dinner. I'll let the update apply the day after thanksgiving when I'm doing the dishes.
There are a few connected appliances brands that do this well: updates are broken down into two classes - "critical/security" updates and "all the other updates" - and I get to pick from "do nothing, notify, notify and download, notify, schedule/auto-apply" for both channels. Unfortunately this is not common because it takes planning and more than the bare minimum to pull off.