4 ms·

We're moving in that direction in the UK. There's no legislation around it yet, but the government recently published the snappily named Code of Practice for Co

We're moving in that direction in the UK. There's no legislation around it yet, but the government recently published the snappily named Code of Practice for Consumer IoT Security[1], which if rumours I've heard are correct they've basically published saying manufacturers can either voluntarily comply, or they can deal with it become legislation in the future. When I first heard about it I was pretty dubious given government's track record on regulating technology, but its actually a really solid document, covering 13 guidelines which are specific enough to be useful, while not going deep into technical detail which will go out of date: 1. No default passwords 2. Implement a vulnerability disclosure policy 3. Keep software updated 4. Securely store credentials and security-sensitive data 5. Communicate securely 6. Minimise exposed attack surfaces 7. Ensure software integrity (this is probably my least favourite guideline, as it basically says you should check signatures on all firmware, by extension shutting down people's ability to control their own hardware with custom firmware) 8. Ensure that personal data is protected 9. Make systems resilient to outages 10. Monitor system telemetry data 11. Make it easy for consumers to delete personal data 12. Make installation and maintenance of devices easy 13. Validate input data [1] (PDF) https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/773867/Code_of_Practice_for_Consumer_IoT_Security_October_2018.pdf https://assets.publishing.service.gov.uk/government/uploads/...

TeMPOraL 7y ago
Oh yes. I'd push back hard on 7. Otherwise, it's a really solid list of guidelines and I love it. WRT. 7, forcing secure boot is an overkill and pretty anticonsumer, IMO. There really needs to be a provision allowing for user-initiated software changes. If you're from UK, please let them know via e-mail to: securebydesign@culture.gov.uk. I was worried about 10 (I don't really like the vendor collecting any telemetry on my IoT devices), but the actual document is more reasonable than the headline makes it sound - it's "if you're collecting telemetry - and keep in mind point 8 - then monitor it for security anomalies".
- TeMPOraL 7y ago
  Past my edit window. I sent them the following e-mail: Hello, I recently discovered your Code of Practice for Consumer IoT Security. After reading through the entire PDF, I'd like to commend you. It's a great document, and a great initiative - nicely striding the line of being specific enough to make a difference, while not constraining manufacturers and service providers too much in technology and business model choices. It's great that such a good document is taking lead on this issue. That said, I'd like to strongly object to the point 7, "Ensure software integrity", in its current form. I strongly believe this would have a negative impact on both consumers and IoT security. As a tinkerer (or "maker") and a leader in a community of tinkerers, I value the right and ability to flash alternative software on devices I own; software both made by myself and sourced from the world of Free/Open Source developers. It's what enables people like me to derive more value from our purchases, to innovate by experimenting with them, and most importantly - to help our families, friends and random strangers with less interest in technological minutea to derive more value from their own devices, including extending their usable lifetime way past the end of manufacturer's support. Secure boot would prevent all of that, by removing the ability of end-users to modify software on devices they own. This goes against both the interests of end-users, IoT security and society at large for many reasons, including the following: - Software provided on IoT devices is typically closed-source. Homegrown/community software is almost universally open-source, which means many more skilled professionals took a look at the code to ensure it is secure against attacks and does not secretly siphon off data, personal or otherwise. - The ability to flash your own software means the IoT device lifetime is no longer determined by the lifetime of its manufacturers. When the original vendor decides to EOL the device, the community of users can still continue to provide timely security updates and feature improvements. - Extending the lifetime of devices through the ability to install custom software also means the devices take longer before they end up on a landfill, thus reducing their environmental impact. I kindly ask you to please reconsider the point 7 of your document. While its intentions are noble, its particular form is, in my opinion, counterproductive to the overall goals of the document. Please help create a future in which companies minding their users' interests can thrive, in symbiosis with a healthy community of tinkerers. Regards, Jacek Złydach
  - stoobs 7y ago
- pessimizer 7y ago
  I'm going to be very cynical and say that 7 is the only reason this legislation is being pushed, and that's the reason it's in the middle, surrounded by boringly reasonable stuff. More cynicism says that it will require IoT devices to be closed source in order to get a signature, and require government access and audit on running devices (to confirm integrity.) That may secretly be the backdoor clause. I'm probably wrong, but the UK government is fully committed to total surveillance, and the opposition either has no position or tacitly supports it.
  - rightbyte 7y ago
    How many firmwares on consumer non-PC products have you ever custom flashed? Zero for me atleast, unless we count a Xbox. If manufacturers would like to add some signature checking chip they can allready do that. I wouldn't be too cynical, unless they make it illegal to modify the firmware.

TeMPOraL 7y ago

Oh yes. I'd push back hard on 7. Otherwise, it's a really solid list of guidelines and I love it. WRT. 7, forcing secure boot is an overkill and pretty anticonsumer, IMO. There really needs to be a provision allowing for user-initiated software changes. If you're from UK, please let them know via e-mail to: securebydesign@culture.gov.uk. I was worried about 10 (I don't really like the vendor collecting any telemetry on my IoT devices), but the actual document is more reasonable than the headline makes it sound - it's "if you're collecting telemetry - and keep in mind point 8 - then monitor it for security anomalies".

TeMPOraL 7y ago
Past my edit window. I sent them the following e-mail: Hello, I recently discovered your Code of Practice for Consumer IoT Security. After reading through the entire PDF, I'd like to commend you. It's a great document, and a great initiative - nicely striding the line of being specific enough to make a difference, while not constraining manufacturers and service providers too much in technology and business model choices. It's great that such a good document is taking lead on this issue. That said, I'd like to strongly object to the point 7, "Ensure software integrity", in its current form. I strongly believe this would have a negative impact on both consumers and IoT security. As a tinkerer (or "maker") and a leader in a community of tinkerers, I value the right and ability to flash alternative software on devices I own; software both made by myself and sourced from the world of Free/Open Source developers. It's what enables people like me to derive more value from our purchases, to innovate by experimenting with them, and most importantly - to help our families, friends and random strangers with less interest in technological minutea to derive more value from their own devices, including extending their usable lifetime way past the end of manufacturer's support. Secure boot would prevent all of that, by removing the ability of end-users to modify software on devices they own. This goes against both the interests of end-users, IoT security and society at large for many reasons, including the following: - Software provided on IoT devices is typically closed-source. Homegrown/community software is almost universally open-source, which means many more skilled professionals took a look at the code to ensure it is secure against attacks and does not secretly siphon off data, personal or otherwise. - The ability to flash your own software means the IoT device lifetime is no longer determined by the lifetime of its manufacturers. When the original vendor decides to EOL the device, the community of users can still continue to provide timely security updates and feature improvements. - Extending the lifetime of devices through the ability to install custom software also means the devices take longer before they end up on a landfill, thus reducing their environmental impact. I kindly ask you to please reconsider the point 7 of your document. While its intentions are noble, its particular form is, in my opinion, counterproductive to the overall goals of the document. Please help create a future in which companies minding their users' interests can thrive, in symbiosis with a healthy community of tinkerers. Regards, Jacek Złydach
- stoobs 7y ago
pessimizer 7y ago
I'm going to be very cynical and say that 7 is the only reason this legislation is being pushed, and that's the reason it's in the middle, surrounded by boringly reasonable stuff. More cynicism says that it will require IoT devices to be closed source in order to get a signature, and require government access and audit on running devices (to confirm integrity.) That may secretly be the backdoor clause. I'm probably wrong, but the UK government is fully committed to total surveillance, and the opposition either has no position or tacitly supports it.
- rightbyte 7y ago
  How many firmwares on consumer non-PC products have you ever custom flashed? Zero for me atleast, unless we count a Xbox. If manufacturers would like to add some signature checking chip they can allready do that. I wouldn't be too cynical, unless they make it illegal to modify the firmware.