Hacker News Reader

> It is hard for manufacturers to do this with small teams. Mostly because they do not always have good CI/CD or platforms available to keep being on top of vulnerabilities and so on and so forth.

"It is hard for hospitals to keep their ORs clean with small teams. Mostly because they do not always have good cleaning products or procedures available to keep being on top of contaminations and so forth". I do not believe this is a valid argument to protect small firms.

> Not all manufacturers write their own software and often contract it out

Two words: liability chain. This is standard practice in almost every other industry.

I agree with the rest of your points, but I do not think that IP protections should trump regulatory requirements: if a company cannot comply with certain requirements due to contracts with their suppliers, the device should not be allowed on the market.

Liability chain in many industries is a fantastic way to build a large legal moat to prevent competition from small players.

The goal of any regulatory agency must be to ensure as much safety as can be done while preserving the ability of small players to enter the field and compete & while keeping the costs low for consumers. Otherwise, safety becomes a rationale that larger corporations are excellent at spinning to justify more regulatory moats.

A fair point. However, what are we optimizing for? An open/fair market, or consumer safety? Balance is key, but I'm interested in any counter proposals that do a better job.

Consumer safety is long term optimized by having competition. Multi-goal optimization is essential. Try to optimize for just one thing and you’ll quickly go off the rails as a regulator.

> "It is hard for hospitals to keep their ORs clean with small teams...". I do not believe this is a valid argument to protect small firms.

I think your argument here undermines itself. I have not seen an operating room anywhere but a hospital, and hospitals are big. It couldn't really be said that hospitals represent a place with small teams or limited resources. Insurance money is involved, and if you are anywhere other than America, a great deal of government money as well. This is not the picture of a "small firm".

Therefore I must conclude that you either didn't mean to put that hole in the argument, or that you did and that therefore you claim that "small firms" should not create IoT devices.

These are all great points and maybe a good reason why a voluntary program like this is the way to start, so a higher-tier of secure products can begin to emerge. We would also love to see the emergence of platforms that allow small teams to build on top of a secure, update-ready base. Some interesting discussion here https://news.ycombinator.com/item?id=37394546

> If a producer goes out of business they should be forced to give out a signed firmware that disables the key checking, then they must put up their source code for any users who wish to build and flash it themselves.

Requiring an organization to do even a small amount of engineering as it is going under is simply not going to work in practice.

IMHO the only possible way for something like this to work is to require vendors to upload buildable firmware source into a third-party escrow system before you can ship devices to customers.

Escrow doesn't really work either. You have the original code, but do you have the signing key? Is it still the correct signing key, or has an update rotated it without putting the new one in escrow? Are there different versions of the hardware that need different firmware?

The only way to know that it works is to let people install custom firmware from day one, so they can discover if they can't and raise their objections before the company is defunct.

If your team is not large enough to meet the required standards then you need to get a bigger team, not ask everyone else to forget the standards. You could make the same point about taxes, radio frequency use, etc. This is a non-argument.

>> If a producer goes out of business they should be forced to

Going out of business is a loaded expression yhat covers many scenarios.

For example if my company is acquired am I 'going out of business' ?

If I go bankrupt then my assets are sold off to pay creditors. Certainly the IP is an asset and it ultimately turns up somewhere. Releasing it before sale would be illegal in some places (disposing of assets while the business is insolvent for below-market value. )

I know what we experience are abandoned PalmOS devices, but fundamentally PalmOS is owned by a legitimate company and has some nominal value.

I think mandating requirements on the owner is a better approach. They reduce the asset value, so if it doesn't sell it could be released as public domain. But that in turn gets very complicated if there are multiple code suppliers, and the downstream goes bust, but upstream is fine.

> - A lot of blast damage can be contained if home devices use local / MDNS based service discovery as opposed to Internet based services. Many services could then either choose to reply locally or sometimes relay to the Internet if users policies allow. Unless people want other people unlocking their doors through the Internet, and they explicitly say it, Internet connection can not be mandated.

Networking ignoramus here. Are you suggesting the device could be prohibited from accessing the internet directly, and would be required to relay through a separate device (presumably with better security assurances)? Because that sounds like a good idea.

Are there off-the-shelf firewall (or whatever) products that do this already? Quarantine the IoT devices and limit them to whitelisted, curated endpoints?

Homekit tried to do this. I don’t know if they still do.

This can be done today by only advertising a ULA v6 prefix to IoT devices. The problem is the router has to now have global knowledge of what devices are allowed to talk to what services. Or the device has to work entirely locally with mDNS, DNS-SD etc.

Vulnerabilities would be virtually eliminated with better choices of programming language. Then they wouldn't need a great CI/CD system to keep on top of things, although it's obviously still recommended.