221–230 of 944 posts
This would incentivize companies to provide updates but also allow the community to take over if the company folds.
Earlier quoted context omitted.
Free software firmware would be great for free software lovers and tech experts, no doubt. But sophisticated users who'll take advantage of things like that are only 1% of the market. But if the aim is to stop DDOSes from botnets of poorly secured IOT devices, we need something to help the other 99% of the market.
> But sophisticated users who'll take advantage of things like that are only 1% of the market. Most folks can't or won't do lots of things in their lives (e.g. plumbing, electrical, construction, lawn services, Automotive). The main thing blocking routers and IoT devices is the control every vendor wants to hold over their customers' devices after sale.
I'd argue that the main blocker to IoT security is the lack of culpability on the part of device manufacturers. I don't want to go so far as to suggest that companies should be wholly liable for software bugs, but vulnerabilities that are brought to the attention of the company privately or disclosed publicly absolutely should be their responsibility to address.
For you or me (or most of the folks here I suspect) we feel better if we had the ability to decide what software our fridge runs, but for 99% of people they're better off if their fridge's manufacturer provides them with regular security updates for the life of their product.
That being said, these aren't mutually exclusive. In a perfect world we'd have laws compelling fridge companies to allow 3rd party software if they don't keep their firmware up to date.
However, I still oppose it for mostly the same reason: if consumers wanted this type of label on their products, then we we would likely already see it.
I am also skeptical that this is being initially proposed as a voluntary program, but is actually laying the foundation for a regulation that is mandatory.]
Please do not propose this regulation. If consumers actually cared about their IoT devices receiving security updates, companies would be doing it. The fact that companies are not already doing this is evidence it's not important to consumers. People may express frustration, but their purchasing behavior speaks louder than their words.
This regulation would force companies to work on things that customers don't actually value. It will hinder innovation. Companies could work on features consumers value instead of working on security updates that consumers do not value.
If this regulation passes, companies will be less likely to offer new IoT devices knowing they will have to provide security updates beyond what consumers are demanding.
This regulation will also increase costs for IoT devices. As a consumer, I do not want the FCC mandating what features will be included in my IoT devices.
From the perspective of an individual engineer, tech regulation like this often leads to engineers doing soul-sucking work that nobody cares about. I know your focus is on consumer protection, not producers, so that point may be irrelevant.
Please do not be the individual that causes a negative impact on the world, despite whatever good intentions you may have.
I'm guessing if the FCC enacts this regulation, it will help you in your political career. However, if you were to take the opposite stance and oppose the legislation for the reasons stated above, I'm sure you'd lose your job very quickly. Therefore, I am confident I will be ignored.
I'm generally skeptical of the efficacy of regulation to solve a problem. Can you please cite some examples of where FCC regulation has been successful in solving other problems, and explain why you believe iot security regulation is likely to help?
As far as effective regulation from the FCC goes, one example would be how well 911 works (and that it actually works on cell phones in addition to landlines). It's because the FCC mandated telecoms include 911 capability, and that it always work, regardless of the subscription status for that line. Another success would be regulation that closed captioning be included in broadcast media, and support for displaying t…
FTA:
> I assumed that device manufacturers update the software in their device about every month...he said they do it annually.
Those devices are at least _getting_ updates - there is a long tail of devices whose operational lifecycle [far] exceeds the vendor's support timeframe - in other words, they don't get patches at all N months after release.
The solution to these problems is straightforward - we've been managing it in software for a long time. EOL OSes, Long Term Support (LTS) OS releases, etc - but the device manufacturers are not as mature, and have not been making natural progress to do so.
And since this is HN - there is a startup hidden in the midst of all of this: an enterprise-grade IoT OS that "does security right." Sell to the device manufacturers, allow them to market it as "enterprise-ready" or some such. If the FCC guidelines here are approved, there will be a suddenly increased demand!
Regulation to require a certain period of security updates doesn't seem useful to me. It's very easy to send out a "security update" that doesn't actually improve security. You can send out an ad to all your users saying "You should upgrade now to our newest product!" and call it a security update. Requiring security updates may end up just requiring companies to spam their users with a certain amount of marketing ma…
I think you're right that it would be difficult for the FCC to precisely define exactly when security updates are required. This is a problem in law generally, one that is usually resolved by imposing a reasonableness standard. Maybe here, a vulnerability needs to be patched if it might reasonably be expected to allow an attacker to take control of a device, or to do so when combined with other known or unknown vulne…
CIA: Confidentiality, Integrity, Availability.
More government is rarely the answer and especially so in this case.
One 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…
This. We were building an IoT product that was effectively stuck on a derivative of Ubuntu 18.04; we couldn't upgrade because vendor wouldn't rebase on a new LTS for a very long time. As our project was being developed in Python, we were stuck on 3.6, and as it reached EOL, many third-party libraries dropped support and wouldn't even release security fixes; we needed to stay on that particular OS because of hardware support; and moving off the distribution-provided Python packages would increase maintenance burden beyond what we were able to handle.
Even if the vendor would continue to provide security updates to the base OS and its packages, any real-world software solution will rely on third party packages, which may choose to drop support.
I would love it if the lawmakers considered this scenario.
There's virtually no overlap between the transactions of (1) purchasing the device for use, and (2) maintaining the device for security.
All the transaction features differ: different parties, different interests, different type of transactions, different risks. That's a recipe for exporting costs that no market mechanism or regulatory scheme can fix.
The best way to handle these is to have official succession plans: the manufacturer needs to delegate to a support organization for every product, and every product in use needs a way to indicate if it is up-to-date with support. The FCC maintains the database of support organizations for every FCC-certified device.
Everything can flow from that, from current to future legal and market contexts.
- Support organizations can take on devices. (Using open-source would be a particularly effective approach.)
- Ordinary negligence can attach to users without support or support organizations who fail to address a risk they know of.
- Support can be separately regulated
- Because support organization (like insurance companies) are taking on the risk, they will discipline manufacturers, raising the cost of producing unsupportable devices.
- Effective manufacturers might elect to internalize support (leveraging confidential information) or focus on manufacturing per design.
- Support organizations may start contracting manufacturers by design, to reduce overall costs considering the entire lifecycle.
Politically, I believe manufacturers seeking to avoid regulation would accept regulation if they have the alternative of offloading it to support organizations. Those organizations would welcome regulation as part of their moat. Large device users would welcome support organizations who can supply the service they need, and support can extend their expertise into consumer markets. Cost/price and the payer would track the value and cover the entire lifecycle.