611–620 of 944 posts
Earlier quoted context omitted.
This is great for hackers but doesn't it make IoT devices incredibly insecure for normal users who wouldn't even know their device has reached end of support?
> doesn't it make IoT devices incredibly insecure for normal users How secure or insecure a device is is unrelated to whether its source code is public. Disclosure: I might be biased on this, as I'm a reverse engineer.
Earlier quoted context omitted.
I am saying that people like you are not enough to help the 99% of people who have an iot product.
Apart from Smart TVs, most people don't have an IoT device to begin with.
Earlier quoted context omitted.
This might be an unpopular opinion but I respectfully do not see it that way. I agree with promoting security for IoT devices, but there needs to be consent from the company being probed for vulnerabilities or else I find it hard to consider it legitimate research, regardless of intent. I dont think anyone would like it very much if someone came to their house and documented all the ways to rob it they could find, ev…
> I dont think anyone would like it very much if someone came to their > house and documented all the ways to rob it they could find, even if > it's for research purposes. The correct analogy would be if someone documented all the ways to rob a house that is currently mass-produced and sold on the market. And yes, as a consumer I most certainly would approve of such activity, especially if I've yet to make a purchasi…
I would not prefer someone to do it all in secret and then at the last second decide they want to inform the company.
Once such a thing gets broadcasted, there is inherent risk created for a lot of those existing owners that did not exist. Opportunistic criminals are way more common than premeditated ones.
Also if we gain the ability to monitor everyone who is currently probing houses for security issues, then if we are able to have a whitelist of people who pre-notified with their intent then we can more reliably examine people who might be looking to abuse the system.
I guess part of my underlying assumptions here is that we are moving towards a surveillance state and there are no signs of stopping that
To add to previous similar comments, I think that one of the best ways to ensure that security updates are provided is to ensure that manufacturers either commit to continuous security updates, or after a minimum sunset period during which they provide security updates (e.g. 5 years), they agree to provide source code as well as build and deployment instructions, so that the community can take over. It must be possib…
And that's on the "if I really thought business should get a handout" approach.
Practically, I see no reason the full source code for any of the network-interactive software components IoT devices shouldn't be required to be open and user-flashable upfront. I can buy pre-flashed ESPHome devices which will do wireless updates and come with the full source code and a map of how to talk to their pins (which implements the functionality) - I see no reason why this sort of access shouldn't be the default.
As a firmware engineer, I'm one of the people who actually writes the code that goes inside the IoT devices. I'm very interested in what the FCC might be able to do here. How does the FCC define a security flaw? Would updates only be distributed when there is a flaw that needs fixing? Remote update mechanisms can themselves present security problems in some domains. Thus, some devices should only be updatable if the…
Good comments. > The FCC recently issued a Notice of Proposed Rulemaking [2] for a cybersecurity labeling program for connected devices. This sounds like it is intended for consumer products, and it also sounds optional. I would hope that users with a legitimate reason to do so (defense, enterprise) would have the capacity to not participate and forego the label.
A lot of IoT companies (especially the startups) focus on the customers with the deepest pockets (enterprise and defense). If big-ticket customers demand this label, it generates a great deal of incentive for IoT companies to just say "to hell with it, we want that label on everything we make."
In any case, the words "national security" are usually a good way to get the attention of a three letter ;)
Customers should be able to return for a full refund any products that have security vulnerabilities that aren't addressed within the support period.
Companies could opt to participate in a source code escrow program where the source code for the product is deposited with a third party, and if the company goes out of business or something, the source code is released with a sufficiently-permissive license that a sufficiently-motivated user community can fix bugs themselves and distribute them (but not necessarily use the code in other unrelated/competing products unless the company is okay with that).
Companies should be required to disclose up-front any classes of vulnerability that they don't consider to be a security flaw. (E.g. a software product probably wouldn't be secure when run in an operating system that has been compromised by a malicious actor, or a network security product might not be secure against an attacker with physical access.)
Just as a matter of terminology, I think it would be appropriate to refer to software security patches as product recalls, because that's effectively what they are.
In the long run, I'd like to see a system where organizations could run something like a combination comilation/notary service. For instance, you have a server somewhere that people or companies can submit code to, and the server compiles the software and issues a digital signature for the compiled binary attesting that it compiled with no errors or warnings, and their linter couldn't find any problems. For something like C++ this might not be very interesting, but languages with stronger type guarantees might provide some confidence the program is at least not doing something that's nonsense. (Whether it's correct is a different problem than whether it's at least using memory and concurrency primitives in a sane way.) Someone might upload their code as safe Rust or Haskell or Agda or whatever, and the service could say "yeah, we're pretty sure this is memory safe and doesn't exercise undefined behavior." Companies could seek certificates from whoever the most respected compilation services are at the moment.
Earlier quoted context omitted.
This might be an unpopular opinion but I respectfully do not see it that way. I agree with promoting security for IoT devices, but there needs to be consent from the company being probed for vulnerabilities or else I find it hard to consider it legitimate research, regardless of intent. I dont think anyone would like it very much if someone came to their house and documented all the ways to rob it they could find, ev…
The problem here is that the thing I am probing is something I own: the device in my house that I ostensibly purchased and am allowed to smash with a hammer or put in a blender for all anyone should care; the context is that the DMCA is often used by companies to claim that DRM on the device is there to protect copyrights--whether music the device had access to, even if it isn't the reason many or even most people bu…
People should not have agreed to buy things where there are parts of it they don't own that they don't even need, but they did. They did it a lot because it didn't matter to them and now those devices are prevalent everywhere and it's a PITA to try to buy the type of item you actually want - where you own it entirely.
Ownership has never actually been absolute. When you buy land you cannot tear it up and make it totally unusable. If you buy a home under an HOA you may have to keep it in a certain type of order.
Maybe what we need is a law that manufacturers always need to provide a "dumb" model of their products which can be completely owned by the consumer.
However, I was speaking from a stance of acceptance that the companies are maintaining ownership of some functionality of the devices. I was primarily thinking about the way it accesses company owned infrastructure (servers and the information on them) but it extends into a grey area on the devices themselves.
You should be allowed to reasonably tamper with the device, but you should also be attempting to communicate with the company about it. They shouldn't be allowed to retaliate against you for requesting to tamper, they should need to reply reasonably quickly, and the reasons for which they are allowed to deny you should be regulated so they cannot just deny for no reason.
I am saying we need to lean in to the situation we are in if we want actual results, and I think there is a lot of room to develop a reasonable legal framework on this subject that incorporates partial ownership.
It shouldn't be as restrictive as it is today, but it also shouldn't be a complete free for all. We should at least attempt to make an effort to control security vulnerability information so criminal behavior and innocent behavior actually looks different.
As a firmware engineer, I'm one of the people who actually writes the code that goes inside the IoT devices. I'm very interested in what the FCC might be able to do here. How does the FCC define a security flaw? Would updates only be distributed when there is a flaw that needs fixing? Remote update mechanisms can themselves present security problems in some domains. Thus, some devices should only be updatable if the…
Thanks for this thoughtful feedback. I encourage you to file an official comment, especially regarding end-user control of update timing. Maybe my response here https://news.ycombinator.com/item?id=37394935 addresses some of your other concerns? We'd love to hear your thoughts.
This isn't a perfect solution but your "support their devices with security updates for a reasonable amount of time" is a non-starter. For example, suppose I'm designing a doll for the Christmas 2024 season. The doll uses the Internet because it's an AI product that converses with young children about the latest STEM news. I don't know how long it'll be used: maybe my eight year old daughter will just find it boring, or maybe she'll physically destroy the doll because she disagrees with its opinion on the Riemann hypothesis.
I can't afford to maintain firmware beyond January 2025. If I have to commit, I'll just never release the product, and children will potentially have worse learning outcomes forever. But I am willing to have my 1.0 firmware send beacon frames to cooperating routers, announcing that my combination of product ID and patch level is a8217a61-09de-4b1e-8a99-b6fbc180cdce, and please blackhole me if this is a dangerous version. This requires more engineering to work effectively, but please don't stifle innovation by small IoT vendors who cannot commit firmware-maintenance resources to a product with an unknown revenue stream.