4 ms·

IoT devices need regulatory standardization w.r.t a few things: 1. software stack – big fat "firmware" should not exist. Entire stack should be upgradable safe

IoT devices need regulatory standardization w.r.t a few things: 1. software stack – big fat "firmware" should not exist. Entire stack should be upgradable safely, securely and frequently during its official supported lifetime and should be open-sourced for owner's own upgrades past end of life. For this, the hardware stack needs some amount of standards compliance. 2. Vendor should clearly declare/advertise the period for which they will support the device. During this period the device vulnerabilities should make them liable. After this period, they should mandatorily open-source the device drivers and unlock the boot loaders to enable free software alternatives to work on them. For certain class of devices, there should be mandatory minimum period of support. 3. Networking capabilities should be legally standardized and verified/certified before being released to market and checked for continued compliance and fined if out of compliance. 3.1 Use of latest mainstream TLS with valid certificates should be mandated for all communication. 3.2 If there is outbound communication from the device, it should make it clear to which domains it will communicate with so that it is easy to allow only that through firewall and keep everything else locked. 3.3 IoT should not accept inbound communication without authentication. 3.4 Follow best practices w.r.t rollback resistant cryptographically verified secure and brick-safe software upgrades.

treyd 3y ago
> 3.3 IoT should not accept inbound communication without authentication. Ideally the user should have to specifically consent to inbound communication on an instance-by-instance basis, even from the manufacturer. There's many cases where forced updates are triggered that change/limit functionality unexpectedly. There's numerous anecdotes of people's devices being required to update to be used while they have some pressing need to use it.
- posix86 3y ago
  That's not what regulation is for though. The marker will regulate companies making bad products. Regulation should only grip where the market doesn't.
  - treyd 3y ago
    That's an overly rosy view of what markets are capable of self-regulating in a situation where network effects are very strong and it's difficult to stop being a customer once you are.
MarcoPerazaFCC 3y ago
These could be great suggestions for the criteria a product must meet to quality for a label. I encourage you to file an official comment with your thoughts.
basch 3y ago
I wrote elsewhere, but a standard/compatible requirement for a rolled up management dashboard. https://news.ycombinator.com/item?id=37395102 https://news.ycombinator.com/item?id=37395102 I dont want 30 semi/unmaintained apps to manage each manufacturers security settings.
wpm 3y ago
In regards to 3.2, I'd like to propose 3.2.1, where a smart device manufacturer must clearly label and explain that A. their device requires a connection to a cloud service, and if so, what for and what data is sent/transmitted, and B. what functionality, if any, remains if you refuse. I have a Winix air purifier that has a sensor and filter lifetime suite that I cannot communicate with because it refuses to connect to my "IoT" SSID that has no access to the outside internet (no, you stupid piece of crap, my WiFi is working fine, now just start sending data damnit).
KyleBerezin 3y ago
I hate all of these well intentioned ideas, just like I hated when apple forced <1 year certs. All of this is in service to online devices, and completely screws devices intended to operate over lan only. I find security and peace of mind by blocking a devices access to the internet, but these changes mean that every single trinket that talks over the lan needs a whole boatload of suspicious looking internet traffic. It also makes it so you can't operate devices in offline networks. (this is already a thing due to apple's cert changes)

treyd 3y ago

> 3.3 IoT should not accept inbound communication without authentication. Ideally the user should have to specifically consent to inbound communication on an instance-by-instance basis, even from the manufacturer. There's many cases where forced updates are triggered that change/limit functionality unexpectedly. There's numerous anecdotes of people's devices being required to update to be used while they have some pressing need to use it.

posix86 3y ago
That's not what regulation is for though. The marker will regulate companies making bad products. Regulation should only grip where the market doesn't.
- treyd 3y ago
  That's an overly rosy view of what markets are capable of self-regulating in a situation where network effects are very strong and it's difficult to stop being a customer once you are.

MarcoPerazaFCC 3y ago

These could be great suggestions for the criteria a product must meet to quality for a label. I encourage you to file an official comment with your thoughts.

basch 3y ago

I wrote elsewhere, but a standard/compatible requirement for a rolled up management dashboard. https://news.ycombinator.com/item?id=37395102 https://news.ycombinator.com/item?id=37395102 I dont want 30 semi/unmaintained apps to manage each manufacturers security settings.

wpm 3y ago

In regards to 3.2, I'd like to propose 3.2.1, where a smart device manufacturer must clearly label and explain that A. their device requires a connection to a cloud service, and if so, what for and what data is sent/transmitted, and B. what functionality, if any, remains if you refuse. I have a Winix air purifier that has a sensor and filter lifetime suite that I cannot communicate with because it refuses to connect to my "IoT" SSID that has no access to the outside internet (no, you stupid piece of crap, my WiFi is working fine, now just start sending data damnit).

KyleBerezin 3y ago

I hate all of these well intentioned ideas, just like I hated when apple forced <1 year certs. All of this is in service to online devices, and completely screws devices intended to operate over lan only. I find security and peace of mind by blocking a devices access to the internet, but these changes mean that every single trinket that talks over the lan needs a whole boatload of suspicious looking internet traffic. It also makes it so you can't operate devices in offline networks. (this is already a thing due to apple's cert changes)