Thank you for this detailed feedback. In the long-run, it's worth asking whether a business that doesn't make money once externalities have been internalized is a business worth having. But this is a voluntary program, and we're just hoping to spur growth of a segment of the device market where these issues are properly accounted for. Hopefully as more and more purchasers begin insisting on higher-standards, maybe by insisting on this label being present, economies of scale and componentization of secure IoT platforms will drive the costs of good IoT security down to the point where your concerns aren't as salient. Please consider sharing your thoughts through official comments.
The flip side of that is you can use control of all those high wattage devices to prevent power outages by shifting load to times when more energy is available.
Hopefully, that's how the impulse will be remembered.
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 vulnerabilities. Or maybe a different standard. Then when enforcement/lawsuits come around, the judge/jury/regulator has to evaluate the reasonableness of the manufacturer's actions in light of that standard. We'd love to see commentary on the record as to what the right legal standard might be.
(originally posted at https://news.ycombinator.com/item?id=37394188)
It's a voluntary label, so it's open to competition from other standard-setting organizations. When it comes to mandatory regulations generally, our office thinks that broad standards that are used to hold people accountable for negligent conduct are better than detailed checkbox-compliance exercises that quickly become out-of-date red tape.
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 vulnerabilities. Or maybe a different standard. Then when enforcement/lawsuits come around, the judge/jury/regulator has to evaluate the reasonableness of the manufacturer's actions in light of that standard. We'd love to see commentary on the record as to what the right legal standard might be.
I think if the box says updates until the beginning of 2025, and they've stopped providing updates before then, you have a pretty good contract lawsuit against them. You'd have to show that their failure to issue a patch for four months constitutes a breach, but that is exactly the kind of thing that gets hashed out in lawsuits. You could even have a class action of all the owners suing the manufacturer. We think one of the great opportunities of this labeling program is to begin developing a caselaw of what it means to hold a manufacturer to the commitments on the label.
Yep, the labeling would enable exactly the kind of class-action false advertising/fraud lawsuits against companies that simply lie on the packaging.
So companies would be forced to disclose their actual level of support, and risk consumers not wanting the product, lie on their disclosure and risk a significant class-action lawsuit, or improve their level of support.
I would hope the market would tip us towards the latter scenario, but...we won't know unless we actually force disclosure of these things.
I figure like everything else, this will just advantage the fly-by-night imports who you can't sue in the first place. They will continue to have no incentive to comply with any laws whatsoever.
These are all great points and maybe a good reason why a voluntary program like this is the way to start, so a higher-tier of secure products can begin to emerge. We would also love to see the emergence of platforms that allow small teams to build on top of a secure, update-ready base. Some interesting discussion here https://news.ycombinator.com/item?id=37394546
Thanks for this thoughtful feedback. I encourage you to file an official comment, especially regarding end-user control of update timing. Maybe my response here https://news.ycombinator.com/item?id=37394935 addresses some of your other concerns? We'd love to hear your thoughts.
