341–350 of 944 posts
Earlier quoted context omitted.
Well, you can't hold somebody accountable if there isn't even a label or information somewhere saying that what they are doing is dangerous.
Sure you can. For example, we have vehicle codes that hold people accountable for dangerous driving.
Consumers consistently vote with their wallets on this, and based on their behavior, they don'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…
As an aside, it'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.
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.
Possibly weird idea: federal firmware escrow. The OEM gets to put a stamp on their product after submitting firmware source/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…
Thanks for this, Nathan. Orphaned devices pose a suite of security problems. They outlast the companies that sell them, the companies that make them, the upstream suppliers of hardware and software, the companies that service and repair them. Smart building devices and power systems can run for decades. Implanted medical devices, home health devices, and hospital systems persist longer than five years and can outlast…
With all due respect, I think the market should address this. Like UL Approval from Underwriters Laboratories, players in the market can submit their products to an organization that vets their security and sets standards about updates, product lifetimes, security incident response time commitments etc to obtain their seal of approval. Perhaps the seal has grade levels to indicate the vendor's commitment to security.…
The UL example is one where it would be hard for improved security to happen by itself. UL was founded to solve for fire risk when insuring buildings. It received funding from underwriters that would benefit from the label. I don't see any particular entity benefiting from security labels - it's a problem of the "commons" where you generally need government intervention of some sort of.
Earlier quoted context omitted.
> There are also often practical issues related to security patching embedded devices: for example, a downstream supplier's driver can make it impossible to upgrade a kernel unless/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'm not going to hold my breath on that one. The effect of regulation like this would make it harder…
Then fire your shitty vendor or refund your customers. Nothing will change unless everybody changes.
This overall strikes me as much lower priority than the currently ongoing ATSC 3.0 DRM doom. Please please please do something about this nightmare that broadcasters are imposing on the public. Don't let broadcasters take away my ability to watch live TV without an internet connection (resulting in a complete emergency broadcast system failure?). Don't let broadcasters take away my ability to record/time-shift live TV using software-based DVRs (e.g. Plex, Jellyfin), which could never possibly meet the "Nextgen TV" certification requirements!
Speaking as someone who has several cheap cameras gathering dust in a box because I no longer trust them with network access... ...manufacturers are simply never going to be incentivized to take security seriously. The best you can hope for with a regulatory approach is to incentivize them to pay more lip-service to the idea, while hiding their backdoors better. Their incentive to spy on users is simply too profitabl…
> The best you can hope for with a regulatory approach is to incentivize them to pay more lip-service to the idea While I think this is true, there's also some benefit to getting the manufacturer's to pay lip-service to the idea. In that, it becomes part of the marketing and the sales of the device. Later, consumers can _attempt_ to hold manufacturer's feet to the fire with false advertising and other fraud class act…
I would hope that this becomes relatively simple at some point.
1. I have this box that says I get updates until 2025-01-01.
2. It is 2023-09-05.
3. I have applied all available security updates.
4. Vulnerability X is still exploitable and has been made public to the manufacturer for 4 months.
5. Get full refund for defective product.
Obviously we are a long way from this. Especially 4 being hard to make a concrete rule for.
With all due respect, I think the market should address this. Like UL Approval from Underwriters Laboratories, players in the market can submit their products to an organization that vets their security and sets standards about updates, product lifetimes, security incident response time commitments etc to obtain their seal of approval. Perhaps the seal has grade levels to indicate the vendor's commitment to security.…
I like this approach, it doesn't necessarily need to be just the "market" performing the audits however. The FDA handles audits of medical software companies just fine. Focusing on the Quality Management System and their Risk Assessment/Security practices seems like a solid approach, and of course centralize this data and make it easily searchable as much as possible, and provide API access to it in case vendors like…
Maybe we need to approach it differently? There will always be an "End of Life" date. And there will always be a user using the product beyond it. So my question is: How do we make it safe? My first thought is a "deadman's switch". If a device doesn't get or see some form of a signal, it just stops updating and disables IOT features. If the user wishes it to come alive again, there's a button they can press to have i…
I am not a fan of this idea as it would only contribute to eWaste, but I think one aspect I can get onboard with is a clearly defined expiration for updates. I think we would be getting too far into the weeds to specify what "security updates" means as there will always be ways to work around the language, but the fact that a manufacturer will guarantee a certain expiration of updates would be better than where we ar…