Hopefully automatic updates by default gets in there, because no one is going to manually update nay of this

Hmm, yeah. Just as fraud telemarketers set up a new shell run by the same principals when the legal bills come due for their old one, so we&#x27;re likely to see new labels for a new shell company slapped on the same old insecure IoT box.So I&#x27;m not sure &quot;escalating penalties&quot; is going to cut it. It&#x27;s still whack-a-mole. You need a way to kill the mole, not just drive it to pop up a new hole.You need a way to get to the principals. They&#x27;re the mole.You need to either make them personally liable financially, or you need to jail them. Nothing else is going to stop serial fraud-behind-a-shell-company.I&#x27;m not sure I have an answer. But whatever answer there is needs to be applied not only to fraud telemarketers (please), but also to fraud IoT manufacturers&#x2F;resellers.

Fair enough, but against whom?Fly-by-night foreign manufacturers or exporters would be difficult to prosecute. Unless the domestic importer, reseller, or transportation provider can be held liable, even class action lacks teeth.

If there’s a private right of action you can bet the class action lawyers will do the enforcing.

Your point about buyers at scale is really important. The current effort is focused on sellers, but we think that if sellers have to define their security commitments, buyers will pay attention and their risk management people will insist on high standards.I fear it is practically unenforceable, particularly for consumer-grade devices manufactured overseasAlso a good point. The way we handle this for RF interference is to look at distributors and importers, not just manufacturers, but there will probably always be an untrustworthy product tier out there.

They&#x27;re proposing an opt-in labeling program that essentially amounts for to the FCC underwriting certain attestations that vendors are choosing to make about their products.This means that someone applying the label without meeting the standards the label indicates would be guilty of exactly the sort of fraudulent advertising you&#x27;re describing, and contract and tort law are the relevant mechanisms of enforcement for this.I&#x27;m not sure what you mean by enforcement efforts being &quot;whack-a-mole at best&quot;, but if you&#x27;re expecting some sort of preemptive regulatory barrier to be enforced by a bureaucratic agency in advance, that&#x27;s just not the way this sort of thing works or is intended to work, and the FCC certainly wouldn&#x27;t have the legal authority to implement such a regime.Legal actions for fraud, false advertising, trademark infringement (in the case of trademarked standards certification badges, e.g. UL) are frequently used mechanisms for this sort of thing, and seem to work well enough to ensure that vendors are deterred from fraudulently applying certification labels to their products.

commitments on this label (including the support period) will be legally enforceable in contract and tort lawsuits and under other laws.When it comes to U.S. laws that touch technology, enforceability is a mess. Spyware, spam, fraud, misleading labels, etc. are already governed by various state and federal laws, yet enforcement efforts are whack-a-mole at best.For IoT devices, having the proposed requirements sounds good in theory but I fear it is practically unenforceable, particularly for consumer-grade devices manufactured overseas.However, if powerful IoT platforms are also tied into the new regs - with Google, Amazon, Apple, Microsoft, PTC, HPE, etc. required to audit supposedly qualified devices and ban those that don&#x27;t meet the standards, with escalating penalties for failing to do so - that might shift the needle.My 2 cents.

What’s your approach wrt. open source, and generally preventing security through obscurity?

IIRC the main objection was that it could be used to do something with the radio (boost power?) that caused the device to exceed FCC limits for a consumer radio? Something along those lines?

There was no requirement that firmware be locked down.The requirement was that consumer radio transmitters could be too easily made to use frequencies and power levels that violate FCC regulations.If a device had a transmitter where firmware could control those things, and the firmware for the device was one blob that contained everything so letting the user replace firmware meant letting the user control those restricted parameters, then the manufacturer might have to lock the firmware.There were other possible approaches. One would be to split the firmware into two parts. One part for the radio hardware and the other for everything else. Make it so the firmware update process only allows the manufacturer to supply the first part.

Vint Cerf and I shot that proposed anti-dd-wrt regulation down thoroughly: filing here:<a href="http:&#x2F;&#x2F;www.taht.net&#x2F;~d&#x2F;fcc_saner_software_practices.pdf" rel="nofollow noreferrer">http:&#x2F;&#x2F;www.taht.net&#x2F;~d&#x2F;fcc_saner_software_practices.pdf</a>Substitute IoT for router in everything we wrote there on page 12-13 and that seems to be a starting point everyone around here has come to think is necessary. I would prefer not to summarize such a large filing here.Also Dan Geer wrote extensively on these topics at the time.Of late I have been strongly suggesting that software be at least &quot;built in america&quot;: <a href="https:&#x2F;&#x2F;blog.cerowrt.org&#x2F;post&#x2F;an_upgrade_in_place&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;blog.cerowrt.org&#x2F;post&#x2F;an_upgrade_in_place&#x2F;</a>I care most deeply first - that the front doors to our houses, the home gateways, are properly secured, kept up to date, and have ipv6 and bufferbloat fixes on them.IoT devices belong on their own vlan...

As far as I remember FCC about 8 years ago didn&#x27;t liked OpenWRT, and even enforced on TP Link to lock it.

Why? The person you are replying to outlined one major example where IoT security was improved: wireless routers. Not allowing users to update the software on the hardware they own is just a botnet waiting to happen.

It allows users to replace insecure software with secure software. And it allows updates long after the company drops official support of the device.

I am all for alternative free software firmware. But I don&#x27;t think it adresses IoT security in any meaningful way.

This is kind of adjunct to the right-to-repair question. &quot;Smart&quot; features are being added to things that a person would expect to have a long usable lifetime--like cars, kitchen appliances, and so on. If the manufacturer is saying, we&#x27;ll only support the &quot;smart&quot; features for five years, one would be inclined to opt out on that unless there is a way to ensure the appliance remains useful.

Yeah if companies that make IoT hardware complain about the costs to keep old devices updated then they should be required to make them more user-modifiable and release source code &#x2F; signing keys when they&#x27;re abandoned by their manufacturer so that they can be picked up by the communities and development can be continued (also requires some policing to determine when hardware is functionally abandoned, as releasing a minor update once a year that doesn&#x27;t fix real bugs should still be considered abandoned). Repair cafes would be fantastic for helping support small businesses keeping people&#x27;s old hardware running.Of course, manufacturers don&#x27;t want that either because they make money off of planned obsolescence and consumers keeping old hardware running makes them less likely to buy old hardware.

At rotary phones still compatible with todays standards? If that’s the case I might get one too.

This is also a key point to fighting ewaste and making devices last longer. I have appliances from the 70s including a rotary telephone, that I still use regularly. If you combined mandatory OSS support with repair cafes, you would have a model for sustainable reuse and better security. You may even start a commercial aftermarket in reflashing older devices!

I&#x27;m a big supporter of the idea of applying right to repair principles to software, but I don&#x27;t think it should (or legally can) be implemented by fiat of unelected bureaucrats at the FCC. Labeling requirements like what the OP is proposing seem much more palatable to me.

openwrt is surely lacking in many aspects, but all the points you brought forward also apply to the manufacturer firmware but those are even less user friendly and cannot be modified.there are a lot of open and closed firmware projects building upon openwrt

There is absolutely no scenario where I want the firmware of any of my infrastructure devices updating without my say so. Even if there are dire security consequences of not updating.If a firmware update on my smart watch bricks it, who cares? But if my entire house&#x2F;office is without internet connection because of a bug in the router update, then I don&#x27;t want to waste time determining if its my ISP, my physical connection, my local hardware, or the firmware update that just occurred silently. I want to send the &quot;update&quot; command, note that network response did not resume within 5 minutes, and revert from there.A lot of folks tend to think of firmware updates as identical in complexity and risk to any other software update. I submit that if it can&#x27;t go wrong in such a way that it requires an in-system-programmer to fix, its a software update, not a firmware update.In that sense, I think true firmware updates (e.g. BIOS updates and the like) require a different set of regulations than your standard IoT security updates.

Openwrt is not the best example. Community sucks, some routers are full of bugs and the security is not great either.In general even if I like open devices and having the option to use my own software, this is not a solution for most of the consumers.It is not a solution even for the enthusiast that know how to flash their own firmware. Because even if they may do it a few times initially, eventually they stop doing it.You need a system that can update automatically even when you are busy in another project.

Maybe the presence or absence of this capability could be something disclosed on the label? It&#x27;s an idea worth thinking about. I encourage you to file a comment with your thoughts on the matter. You probably want to focus on how this information could help a security-concerned consumer&#x2F;business make a better purchasing decision. Or if you&#x27;re arguing that this be a hard-requirement for the label, why a device should not be considered secure without this capability.

Also, one of the single most important parts of security is human manageability. Having to go into a proprietary app for each manufacturer.There&#x27;s this level of management at the google&#x2F;amazom&#x2F;apple level, and in some cases google even lets me push firmware updates (sennheiser ambeo is an example), BUT there should be a requirement that security settings in firmware be exposed in a way that they can be manipulated in a rolled up dashboard. I shouldn&#x27;t have to depend on a first party app to stay maintained to get to the settings for a device.

I like this idea!
A code&amp;keys escrow org, yes please

This is an amazing idea and I would only buy a product that has this stamp on them. I would put some additional triggers into the publication of source code as well, notably if the company goes out of business. I would also put some kind of timer and renewal process on it, like a company needs to recertify every 1-5 years (pros and cons to different time lengths) and that they have indeed been providing actual updates (and not just fake ones) and actual support.

So this feels like an amazing idea...but do we really want to give the federal government the keys to update your equipment remotely and to be able to pinpoint weaknesses of the source?  This feels like Edward Snowden&#x27;s grimmest nightmare.

A challenge to this sort of suggestion is that the device OEM rarely controls all the software which goes into a device. There are third-party modules, hardware drivers, and more, which are also components. Then there are patents.Either the escrow would have to apply to all software on the device, regardless of whether owned by the OEM or third parties, or OEMs would be required to vouch for all the included software.I&#x27;d prefer the former myself: multiple software and patent assets can be combined, but on support EOL, all those become public domain.Build &#x2F; release &#x2F; update toolchains must also be included.

I have been thinking that something along these lines should apply to most embedded systems, from mobile phones to game consoles to IoT devices. And more, for cases when companies go under: industrial control automation, etc.However, it&#x27;s very hard to police: what if the company only provides a header file or so? Or the basic OS but not the UI?Moreover, what counts as &quot;support&quot;? There have been cases where companies refuse to consider remote code execution a &quot;security issue&quot;. What&#x27;s to prevent token updates that let the company claim a product is supported while it&#x27;s riddled with holes?I could also see companies fighting teeth and nails against this if their devices share a common software base. But hey, you have your support incentive right there!

The problem here is the government can’t be trusted with the signing keys. They will simply use them to deploy their botnets.

Possibly weird idea: federal firmware escrow. The OEM gets to put a stamp on their product after submitting firmware source&#x2F;keys to the FCC. When the OEM either declares the product not supported or provides no updates for X length of time, the files are automatically published to a public repository. Perhaps there is an appropriate license which says essentially that it is almost public domain, with an exception (or fee?) to use it for any purpose other than supporting the lifetime of an existing product.As others have stated, free software is one way of giving the public ability to keep things up to date but that&#x27;s almost like the government saying people are allowed to clean up pollution. It doesn&#x27;t put any pressure on companies to behave better.Another issue is build-ability of open source code. If an OEM submits firmware source and keys to a third party, even regularly, who really knows whether it is actually functional and complete. Automated tests or sample hardware are possible ideas but have their own failure modes and could be difficult for to implement solely for this purpose.Another weird idea for the above. If one requirement was deterministic builds, then in addition to source&#x2F;keys, a suitable toolchain to build could also be required such that the repository stewards would only need to run exactly what the OEM provides, and if the checksums don&#x27;t match then it means they are not in compliance.

I like this angle. Require device manufacturers to actually comply with OSS licenses and extend it to require providing the means for consumers to build upon the software as you mention.Furthermore, if the concern is national security, then I think some of the onus should be on the corporate consumers of such devices. Holding them responsible for doing due diligence on their vendors seems easier to regulate and enforce than trying to regulate supply side.Of course, this leaves the general population without a clear solution to updates if the process of updating using alternate channels has any amount of friction whatsoever. I&#x27;m clueless as to what to do about that. Regulating it entrenches established companies. Not regulating it maintains the status quo.Anecdotally, it feels like software has gotten far more secure in the past decade without regulation but security theater and concerns around national security have grown considerably faster. This isn&#x27;t easy to measure of course, but that&#x27;s how I see it.

The best alternative firmware example for true IOT devices is Tasmota [1]. Erase manufacturer firmware for every ESP devices the day after purchase to avoid those careless manufacturer firmwares.[1] <a href="https:&#x2F;&#x2F;tasmota.github.io&#x2F;docs&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;tasmota.github.io&#x2F;docs&#x2F;</a>

How about requiring devices to accept alternate, Free Software firmware, from the upstream provider?At the very least, it should be possible after some time period of no updates or insecurity, but a blanket requirement is less susceptible to games.Probably the best thing to happen to wireless routers is OpenWRT and the other descendents of the WRT firmware.

I guess the one thing I can hope you consider is that not everyone or everything is a for-profit company and you should leave open source and individual human developers out of these coercing regulations and only apply them to incorporated entities that exchange products for money.The idea of a random human being forced to keep writing software via the threat of being sued is incompatible with human freedom and in that context would be far worse than the problem it &quot;fixes&quot;.

I think you&#x27;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&#x2F;lawsuits come around, the judge&#x2F;jury&#x2F;regulator has to evaluate the reasonableness of the manufacturer&#x27;s actions in light of that standard. We&#x27;d love to see commentary on the record as to what the right legal standard might be.
(originally posted at <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37394188">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37394188</a>)

How can we define a security vulnerability meeting this &quot;serious&quot; requirement? There are a wide variety of vulnerabilities, so it seems difficult to define this strictly.

&gt; What&#x27;s stopping hobby&#x2F;micro-developers from saying &#x27;Not FCC approved, use at own risk&#x27;?OP is. Or rather, he wants to make it impossible to opt out. At least that&#x27;s how I interpret these two paragraphs:&gt; The FCC recently issued a Notice of Proposed Rulemaking [2] for a cybersecurity labeling program for connected devices. If they meet certain criteria for the security of their product, manufacturers can put an FCC cybersecurity label on it. I fought hard for one of these criteria to be the disclosure of how long the product will receive security updates. I hope that, besides arming consumers with better information, the commitments on this label (including the support period) will be legally enforceable in contract and tort lawsuits and under other laws. You can see my full statement here [3].&gt; But it’s too early to declare victory. Many manufacturers oppose making any commitments about security updates, even voluntary ones. These manufacturers are heavily engaged at the FCC and represented by sophisticated regulatory lawyers. The FCC and White House are not likely to take a strong stand if they only hear the device manufacturer&#x27;s side of the story.

What&#x27;s stopping hobby&#x2F;micro-developers from saying &#x27;Not FCC approved, use at own risk&#x27;? I hack on ESP32 devices, I certainly have different expectations as a hobbyist and as a consumer or consultant.

&gt; There is no way for people to know if products will still work in 2-5 years if it depends on some server staying up.If customers want it, there is a way: use contract law to commit the manufacturer.That&#x27;s already the norm for enterprise grade equipment. Companies often pay more for their hardware to get guaranteed long term support.So the market is willing and able to provide this kind of service, when people vote with their wallets.&gt; The free market hasn’t figured it out, as evidenced by the decade of half-working devices consumers are left with.The free market hasn&#x27;t provided me with a flying car either. But that doesn&#x27;t mean the market has failed. And I don&#x27;t think using bureaucracy to ban any company that doesn&#x27;t want to sell me a flying car would be an improvement on the status quo.(To be more explicit: many people, including me, think a flying car would be fun. But we don&#x27;t want it badly enough to be willing to pay what it would take. And that&#x27;s why suppliers only offer normal cars, not the flying kind.)

The free market hasn’t figured it out, as evidenced by the decade of half-working devices consumers are left with. There is no way for people to know if products will still work in 2-5 years if it depends on some server staying up.

Hurrah, more red tape!Please let customers opt out of your proposed protection, if they want to.(And it sounds like that&#x27;s already the status quo. So perhaps you could use your time to figure out where you can cut obsolete and cumbersome regulations instead of adding more mandatory bureaucracy that customers evidently don&#x27;t want enough to pay for voluntarily?)There might be an argument to be made about negative externalities. The economic standard answer is either let the Coase Theorem sort it out, or to tax the externalities. Not to ban what you don&#x27;t like.<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Coase_theorem" rel="nofollow noreferrer">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Coase_theorem</a>

I just want to reaffirm the importance of this point. I&#x27;ve used an open source solution named Home Assistant[0] to manage my own network of IoT devices that I don&#x27;t expose to the internet. I want to stay local because of the risks involved with the internet and with trusting companies to protect such private data.As such, I look to purchase relativity open devices. But, companies want to keep trying to inject themselves as a middleman, sometimes after the fact. In that case I&#x27;m let with a device that becomes e-waste. I don&#x27;t know what other actions are being taken in regards to subscriptions, but it&#x27;s a problem here.[0] <a href="https:&#x2F;&#x2F;www.home-assistant.io&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.home-assistant.io&#x2F;</a>

I&#x27;m not a US citizen, but I too would cosign the idea of not using security updates as a vector for pushing monetization &quot;features&quot;.

&gt; One of my concerns is that security updates are strictly defined in a way that prevents this type of regulation from being used as cover for these shenanigans.And then as a manufacturer you need to pay someone to certify that, or otherwise risk a class action lawsuit?What about hardware that uses third party software? (Either because it&#x27;s a genuine third party, eg when you put open source on your router, or because the manufacturer split into two companies to exploit a legal loophole?) Can open source software only make releases that update automatically after getting certified, or risk getting sued otherwise?

We’ve seen manufacturers abuse ongoing access to devices to turn off features the device came with at the time of purchase or convert one-time-fee features into subscriptions. One of my concerns is that security updates are strictly defined in a way that prevents this type of regulation from being used as cover for these shenanigans.

Sure, but the question here seemed to be about security, specifically. What you&#x27;re talking about is definitely a problem, but it seems like a different one.

That’s only one aspect of the problem.Lots of people have been bitten by suddenly unsupported devices.I think it could do some good.

Well, you can&#x27;t hold somebody accountable if there isn&#x27;t even a label or information somewhere saying that what they are doing is dangerous.

Exactly. I don&#x27;t see the situation improving until either the owner or, preferably, the manufacturer of a device that participates in a DoS attack is held partially accountable for said attack.

I don&#x27;t get what you&#x27;re saying here. What &quot;offending behavior&quot; are you referring to in this case that might be taxed to disincentivize it?

Sounds like you are making an argument based on externalities.That&#x27;s fine. But economic theory also gives you standard answers for externalities:Don&#x27;t ban the behaviour you dislike. Either let people sort it out themselves (like the Coase Theorem <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Coase_theorem" rel="nofollow noreferrer">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Coase_theorem</a> describes), or at most tax the offending behaviour.

Thanks for this great observation. I encourage you to share it in an official comment. In a final rulemaking, perhaps we could make it clear that the purpose of the label is not only to protect the purchaser of the product but also anyone who might be injured by way of a compromised device.  In an FCC enforcement proceeding, we have broad discretion in assessing damages. In contract, the third-party beneficiary doctrine could allow victims of such attacks to enforce label commitments. And in tort, statutory duties apply to anyone who is within the class of people that the law seeks to protect. So the law is flexible here, but it depends on what exactly our final rules say.

I think it is already illegal to participate in DDOS. Even though enforcement is .. pretty much nonexistent? And how could you enforce it? It would create an outcry if done consequently. (But maybe a neccessary one)But it also will be a consumer problem, if they cannot access important services anymore, because their IP has been blacklisted, because their toaster participated in too many DDOS or spam attacks.

In order to make it a consumer problem, we&#x27;d have to make it a criminal violation  to participate in a botnet. We could make it a punishable infraction I suppose, much like a speeding ticket for automobiles, but somehow I just don&#x27;t see this happening in a coordinated fashion across the world.

oh man, you sound like the type of person that would fall for the intentionally misleading labels that makes it sound like one thing but is in fact absolutely not that thing. just yesterday, there was a link to an article about the lies on food packaging.so, labeling requirements are one thing, but requiring that the information is straight forward and leaves no options for misleading would be great. I just don&#x27;t think there&#x27;s ever going to be a way from preventing someone from finding loopholes.

Even if consumers don&#x27;t necessarily care about security, required labelling gives brands an opportunity to stand out from one another. If I&#x27;m looking at two products on the shelf, where one claims to have greater security, and the other makes no such claim, I&#x27;m likely to buy the more secure one, even if I don&#x27;t necessarily care much about security. If getting the secure label is relatively cheap (which it should be, since most of the issues we see are the product of laziness rather than being especially hard to fix), than we could see the market dominated by products promoting high security, even without customers ever caring that much about insecure devices.

Making &quot;x years of security updates&quot; mandatory is likely to end up in a warning disclaimer every time you turn on the TV after x years: &quot;This device does not receive any more security updates. You may be at risk.&quot;That will either make a large part of consumers paranoid or annoyed. So they will replace a TV that is in perfectly working conditions with a new TV.Samsung, LG and the consumerist economy would love that!

&gt; „If sticker X is not on the package I will get hacked“ is much easier to grasp.Hmm. In the grocery store, where this idea comes from and has the most persuasive history in govt. regulation, where manufacturers own the front of the package and regulators own the back, what is the healthiest food?The produce and meat. Which has no nutritional label.There&#x27;s no such thing as a secure IoT device. There&#x27;s absolutely no such thing as a secure connected device that is also cheap.If you build your computer from commodity parts, it tends to be the longest lasting and most secure. It is usually the most expensive.Anyway, what would the label for a PlayStation 5 and an iPhone 15 look like? Miles long.Then, for the consumer buying the cheapest smart plugs off Amazon? Like one paragraph the vendor copied and pasted from the Internet, along with all the other legal shit they deal with.Whom should be regulated? I guess Amazon and Walmart, the retailers, they are the real gatekeepers. That&#x27;s what the EU does! Which doesn&#x27;t fly here. The Waltons live here, not in the EU.

I think you are underestimating how a well known „secure“ label (or lack thereof) could influence customer behavior. It’s not that they don’t care - they (understandably) lack deeper knowledge and therefore don’t base their purchasing decisions on how long they will get updates. „If sticker X is not on the package I will get hacked“ is much easier to grasp.

A big issue with botnets running on device owner equipment is the amount of bandwidth they &quot;steal&quot; from the device owner. Especially for device owners who are on constrained networks (such as a mobile&#x2F;satellite network) this can be a really expensive issue for the device owner.So while the device owner may not be the primary victim, they can definitely still be heavily affected.

&gt; The FCC recently issued a Notice of Proposed Rulemaking [2] for a cybersecurity labeling program for connected devices.That appears to me to be the wrong way to go about this, and it has specifically to do with how IoT security is a problem.The most severe case of IoT security problems we have seen were things like mass botnets, where plenty of devices of the same type were hacked and then used for things like DoS attacks. Notable cases include the DoS attacks against Brian Krebs for some of his reporting.The important thing to understand here is that the device owner is not the primary victim. That&#x27;s a third party.This is not about consumer choice, because consumers by and large do not care, because they are not the people being affected by this. An optional security label tries to adress it as a consumer choice problem, which it isn&#x27;t.

I wonder how companies will simultaneously deal with these FCC regulations in the US, and the proposed regulation to not update anything without intelligence approval in the UK.

They&#x27;re definitely making efforts to engage where practitioners and subject matter experts are. Substantial Federal gov showing at defcon this year for example.<a href="https:&#x2F;&#x2F;www.dhs.gov&#x2F;news&#x2F;2023&#x2F;08&#x2F;11&#x2F;secretary-mayorkas-delivers-remarks-def-con-31" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.dhs.gov&#x2F;news&#x2F;2023&#x2F;08&#x2F;11&#x2F;secretary-mayorkas-deliv...</a><a href="https:&#x2F;&#x2F;www.politico.com&#x2F;news&#x2F;2023&#x2F;08&#x2F;11&#x2F;def-con-hackers-space-force-00110919" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.politico.com&#x2F;news&#x2F;2023&#x2F;08&#x2F;11&#x2F;def-con-hackers-spa...</a><a href="https:&#x2F;&#x2F;arstechnica.com&#x2F;information-technology&#x2F;2023&#x2F;05&#x2F;white-house-challenges-hackers-to-break-top-ai-models-at-def-con-31&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;arstechnica.com&#x2F;information-technology&#x2F;2023&#x2F;05&#x2F;white...</a>

Pretty cool (or at least interesting) to see a government agency engage on HN like this. Never seen that before.

I think that you&#x27;ll get a lot of feedback.I would suggest to my peers, that the links you gave are &quot;official channels,&quot; and are probably what you really want, as opposed to a rather rambling thread of comments.But for me, you just get a rambling comment.I made my career on devices. In particular digital scanners and cameras.I worked for a company that was about as tinfoil as you could get, and they supported devices long past their sell-by date.But I also know that my company was an outlier. They sold premium equipment, at a premium price. They were an &quot;old-fashioned&quot; Japanese corporation, and had a basic mindset of keeping the customer&#x27;s workflow in the center of the screen.I think IoT security is a huge issue, and I think that the solution could be that there are standard, open-source, open-license, free-to-use packages; maybe written in languages like C, that could be offered to the industry. These could enforce low-level compliance with security standards.Oh, and keep the TLAs out of it. They would really like to put a bit of &quot;extra spice&quot; in something like that.That said, I know that it will never happen. There&#x27;s a gazillion issues.

An even better venue for informed cybersec professionals is the info-sec community on Twitter and Mastodon, <a href="https:&#x2F;&#x2F;infosec.exchange&#x2F;about" rel="nofollow noreferrer">https:&#x2F;&#x2F;infosec.exchange&#x2F;about</a> .People like Michal Zalewski, <a href="https:&#x2F;&#x2F;twitter.com&#x2F;lcamtuf" rel="nofollow noreferrer">https:&#x2F;&#x2F;twitter.com&#x2F;lcamtuf</a>, could point you to the best of that.

Thanks for participating! After this thread winds down, I and my team are going to comb through it for suggestions and take as many as we can. We&#x27;re also looking into other venues to engage directly with cybersecurity professionals. But please feel free to comment on the record as well -- a robust and detailed record is worth a lot more than whatever I can do individually.

Awesome!Thanks for engaging, where the rubber meets the road!Hopefully, you are also looking into other venues, as well.HN has a great group of folks that represent some of the most cutting-edge tech, but IT runs on Java 8[0].[0] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19877916">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19877916</a>

I don&#x27;t think it has to be part of the network interface. You could have an ethernet-connected device that emits RF for some non-networking purpose and I think it would still qualify.

I don&#x27;t like the quoted wording.  I would like it to be clearer that the RF part isn&#x27;t part of the transducer, but part of the network interface.

&gt; Accordingly, incorporating our modifications, we propose, for purposes of the IoT labeling program, to define an IoT device as: (1) an Internet-connected device capable of intentionally emitting RF energy that has at least one transducer (sensor or actuator) for interacting directly with the physical world, coupled with (2) at least one network interface (e.g., Wi-Fi, Bluetooth) for interfacing with the digital world. We seek comment on our proposed definition.I think this definition would apply to stuff like phones and cars, right? If so that&#x27;s great.

From the Cyber Trust Mark perspective, there&#x27;s no inherent difference between a connected disposable gizmo and your example of the water heater. Personally, I would love to see a minimum cybersecurity commitment made by anyone who makes or sells anything with connectivity.

What makes IoT devices special, and warrants carve outs for security &#x2F; vulnerabilities?I guess I am not surprised there are security issues with these devices, because I think of most of them as coming from small companies, and wonder what the impact would be on the IoT space if only large players can work through more regulation.That said, I can&#x27;t decide if I am more concerned about my Wyze camera sending data where I don&#x27;t want it to, than my water heater leaking it&#x27;s current temperature (implicating whether I am home or not).

These rules sound like reasonable steps, upon first reading. Not sure what the downstream effects might be.Is there any thought given to cloud based devices becoming paperweight when companies behind them just stop supporting it or turn off the API? I&#x27;d like some &quot;assurances&quot; in place that if the company either goes out of business or decides to sunset the service, it would be required to open source (or at least make available for download). If memory services, that happened to some Nest models a while back.

we installed a storm door not for protection against storms, but an intruder armed with a brick and&#x2F;or hammer because our front door was 85% single pane of glass.it seems like a bad analogy on the GP&#x27;s part

&gt; It&#x27;d be like putting a &quot;secure against bricks&quot; sticker on a window.I lived in a house that had such secure windows. I even witnessed someone trying and failing to smash a window with a brick.

Scroll down: <a href="https:&#x2F;&#x2F;arstechnica.com&#x2F;author&#x2F;dan-goodin&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;arstechnica.com&#x2F;author&#x2F;dan-goodin&#x2F;</a> This is just a teeny tiny sampling of the security vulnerabilities disclosed every day. Our industry is just not built with security as a goal, and even if we started caring about it today, we have 50 years of not caring to patch up. Caring about security in a meaningful way (i.e. formal verification, engineer licensing &amp; liability) is really, really expensive. No one is going to carry that burden when their competitors don&#x27;t have to. The end result is the situation we find ourselves in: there is no such thing as computer security, and any networked computer should be considered compromised by default.

&gt; There is no such thing as computer security in 2023This is absurd.Even the passive basics like relying on your free email provider&#x27;s filtering and running Windows Defender is going to stop a huge number of attacks.If you&#x27;re expecting perfect security, you&#x27;ll be disappointed -- but we can&#x27;t declare complete bankruptcy.

Amusingly enough, being able (or not being able) to gain root access to my own devices is one of the main reasons I can&#x27;t address or verify their security - especially as official support is dropped over time.Modern phones and other appliances have (or are) computers to which it is nigh impossible to operate as root. You might say you have to pwn them even if you supposedly own them ;)

This take is simply not based in reality. Compare what it took to gain root access to a computer 20 years ago to a modern iPhone and tell me again that there is absolutely no point in caring about security.

Well, my comment is predicated on the, apparently erroneous :), assumption that no glass is brick-proof.  It is impossible to build a secure software product with our current tooling &amp; development practices.  The number of security flaws in every software product is so high as to make the label meaningless. I don&#x27;t think there&#x27;s a meaningful distinction to end consumers between &quot;this product has 1,000 holes, 100 of which are publicly disclosed&quot; (i.e. no label) and &quot;this product has 900 holes&quot; (i.e. with label).

&gt; If someone wants to sell brick-proof glass, and get a sticker from the US GovernmentIn a free society, why would we ask government (lowercase g) for a window certification sticker? Should government also provide condom anti-breakage stickers? If we want this, maybe UL can set the standard and ask for volunteer testers to affirm the condom or window anti-breakage quality.Or maybe we can put the Bell System back together and let them regulate what devices may connect to the network. That led to expensive monthly handset charges.

I understand your skepticism. That&#x27;s why I want to see the label functioning as something like an enforceable representation to consumers. If someone wants to sell brick-proof glass, and get a sticker from the US Government saying so, it better be brick-proof.

I completely agree that it is meaningless to assert that something is &quot;secure&quot;. Even very well secured things have been hacked, and the smallest of mistakes can have huge impact.What would be meaningful is an assertion that some basic set of secure practices have been or are followed. For example, that there are no default passwords on a device, that security updates will be provided on some defined schedule, that network protocols meet some reasonable standard of security, etc.

Does the IoT company called &quot;Eve&quot; give hope to the industry?  From what I understand, they take a security first approach to their IoT products.  I haven&#x27;t tried them out yet though.

I think this might be useful if we kind of wargame prospective regulations to follow all the ways people might abuse it, then you might get something that works. Maybe lawmakers already do that? This thread feels in that spirit too…

There is no security against all the threats you can possibly be imagine, but being free of well known, stupid simple vulnerabilities is still good.

FWIW, seeing a security compliance label on an IoT product wouldn&#x27;t mean anything to me as a consumer. There is no such thing as computer security in 2023, and there are no hints that security will exist at any point on the horizon. Even the biggest names in the field cannot put out secure products. Products from well-meaning manufacturers are going to be absolutely riddled with security problems, and putting a sticker on the box won&#x27;t change that. It is literally impossible to put out a software product with anything resembling security today. It&#x27;d be like putting a &quot;secure against bricks&quot; sticker on a window.  Our industry is a joke. Building secure software products can&#x27;t be done without completely rearchitecting how our industry operates, which isn&#x27;t going to happen.

My opinion is that a stationary e-bike should be a stationary bike whether or not the wifi  is connected, and then I can choose whether I want to connect it online. I don’t think a switch is necessary, just don’t connect the thing.

This is a great point. What are your thoughts on requiring a switch on all IoT devices so the consumer can flip a switch and their &quot;smart Widget&quot; just becomes a &quot;widget&quot;? This would be a nice for both security perspective and a consumer perspective.An insecure e-stationary bike should just become a stationary bike rather than a 100-pound pile of trash.

There are too many IoT devices that want my email&#x2F;phone just to perform what normal devices have been able to do for decades. No, I don’t want to download an app just so I can use my apartment stationary bike. I get enough spam already, and I don’t want to agree to a long terms and conditions just for that. In that case I couldn’t even use the bike at all without creating an account.I think a lot of places got duped into thinking their internet connected stuff was an upgrade but in my opinion it’s a major downgrade. A device should do what other non-IoT devices do without being online, and internet capabilities should only be a value-add. A toaster should make toast without being online.

Has there ever been an example of a consumer RF emitter being remotely hacked and turned into a jammer?

That&#x27;s a great question. Devices that emit RF could be hijacked and turned into signal jammers. With smart jamming attacks, even low-power transmitters could potentially cause serious harmful interference to other devices. Botnets of compromised devices could be especially damaging. Since vulnerabilities are often chained by attackers, sometimes in very unexpected ways, to accomplish their final goal, we think that the FCC has a legitimate interest in just about any vulnerability on a wireless device. But the question of legal authority is itself open for public comment and we hope there&#x27;s vigorous debate on the record to make sure we get it right.

If a device does not violate (e.g.) RF emissions regulations, what authority does the FCC have to regulate its internals?Thanks!

&gt; A mechanism requiring disclosure of how long security updates are available seems like a great step.So, as I work in this space, there needs to be realistic guidelines on this, does a security flaw need to have a CVE ? Do they need to fix every CVE ? What is the timeframe requirement ?This kind of thing keeps me up at night.

The requirement can be easily bypassed by going bankrupt before the required time is up. You will soon hear advice like &quot;if you want to get in to the IoT space, create a new C Corp for each iteration of your product...&quot;Whatever you require them to disclose after X years, it must be escrowed with a trusted third party in advance.

Another great step would be a guarantee of making the firmware Open Source after no more than a certain amount of time, and having that guarantee known at compile time. Effectively, that means the device will always be supportable.It&#x27;s not inconceivable that this could be a requirement for getting a label (or some tier of label.) It depends how the advocacy comes out on the record.

A mechanism requiring disclosure of how long security updates are available seems like a great step.Another great step would be a guarantee of making the firmware Open Source after no more than a certain amount of time, and having that guarantee known at compile time. Effectively, that means the device will always be supportable.

I don&#x27;t know who those manufacturers are, but I can guess. One left-field piece of advice I would offer is looking at what they specify for their own offices&#x2F;HQs.&quot;Smart&quot; commercial office space has a bit of a head start in this area, and the specifiers have now had some time to find their feet.Some prominent IoT device manufacturers have had written into the specifications for their own buildings that, for example, the end user (read: them) shall be able to manage the certificates on the devices, and so on and so forth.A couple that come to mind would make for nice blueprints for consumer protections if you can cut through the prescriptive talk about preferred tech.

&gt; Companies may cease supporting a device well before consumers have stopped using itIn which case all information required to create and load custom firmware should be released to the public. This information should be placed in escrow, in case the company ceases to exist. The same rule should apply to backend services, in case of a device being depended on such a service to operate.&gt; security updates for a reasonable amount of timeWhich is 25 year or more for some classes of devices. Phone have already reached a point where they should be required to come with 10 years of security updates. I&#x27;d expect light switches to get at the very least 20 years of security updates.Generally I believe that governments are being WAY to lenient towards manufactures of any type of electronics when it comes to updates. It&#x27;s bad for security, the environment and the causes consumers to make bad investments. The companies making these devices have long since proven that they DO NOT CARE and shouldn&#x27;t be trusted to deal with the issues themselves.

None taken, of course. Several people in this thread have made this point, and it&#x27;s a very reasonable one.The current framework is 100% voluntary for what amounts to a marketing label. There are non-FCC government databases for issue reporting, and a commitment to reporting to such DBs could be part of what earns you a higher label. Would be great to see commentary on this point from the tech public.

&gt; I would prefer that FCC works to inform: maintain an up-to-date database of issues (reported by both the manufacturers and by third-parties), impacts and recommended fixes for those that have a fix. My 2c.How would that help 99.99% of consumers? They are not going to look in databases, understand the issue, and apply fixes.

&gt; I’ve advocated for the FCC to require device manufacturers to support their devices with security updates for a reasonable amount of time [1].No offense intended, but I would be worried about this more than I would be worried about the current state of the IoT world. A blanket requirement would punish hobbyists and small companies prototyping new technologies. But big players could spend relatively minor technical and legal resources for publishing regular &quot;security updates&quot; without trying to find and close the biggest security holes.I would prefer that FCC works to inform: maintain an up-to-date database of issues (reported by both the manufacturers and by third-parties), impacts and recommended fixes for those that have a fix. My 2c.

Nothing? Hasn&#x27;t Apple built a part of their brand upon security and privacy?

&gt; An informed market avoids lemons.Has that been true in practice? I can think of plenty of horrible products, in IT, on the market. In terms of security (including privacy), the market has done nothing for IT consumers. And what about the people who already bought the lemons, before the market learned of it? Also, what if the lemon doesn&#x27;t affect me but affects others (such as through DDoS)?I prefer to keep it as simple as possible, but no simpler.

As someone with a libertarian bent, meaningful labels appeal to me as a decent way to address problems without overriding the judgement of the market. An informed market avoids lemons. So this proposal sounds OK in principle but here are some questions. Please be aware that I&#x27;m not a US citizen so my views don&#x27;t really matter here, I&#x27;m just looking over the garden fence and asking questions.1. Your argument for why it&#x27;s under the FCC&#x27;s jurisdiction doesn&#x27;t seem all that strong. In your linked speech, you argue it&#x27;s important because the FCC has the ability to regulate signals interference, and insecure devices could be turned into jammers. Has this ever actually happened? If not, is this not rather a large stretch of the FCC&#x27;s mandate? Perhaps this sort of effort belongs in a different part of the government, or in an international standards agreement (possibly non-governmental).2. What&#x27;s the definition of security you&#x27;re using? Security problems always exist in the context of a threat model, so having a label would imply standardizing a threat model. For example, smartphone security systems were originally designed to block malware, but over time have been stretched to try and solve often vaguely specified privacy goals towards non-malicious software too. If someone commits to supporting security updates for five or ten years at risk of government censure, then the definition of security is going to become a battlefield because whoever wins gets to control all the software that&#x27;s got this label.3. Modern security is layered via defense-in-depth strategies. If there&#x27;s a bug in an inner layer but it&#x27;s not exploitable due to mitigations or sandboxes (software firewalls) in outer layers, is that a mandatory security update or not? It could be argued either way because the device is not technically hackable still, simply the armor became weaker. Today this is left to the best judgement of engineers, who must balance efforts to patch theoretical vulns in old devices with work to e.g. build new defenses for newer devices. If it becomes mandatory, then paradoxically, new devices may become less secure than they otherwise could have been because all the effort is going into patching old devices.4. Imagine a company commits to security updates for all devices for 10 years, but after 5 gets into financial difficulties. Maybe due to competitors who didn&#x27;t make that expensive commitment. One quick way to dig themselves out of this hole is to push a &#x27;security update&#x27; that drastically restricts the device&#x27;s functionality e.g. prevents it from installing new apps released after a certain date. This can be indeed argued to make the device more secure, and you can argue that there&#x27;s no expectation that the device will always be able to install new apps anyway, so no end-user expectations or promises have been violated. How would you stop this kind of perverse incentive?

Consumer&#x27;s power is not the same as FCC&#x27;s

So what we need is giant warning stickers on products of which their parent companies don&#x27;t follow good practices. Kind of like tobacco products.&quot;Leaks your personal data to unknown servers&quot; Or &quot;Manufacturer typically does not support their products beyond 2 years after which critical features and functions may stop working&quot;

I&#x27;ve been not-buying IOT trash as hard as I can for decades. But nothing&#x27;s changing... please tell me how to do this correctly!

A relatively small group of people won&#x27;t have an effect, that&#x27;s why regulation plays an important role.

You as a customer can already give the manufacturer that choice, and simple refuse to buy from any manufacturer that doesn&#x27;t comply.

I&#x27;m working on an IoT device for industrial use, and we&#x27;re wrestling with this very problem.The answer we&#x27;re probably going to go with is that the device is &#x27;leased&#x27; to the customer. It&#x27;s part of their subscription.This solves a ton of problems about FLOSS and support of the same. It&#x27;s now a closed device, and you have no rights to the code inside. If we go out of business, you have a brick that you don&#x27;t have to pay for anymore.

If parts of the supply chain aren&#x27;t FLOSS, then manufacturers would have to lean on those suppliers to change their licensing or find different suppliers. Same with other regulations around things like lead in consumer products. Anyone wanting to be part of consumer product software supply chains would have to start offering it as FLOSS if they want any customers, so the supply chain would adjust to the new reality.We do need to establish common sense liability if it&#x27;s not already there. If you modify your circular saw to remove the guard and injure yourself, that&#x27;s your fault. If you modify some software to run outside of safe design parameters and it malfunctions&#x2F;injures you, that&#x27;s your fault.I don&#x27;t see why zero-trust is incompatible with user-modified devices. In fact it&#x27;s in line with the spirit of zero-trust: don&#x27;t assume just because something is able to talk to one of your servers (e.g. because it&#x27;s on your VPN&#x2F;LAN) that it&#x27;s friendly. People should already always be assuming customer-owned hardware will potentially be completely controlled by a malicious actor and acting accordingly.

&gt; either they must provide full (FLOSS) source code and documentationI like the spirit of this, but one problem with this is that the software stack is likely not FLOSS, and the manufacturers don&#x27;t own all the software.A second problem is that lot of the software for production IoT-devices doesn&#x27;t live in the device.Third, there are safety concerns with a lot of devices that you&#x27;d need legal productions for.Finally, the best IoT devices use a zero-trust architecture. You&#x27;d need to support a variation of this pattern to allow users to modify the devices.

Sorry, but some people will run routers (and other IoT devices) for &gt; 10 years, and long past some random 2 year EOL a manufacturer may set. We need less e-waste, and if manufacturers have to warrant security for 30 years, they may also invest enough to make the hardware itself last longer.  More expensive is totally fine if the product is useful for longer! Oh, and please double-check if you really have no 1st generation Raspberry PI anywhere, or maybe some ancient Arduino? What about your washer? Modern washers are IoT devices. My (admittedly not yet IoT washer) is &gt; 10 years old. Or take your car. Sure, you may buy a new one every 10 years, but there are plenty of cars &gt; 10 years on the road. Do you want all of them to be vulnerable and out of warranty in the future?

&gt; 30 years of expected support is pretty unreasonable.I happen to know, having been with a Ford unit at the time, that the Ford EEC-IV engine control unit in 1980s Ford cars and trucks was designed for a 30 year lifetime. Many are still working.The average age of light vehicles in the US is 12.2 years.This is more in NHTSA&#x27;s wheelhouse, though.

&gt; I don&#x27;t have a single computing device that has lasted longer than 10 years. Reasonably speaking, either performance or features start to make the device largely obsolete and unusable.Are you just buying cheap junk? An i7-3770 PC - a good example of an 11 year old PC, and one I happen to use every day - can be quite usable today.

30 years of expected support is pretty unreasonable. Stating a requirement like this makes the discussion about competing dogmas. Rather, it&#x27;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 harder to disrupt an industry with hardware at its core.I don&#x27;t have a single computing device that has lasted longer than 10 years. Reasonably speaking, either performance or features start to make the device largely obsolete and unusable.I think a better way to propose this would be the expectation that when a product is EOL, it should be supportable by the buyer for a certain period. This requires figuring out the right period of support. I&#x27;d propose something that scales period based on cost or device class. A $1200 phone should be usable for 10 years while a $10 disposable glucose sensor with a battery should not.

I favor something like this, if less strong. It should be required that a product that reaches end-of-life as defined by the manufacturer should have all documentation and source code released and open sourced; prior to end-of-life (and perhaps for one year after), they&#x27;re required to provide security updates. The manufacturer is then free to decide the point at which closed source is no longer worth the maintenance cost.A few additional thoughts:- Perhaps hardware design&#x2F;specs should be released as well?- A government body should probably host this information after EOL.

Ah, the utopian dream of a world where every manufacturer gives away their intellectual secrets just so users can play tech guru. You&#x27;re suggesting that companies offer up decades of R&amp;D and risk their competitive edge, or else face 30 years of liability? With the speed at which technology evolves, we&#x27;re lucky if a device is even relevant after 30 months. And let&#x27;s not forget the minor detail of skyrocketing costs. Want a device built under these fantasy rules? Hope you&#x27;re ready to pay through the nose—think 10 times the current price. Because nothing says &#x27;accessible technology&#x27; like pricing out the average consumer.

^^^ This right here ^^^Additionally, this cannot be an excuse to charge subscriptions or force lease agreements into the fine print for items consumers buy outright.

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 that they cannot get out of that liability by bankruptcy). Most will opt for FLOSS, and none will have the excuse that it would be more secure to make it proprietary. And then users will at least be able to fix issues -- and the security community will be way more effective at finding issues as it wouldn&#x27;t have to do the slow reverse engineering.

&gt; Also, what happens when an IoT mfr is acquired, does the acquirer assume all the IoT risks as well?Most other liabilities are inherited during an acquisition. I don&#x27;t see a good reason for this to be an exception.It would encourage acquirer&#x27;s to do much more strict due diligence in this regard, which will have a natural pressure to clean up the behavior of manufacturer&#x27;s that plan to seek a future exit.Any exception to liability here seems like a get out of jail free card, for all new manufacturers seeking an exit to behave extremely badly. It also opens the door to corporate shell games, where as soon as a liability is discovered it gets acquired by a thin parent entity to dissolve that liability. I&#x27;ll leave a comment to that effect as well, but it absolutely seems like this liability should survive an acquisition.

Planned or unplanned obsolescence is good for business. You are proposing regulations counter to that, so should expect counter-pressure, even for IoT makers that want to do the right thing.Great points. From one perspective, we can&#x27;t afford to do this stuff; from another, we can&#x27;t afford not to. If connectivity makes your life a little easier for little risk, that&#x27;s one thing; if your dishwasher steals your identity and sells it online, that&#x27;s another.My concern would be low quality, usually cheaper, whack-a-mole mfrs that come and go on Amazon, eBay, etc. Even if they release a product that would fall under these guidelines, how are you going to go after a ghost?Another great point, but that&#x27;s a snapshot of the market as it is now. We expect certain standards from some things but not others, depending on how much you depend on them, how much is at risk, and what the costs would be. Right now, under the proposal, a company is 100% free to say &quot;I will support this for 0 days and you expect it to ship broken from the factory&quot; -- it&#x27;s just that they actually have to say that out loud.Also, what happens when an IoT mfr is acquired, does the acquirer assume all the IoT risks as well?I expect this to be a hot topic on the record. We&#x27;ll see what technologists, manufacturers, consumer advocates, etc. say and try to come up with a proposal addressing stated concerns.

Planned or unplanned obsolescence is good for business. You are proposing regulations counter to that, so should expect counter-pressure, even for IoT makers that want to do the right thing.By volume and impact, what devices have IoT vulnerabilities? If from large mfrs, you might expect some measure of support as that would be somewhat in their best interest, if only to preserve their brand image. My concern would be low quality, usually cheaper, whack-a-mole mfrs that come and go on Amazon, eBay, etc. Even if they release a product that would fall under these guidelines, how are you going to go after a ghost?Also, what happens when an IoT mfr is acquired, does the acquirer assume all the IoT risks as well?

Firstly you have to appreciate the web isn’t a thing. When they want to talk protocols and crypto they mean things like sockets, mqtt and talk about where on the production line the fuses for the keys will be blown and who will have access to that area. It is a different universe.The absolutely huge thing is they want to live in a world of standard interchangeable pieces. They despise custom solutions to problems unless totally necessary or they are enormously better than the alternatives.They will flat out tell you that they are essentially waiting for an industry standard solution to problem X to appear, and until it does these ad hoc solutions suck.If you want IoT security you don’t need to regulate it, you “just” need to create a no-brainer to adopt industry standard model for device operation that these people can drop in place. (I hate MQTT, but think something in that ballpark with the right security model* would be a good starting point). This is a hard enough ask as is, but is made harder by the big software giants all trying to come up with schemes that put them in the middle all the time.As an aside I also encountered a non Taiwanese executive espousing the view (with respect to slurping up network topologies via multicast) that he hates it, but as long as it isn’t illegal they have to do it. I don’t believe the law would help as you will always have bad actors and people using aliexpress - it needs to be technically impossible, hence the star networks.Edit to add: * and provisioning process. Were it up to me I&#x27;d have something like NFC based key exchange between broker and device during setup as part of the standard.

&gt; The only corporate actors I encountered that understood this were the Taiwanese OEMs, who are remarkably on point and blunt behind closed doors, but they are basically powerless to do anything about it.Fascinating! Could you elaborate?

&gt;Having worked in the space I came to the conclusion the only viable secure future is to adopt star topology local networks where local traffic for all devices goes into a single secure regularly updated broker device that then decides what to do with it. Any access out to the Internet or between devices needs to be mediated.Yes, yours is (IMHO) the only possible way out, still there are things that simply should be not allowed or be only optional, as I see it the &quot;mistake&quot; is confounding the &quot;Internet&quot; in IoT with the &quot;Cloud&quot;.

While the IoT security situation is out of control I doubt that regulating security updates will have any other result than radically reducing competition and innovation in the space by making it impossible to operate as a small company. It will simply push more hardware innovation out to China.Having worked in the space I came to the conclusion the only viable secure future is to adopt star topology local networks where local traffic for all devices goes into a single secure regularly updated broker device that then decides what to do with it. Any access out to the Internet or between devices needs to be mediated. The part that will annoy a lot of people is that broker device probably needs to be able to read all of it. Therefore rather than just regulation I would talk to the WiFi alliance in particular about possibly expanding the scope of what it means to be a WiFi router.The problem is actors like Google really want such a thing to be just in the cloud &quot;for convenience&quot;, by which they mean monitoring everything that ever happens.The only corporate actors I encountered that understood this were the Taiwanese OEMs, who are remarkably on point and blunt behind closed doors, but they are basically powerless to do anything about it.Edit to add: if there is one thing the FCC could do immediately it would be to ban the covert deployment of cellular modems in other devices and to force giant warning labels for such things and require they be user removable.

Thank so much for posting this here first of all! I agree with other comments that rather than, or in addition to, some direct required period for security updates I&#x27;d really like to see a dynamic setup along the lines of &quot;Power Means Responsibility&quot;: manufacturers can stop supporting devices when they wish, but must at that time release all keys and IP licensing needed for hardware owners to take over. If a company wants to keep supporting something, and in turn keep their power over deciding how it works, for 10 years that&#x27;s fine. If they want to drop it after 6 months and make the firmware fully source available and allow owners to add their own root keys to devices that&#x27;d be fine too. Or someone could offer something fully open source with no strings attached but also no responsibility attached. The market can fill with a range of decent options.But manufacturers shouldn&#x27;t be allowed to have it both ways, with control post-sale over their customers&#x27; hardware AND no responsibility to support it. It should be directly linked by law.

100% agree! This is a totally voluntary program that is explicitly based on EnergyStar.I also worry that check-the-box compliance is one possible outcome. I&#x27;d love to see professionals comment on the record about where a checklist would and wouldn&#x27;t be helpful. I&#x27;d also love commentary on if and where liability for failure to meet stated commitments would be helpful.

&gt; Voluntary certification, please.
Second this, otherwise it&#x27;ll just put smaller companies without enough resources at disadvantage.

Voluntary certification, please. Law is slower than technology. This is a good thing! EnergyStar is a great example of a voluntary program doing more good than DoE or FTC mandates. HIPAA is a good example of what happens when mandates can’t keep up with technology. When it comes to security, we can’t afford another HIPAA.

Many of these devices are made in China, even if designed and sold by American companies. Nearly all contain Chinese made parts. These are network devices with sensors and various behaviors. Given the tension between USA and China, especially in the cybersecurity realm - what about making the case based on US national security (in addition to consumer protection)?

I would like to add most of the IoT problem is no patches at all. The firmware they get is usually bog standard with some very minor tweaks out of china somewhere.It is a problem of vendor locked in products where you have to buy a hub to do an update. If there even is an update. If you want to get a good picture of how sideways updating can even be watch the linus tech tips on where he wanted (and has the tech ability) to patch his light switches. But could not even get them to give him the correct firmware or even say if he could. Also many devices there is literally no way to even do the update. They flash it on the line and that is the last update it ever gets.Also Supported and actually maintained in the hardware world can mean different things. So you will need to get your definitions up front correct. Supported could mean to a HW manufacture if the thing burns out ship a new one. The firmware is a secondary consideration.Another aspect you will run into is licensing. I can sell a device but may not have access to the code. Example: The vendor who makes that code went EoL on their code 5 years ago. They will not even sell me the code as they may or may not even have anyone who works for them to give it away if they could. They may or may not want to sell me that software anymore as they have a new shiny they want to sell me. So I am stuck even though I want to update I can not do it. I had one vendor flat out refuse to give me the older docs because the item was EoL and they had a replacement product that cost like 5x. That was just to communicate with the thing. Not even to update it to a later revision.

The biggest problem isn&#x27;t even new regulations. The liability for violation always tends to be a rounding error to profits. Then, even if there are teeth, there is no money for enforcement which makes it all pointless.Look at how the FTC and SEC have completely failed us in the 21st century. Better regulations would matter if we ever bothered to enforce the ones we already have.

This may be beyond the FCC&#x27;s purview, but given some of the comments (e.g., <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37393644">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37393644</a>) perhaps an entirely different strategy is warranted.Instead of trying to compel manufacturers, who may no longer even exist, to support their old products; perhaps the government should focus on protecting consumers and aftermarket vendors who update &#x2F; modify &#x2F; reverse-engineer older revisions--especially after they&#x27;re no longer meaningfully supported by the manufacturer.

Indeed, this is awesome.Not sure if you&#x27;re able to comment on this, but is there anything in place to mitigate the risk of automated astroturfed commentary e.g via LLMs in this and other cases?Edit: on the fcc docket specifically, not on HN

Thank you so much for asking HN! I can&#x27;t think of a more informed, higher signal community to interface with and get open and honest feedback from. Really brilliant idea.I don&#x27;t have much input on this issue, but I wanted to ask that if you know folks in the US Copyright Office, that you recommend the same approach to them with regards to their upcoming regulatory stance on AI.The copyright office is going to hear one-sided input from artists and the largest tech companies (seeking to build moats), but they need to broaden their inquiry to include technologists, researchers, and startups. HN is an excellent place to increase their understanding.If you can, I would greatly appreciate it if you tip the copyright office off about HN!

Thanks! I am thrilled that so many people are participating. The FCC is going to need a lot of this community&#x27;s input over the next few years as more and more devices go online.

Agreed. Thank you Commissioner Simington for reaching out to us. It makes all the difference in the world.&gt; while you likely can’t influence something like a presidential election on your ownIn fact, there is almost nothing of significance you can accomplish (or influence) on your own. We always do and always have needed to work together - and the results are astonishing: almost everything that&#x27;s ever been accomplished.

There’s some great recommendations in this thread but I just want to thank you for engaging with this community to solicit opinions from the trenches.This is really meaningful to most of us who see the regulations in our lives as something far away that we can’t influence.Another reminder for everyone that while you likely can’t influence something like a presidential election on your own, you can influence many other spheres with your knowledge and time that are closer to home and probably affect you more immediately.

How will you define the difference between IoT, embedded, and devices which just happen to be tucked away?

The best regulation is written as if it would be implemented and&#x2F;or interpreted in the worst possible way. As if it would be used by your worn enemies against you.Would manufacturers be required to brick devices that cannot be fixed in software? For example, if an MCU didn&#x27;t have a hardware implementation of a particular crypto function.Could a device be sold even if the end user had to take action in order to update the firmware? For example, would a manufacturer be encouraged to have every device &quot;phone home&quot; for &quot;updates&quot; without a method of operating in a network where outside Internet is unavailable?

Could you summarize what these &quot;security updates&quot; would entail? There are 1000s of attack vectors, so it would be difficult to practically define.It&#x27;s awfully vague to the point of just being more regulation that allows selective enforcement, which reduces competition and leads to boilerplate allowing FCC department growth, without improving the situation.It will serve as a barrier to entry to new entrants. What&#x27;s worse, is that this will create the illusion that IoT is in any way secure. Some IoT is secure, but that standard is unrealistic to apply to consumer devices.

Someone smarter than I and more versed in the legal matters should shape this concept: if you go bankrupt, your source code gets released.  I can already see some small problems with this but the general thrust is, I think, not unreasonable.

Good luck patching security problems then?

How about requiring devices to implement key security-relevant features in an immutable way, such as via FPGA, so that attackers have no way of circumventing those features even post EoS.

Good examples! I&#x27;m more familiar with 911 but I know it also contains nightmare pains in the butt (e-911 software requirements).

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&#x27;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 them by consumer devices.

Hmm I don&#x27;t know the food quality area super well but I am sure it&#x27;s hard to confirm improvements were caused by regulations and not technology, right?The idea of transparency is interesting to me. I used to agree with you that more is better but I no longer feel that way. Prop 65 in California is one example where there are stickers saying &#x27;this might give you cancer&#x27; basically everywhere and we all ignore them so often that we start worrying about cancer less. It&#x27;s not a good thing.Imo existing laws regarding misleading marketing and accuracy are probably all that we need (perhaps increased enforcement) for something like iot security updates.

Since your skepticism of regulation seems broad, it seems unfair to cabin examples to just the FCC.Why not look at the food quality changes between 1905 and today? Those have largely been won on the back of serious regulation through the FDA (and it&#x27;s predecessor), as well as labeling requirements. Both of those regulations have had significant improvements in the lives of consumers.Honestly, I have a very hard time seeing a downside to regulation that solely mandates a more transparent marketplace. The free market only actually works when an effective marketplace is possible, and that requires transparency. Without transparency, &quot;free markets&quot; are less likely to produce efficient outcomes.

Your skepticism seems ideological, rather than practical. The FCC manages frequency bands, without which most technologies that rely on long-band EM spectrum would become a mess of conflicting signals.

I&#x27;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?

For many products, I&#x27;d agree. For things that can affect public safety or shared, publicly owned or essential resources like network connections, use of radio spectrum, etc. we&#x27;ve long accepted that regulations are necessary so that the services can be available to everyone and provided safely.

&gt; If you want to make a difference, an FCC sticker won&#x27;t do it. Consumers will go for the cheaper one without the sticker. You&#x27;ll have to mandate whatever minimal level of support you want these companies to provide.Or you could respect the customers&#x27; revealed preference?

In a healthy person, caring should pretty surely imply efforts to research the topic and eventual understanding.

&gt; based on their behavior, they don&#x27;t care.Personally I see it as &quot;based on their behavior, they don&#x27;t understand&quot;We also need far more computer&#x2F;tech literacy in the education system and populace.

FWIW, I want to claim that I personally care deeply about a lot of this stuff; but, if I go to Home Depot and buy a piece of dumb equipment (such as a run of the mill light bulb or an outlet), it never occurred to me that I might have to check that there is a UL mark on it... I somehow assumed that Home Depot wasn&#x27;t allowed to sell something that wasn&#x27;t certified for at least basic electricity safety in the US.

Do you think your mother, your uncle, your niece, your sister would do the same? I don&#x27;t really buy that even 1% of the consumers will care about this label to the point of voting with their wallet on that basis.

I just don&#x27;t agree with this at all. I specifically avoid all smart plugs that don&#x27;t have a UL mark (or European equivalent mark).It&#x27;s impossible to say that consumers don&#x27;t care about a specific certification before it exists based on their existing behavior. Consumers _do not have any ability_ to distinguish on this axis at the moment. So, we can&#x27;t say: &quot;based on their behavior they don&#x27;t care&quot;. They very well might, and just don&#x27;t have the information necessary to tell.

If you think stronger action is needed, please share it through an official comment. Even if we don&#x27;t do what you suggest, thoughtful comments really do influence the rulemaking process.As an aside, it&#x27;s worth considering that there are also very sophisticated purchasers in this space, such as government and large businesses, and that a standardized, legally binding, label might help them insist on purchasing higher quality products.

Consumers consistently vote with their wallets on this, and based on their behavior, they don&#x27;t care.They will buy the cheapest devices they can find on Amazon, made somewhere in the far East, and as likely to set their house on fire as punch a gaping hole in their home computer network, when there are much better made, well-supported alternatives but they cost more.If you want to make a difference, an FCC sticker won&#x27;t do it. Consumers will go for the cheaper one without the sticker. You&#x27;ll have to mandate whatever minimal level of support you want these companies to provide.

At the very least, manufacturers should have to notify all users or via press release when a product has been compromised or can be compromised via a known attack, with maybe some required details like the severity of the breach and possible outcomes.

Yeah, I don&#x27;t operate software controlled heavy machineries, but it&#x27;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&#x27;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 surgery, but like a surgery, not without risks. I think advocating frequent updates to all types of electronics is slightly irresponsible.(Edited to add! I&#x27;m writing in good intentions but I&#x27;m not a US person, in case that matters)

I&#x27;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&#x27;s often better to have a known quantity.Especially with equipment that can cause damage or even kill people.Even if it isn&#x27;t quite that high stakes, dealing with constant random updates is a cost factor with no clear commercial gain.This doesn&#x27;t mean there can&#x27;t be updates, but they need to be done on the factory&#x27;s schedule, not on the schedule of some random supplier.

Comments against push updates and highlighting industrial applications would be a very important part of record development. I would expect industrial buyers to have very different needs from commodity consumer hardware buyers and it would be great if they (and their vendors) were represented on the record!

What 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.

Thanks for your response!To add on the &quot;label&quot; point: I don&#x27;t think labels are enough, not in a world where consumers (private, commercial and governments) primarily look at the price in purchase decisions. At least a base set of legally binding requirements must be established.ETA: I&#x27;d also love to see an exception for small scale &#x2F; startups. Like &lt; 1000 units sold per model and year. That allows quick iterations while the large offenders still have to comply.

Re your point 4 in particular, I feel your pain -- I said &quot;exposed public keys, expired certs&quot; in the OP for a reason. The current item doesn&#x27;t contemplate a requirement to tie these off as such, but I&#x27;d be interested to see if commenters ask for this as part of getting a stronger label.

I can&#x27;t file because I&#x27;m not based in the US, but I&#x27;d love to see smartphones, tablets and similar devices to be covered as part of IoT in general, as they share the most important of the characteristics - the manufacturer sells a device connected to the Internet.There are multiple issues that I think need urgent regulatory attention, and the issue classes are valid for both &quot;classic&quot; IoT devices and phones:1. Manufacturers often do not state anything about support: availability of spare parts, feature updates, security updates. Even those that do, like Google&#x27;s Pixel lineup, have ridiculously short times, and &quot;enterprise&quot; devices like my Samsung Galaxy Tab Active 3 that&#x27;s 2.5 years old don&#x27;t have spare screens available any more. I bought an &quot;enterprise&quot; device in the hope that it would have a better supply chain than consumer devices, but I was mistaken.2. Many devices with batteries are sold without the ability to easily replace them or without officially sanctioned spare parts, which causes a risk of people running devices with swollen or otherwise damaged batteries, or devices living way shorter than they could be because batteries can and do simply lose capacity.3. Many devices are completely locked down. This is particularly relevant for SSL root certificates whose expiry leads to devices being bricked, or for people who simply would like to enjoy the freedoms of the GPL and other FOSS licenses but can&#x27;t because custom firmware can&#x27;t be installed at all (due to Secure Boot) or permanently bricks features out of DRM concerns (e.g. Samsung Knox, Netflix, banking and many other apps that refuse to run on rooted or otherwise modified devices).4. Many devices&#x27; BSPs (board support packages) are littered with ridiculously old forks of stuff like bootloaders, the Linux kernel or other userland software, and the chip&#x2F;BSP vendors and manufacturers don&#x27;t give a fuck about upstreaming their changes or code quality is so bad it cannot be reasonably upstreamed.

I’m concerned about smart lights that need to connect to Chinese servers to work being peddled on Amazon.

It&#x27;s a voluntary label, so it&#x27;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.

How will the regulations keep up with evolving security best practices?

There is a high degree of ignorance pertaining to cybersecurity among the general public. Stand next to the Geek Squad counter at Best Buy and you&#x27;ll hear login credentials being freely exchanged all day.Since this is &quot;opt-in&quot; on the part of the vendors, how will consumers be educated to care about the FCC cybersecurity label to make it worthwhile?This also seems analogous to the USDA&#x27;s Organic label.

Thank you for your response, I&#x27;ll consider submitting it.For context, I&#x27;ve thought about commenting on issues in the past, but especially on the heels of the fake comments regarding net neutrality, for lack of a better way to put it I&#x27;m left feeling outgunned against such sophisticated lawyers and companies. This may be a little paranoid, but from a risk perspective I also worry about having my name attached to comments that go against the interests of large companies which dominate the marketplace. I also have hesitation about identity theft and uncertainty about the process.Again, thank you for bring the conversation home, so to speak. I&#x27;ll look at the process again.

Right now, the actual requirements for a label are totally up for grabs. This would make for a good public comment, in my opinion.

&gt; required to use the deviceThe Eufy story was blown out of proportion. Alarmist tech clickbait. There was no requirement to use the cloud. People were misled into believing their Eufy cameras were spying on them, or doing bad things, or easily hacked by anyone armed with the &quot;knowledge&quot; found in the arstechnica story and numerous repeater channels.Today in 2023, the Eufy cameras are solid, I like how they work. Zero subscription costs, local storage expansion, optional cloud storage, no cloud dependency, and the cameras keep recording if your home internet goes down. If you want thumbnails included in push notifications, then tick the box in settings where is says underneath: &quot;thumbnails will be temporarily stored in the cloud&quot;.

Has much consideration been given to labeling when a third party cloud or paid service is required to use the device? As somebody who uses IoT devices &quot;locally&quot; on my private network, I want to know my data will stay local and protected. The recent issues with Eufy doorbells claiming to be under local control [and encrypting data], but actually sending data to the cloud stands out to me as an example where labeling and enforcement could help.[0] <a href="https:&#x2F;&#x2F;arstechnica.com&#x2F;gadgets&#x2F;2022&#x2F;11&#x2F;eufys-no-clouds-cameras-upload-facial-thumbnails-to-aws&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;arstechnica.com&#x2F;gadgets&#x2F;2022&#x2F;11&#x2F;eufys-no-clouds-came...</a>

Seconding this thread. There is no reason why a device shouldn&#x27;t be servicable in 30 years regardless of whether the vendor is still in business.There might be a way to integrate these IoT regulations with e-waste regulations, where the liability for disposal, recycling, and cleanup is related to servicability.

Some sort of escrow with a dead man switch could solve this. They can reset the switch by releasing an update or affirming that they are still providing service. If no communication is received after a certain period of time, then it gets released publicly.

There&#x27;s also the problem that electronic devices last a long time -- often much longer than any manufacturer wants to admit.Vehicles, PCs, printers, and routers can easily last 10 years. Refrigerators and HVAC units can last 20 years or more. And now we&#x27;re putting &quot;smart&quot; stuff into electric circuits that should last the lifetime of the house. The manufacturer will probably go out of business long before those devices go out of service, and there&#x27;s no guarantee that there will be anyone to push one final firmware update or release the source code in the hectic last few days of an imploding business.

&gt; doesn&#x27;t it make IoT devices incredibly insecure for normal usersHow secure or insecure a device is is unrelated to whether its source code is public.Disclosure: I might be biased on this, as I&#x27;m a reverse engineer.

This is not really a solvable problem.  Whether or not your iot devices are out of support is just not something anybody has time to think about.  It&#x27;s right up there with those &quot;our terms of service have changed&quot; emails from your bank in terms of priority.

No more than our current situation. A sufficiently determined hacker can break into most IoT widgets given enough time, and decompile the firmware.The vulnerabilities exist and will be exploited either way. But with source available, we now have the possibility of a whitehat group springing up to patch them.Would you rather have no chance of ever patching exploits or giving people the ability to patch them?

This is great for hackers but doesn&#x27;t it make IoT devices incredibly insecure for normal users who wouldn&#x27;t even know their device has reached end of support?

Then they have to acquire the rights to do so for of all components before they use those components.

A competent technician with access to a workshop can make even 80 year old vehicles work. That is long past the service life of that vehicle but it can still be done, an iteration of the same technology is likely still in use today though in your car.That isn&#x27;t possible for software simply because reverse engineering is not simple, reverse engineering a small microcontrollers firmware might be possible, reverse engineering even something like old unix wouldn&#x27;t be and definitely any modern operating system wouldn&#x27;t be even though there is no legal precedent for that source code to be protected.In 30-40 years time when early windows and early DOS copyright expires do you think Microsoft is going to benevolently make that source code available? It has legally become public domain but the source code will still remain closed.How about firmware for IOT devices being installed in your house, it&#x27;s likely that that hardware can be made to work for the next 60 years but you are forced to replace it in 3 when the manufacturer decices it&#x27;s no longer financially viable to support it.

Great, then if they keep supporting the codebase internally, back-porting security patches to an older device should be easy.Manufacturing millions of widgets that go into the garbage every three years is bad and should carry heavy consequence. If the company isn&#x27;t willing to support the devices they sell, it should be possible for consumers to do it.

&gt;AND be obligated to release the full source code for the device once they decide to end support.This is unreasonable. Code is often reused in the next generation of a product. The company may not have the rights to release all of the code.

I think that IOT device manufacturers should be required to support their device for some minimum period of time AND be obligated to release the full source code for the device once they decide to end support. This also requires releasing the keys to any firmware signing mechanism or publishing a firmware update that removes such checks.The core problem is that without control of the firmware, consumers don&#x27;t really own these devices. The company can unilaterally decide one day to brick your device and force you to buy a new one. It should be obvious that this behavior is egregiously anti-consumer and anti-competitive.

It would be great for people to post an update like &quot;comment submitted&quot; on threads like this one to make sure it was entered as a comment into the official record.I&#x27;m sure these comments in themselves are helpful to @SimingtonFCC individually, but having them be part of the official record gives the FCC legal grounds to consider them and incorporate them into rules.

My two cents is that this would be an excellent comment on the record -- I&#x27;d love a discussion at the level of defining security risks to be part of the official federal commentary, because this is going to be a thorny implementation problem.

That&#x27;s the problem, there isn&#x27;t a good objective measure. Some type of &quot;reasonableness&quot; standard is usually invoked in situations like this, but that kinda just takes us back to square one: what&#x27;s currently considered reasonable in the industry is pretty terrible.

just go by past incidents. Quite often it is not software vuln that enables hacker&#x27;s attack - it is insecure default config that user never changes and manufacturer supplies same default user&#x2F;pw with each device.also insecure backdoors left by developers for debug purposes (or is it really debug or maybe espionage?)

While I acknowledge that CVE scoring of risk can be inconsistent and sometimes wildly wrong, what would you suggest in its place?

I don&#x27;t know about a mandatory update regulation -- one way or the other, that isn&#x27;t on the table right now. I would love extensive discussion on the record, however, of the costs and benefits of requiring updates to get the label.

I&#x27;m curious about your thoughts on balancing the damage of another Mirai with the damage of another SolarWinds. A regulation where every IoT device must accept a signed OTA update would make update servers an extremely valuable target for supply chain compromises.On the one hand, without updates, a world of IoT devices will inevitably get infected slowly and permanently (as long as they&#x27;re physically active).But on the other hand, with mandatory updates, a world of IoT devices can get infected all at once (in the case of a supply chain attack) and possibly just as permanently (if the attacker&#x27;s payload can disable or re-route the update system)?Do you think that prevailing security standards for IoT manufacturers are good enough that this balance falls in favor of a mandatory-update regulation?

Then fire your shitty vendor or refund your customers.Nothing will change unless everybody changes.

&gt; There are also often practical issues related to security patching embedded devices: for example, a downstream supplier&#x27;s driver can make it impossible to upgrade a kernel unless&#x2F;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&#x27;m not going to hold my breath on that one. The effect of regulation like this would make it harder for manufacturers who don&#x27;t have the market power to lean on their suppliers to provide security patches.This. We were building an IoT product that was effectively stuck on a derivative of Ubuntu 18.04; we couldn&#x27;t upgrade because vendor wouldn&#x27;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&#x27;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.

One thing that regulators need to be very careful about is how &quot;security updates&quot; 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 &quot;manufacturer must issue new releases that include any released patches for CVEs with a severity rating greater than 9&quot; would be a clear non-starter.There are also often practical issues related to security patching embedded devices: for example, a downstream supplier&#x27;s driver can make it impossible to upgrade a kernel unless&#x2F;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&#x27;m not going to hold my breath on that one. The effect of regulation like this would make it harder for manufacturers who don&#x27;t have the market power to lean on their suppliers to provide security patches.Finally, it&#x27;s important that any regulation that mandates or strongly encourages software updates also mandates that the update system itself be implemented in a secure way. This is my specific area of expertise, and I can tell you that it&#x27;s very often done very badly. A bad update system is a gigantic, flashing red target for attack. So something like mandating signatures (and sig validation) on software update images would be a good start. Mandating the use of TUF-compliant repositories would be even better.

Hi everyone, I’m FCC Commissioner Nathan Simington, and I’m here to discuss security updates for IoT devices and how you can make a difference by filing comments with the FCC.As you know, serious vulnerabilities are common in IoT, and it often takes too long for these to be patched on end-user devices—if the manufacturer even bothers to release an update, and if the device was even designed to receive them. Companies may stop supporting a device well before consumers have stopped using it. The support period is often not communicated at the time of sale. And sometimes the end of support is not even announced, leaving even informed users unsure whether their devices are still safe.I’ve advocated for the FCC to require device manufacturers to support their devices with security updates for a reasonable amount of time [1]. I can&#x27;t bring such a proposal to a vote since I’m not the chairman of the agency. But I was able to convince my colleagues to tentatively support something a little more moderate addressing this problem.The FCC recently issued a Notice of Proposed Rulemaking [2] for a cybersecurity labeling program for connected devices. If they meet certain criteria for the security of their product, manufacturers can put an FCC cybersecurity label on it. I fought hard for one of these criteria to be the disclosure of how long the product will receive security updates. I hope that, besides arming consumers with better information, the commitments on this label (including the support period) will be legally enforceable in contract and tort lawsuits and under other laws. You can see my full statement here [3].But it’s too early to declare victory. Many manufacturers oppose making any commitments about security updates, even voluntary ones. These manufacturers are heavily engaged at the FCC and represented by sophisticated regulatory lawyers. The FCC and White House are not likely to take a strong stand if they only hear the device manufacturer&#x27;s side of the story.In short, they need to hear from you. You have experienced insecure protocols, exposed private keys, and other atrocious security. You have seen these problems persist despite ample warning. People ask, ‘why aren’t there rules about these things?’ This is your chance to get on the record and tell us what you think the rules should be. If infosec doesn’t make this an issue, the general public will continue falsely assuming that everything is fine. But if you get on the record and the government fails to act, the evidence of this failure will be all over the Internet forever.If you want to influence the process, you have until September 25th, 2023 (midnight ET) to file comments in the rulemaking proceeding.[4] Filing is easy: go to <a href="https:&#x2F;&#x2F;www.fcc.gov&#x2F;ecfs&#x2F;search&#x2F;docket-detail&#x2F;23-239" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.fcc.gov&#x2F;ecfs&#x2F;search&#x2F;docket-detail&#x2F;23-239</a> and click to file either an ‘express’ comment (type into a textbox) or a ‘standard’ comment (upload a PDF). Either way, the FCC is required to consider your arguments. All options are on the table, so don’t hold back, but do make your arguments as clear as possible, so even lawyers can understand them. If you have a qualification (line of work, special degree, years of experience, etc.) that would bolster the credibility of your official comment, be sure to mention that, but the only necessary qualification is being an interested member of the public.I’m here to listen and learn. AMA. Feel free to ask any questions about this or related issues, and I’ll answer as many as I can. I just ask that we try to stay on the topic of security. My legal advisor, Marco Peraza, a security-focused software engineer turned cybersecurity lawyer, will be answering questions too. 
I’m open to incorporating your ideas (and even being convinced I’m wrong), and I hope that my colleagues at the FCC are as well. Thank you!Edit: The Q&amp;A is over now, but please keep this great discussion going without us. Thanks again everyone for your input. Don&#x27;t forget to file comments if you want to make sure your arguments get considered by the full FCC.[1] <a href="https:&#x2F;&#x2F;www.fcc.gov&#x2F;document&#x2F;simington-calls-mandatory-security-updates" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.fcc.gov&#x2F;document&#x2F;simington-calls-mandatory-secur...</a>[2] <a href="https:&#x2F;&#x2F;www.fcc.gov&#x2F;document&#x2F;fcc-proposes-cybersecurity-labeling-program-smart-devices" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.fcc.gov&#x2F;document&#x2F;fcc-proposes-cybersecurity-labe...</a>[3] <a href="https:&#x2F;&#x2F;www.fcc.gov&#x2F;document&#x2F;fcc-proposes-cybersecurity-labeling-program-smart-devices&#x2F;simington-statement" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.fcc.gov&#x2F;document&#x2F;fcc-proposes-cybersecurity-labe...</a>[4] If your comments are purely in response to arguments made in other comments, you have an extra 15 days, until October 10, 2023.

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