5 ms·

I've dealt with this multiple times, so let me give my perspective. - It is hard for manufacturers to do this with small teams. Mostly because they do not alwa

by vkaku 3y ago

I've dealt with this multiple times, so let me give my perspective. - 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. - Not all manufacturers write their own software and often contract it out to other experts in the field. This includes firmware and app developers. - If a manufacturer goes out of business or their website is hacked or whatever, the devices are going to send information to someone else, this is a big risk. - 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. - 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. - Some of these will not be practical to get manufacturers to agree on. IP issues will arise. Following decent open protocols for firmware upgrade and sharing platform specific specs can alleviate this. One should be able to re implement open firmware for their bulbs if everything else shuts down.

bewaretheirs 3y ago
> 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.
- AnthonyMouse 3y ago
  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.
MarcoPerazaFCC 3y ago
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 https://news.ycombinator.com/item?id=37394546
tremon 3y ago
> 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.
- Robotbeat 3y ago
  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.
  - dcsommer 3y ago
    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.
    - Robotbeat 3y ago
      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.
- djha-skin 3y ago
  > "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.
Etheryte 3y ago
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.
MetaWhirledPeas 3y ago
> - 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?
- dcow 3y ago
  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.
bruce511 3y ago
>> 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.
naasking 3y ago
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.

by vkaku 3y ago

bewaretheirs 3y ago

> 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.

AnthonyMouse 3y ago
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.

MarcoPerazaFCC 3y ago

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 https://news.ycombinator.com/item?id=37394546

tremon 3y ago

> 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.

Robotbeat 3y ago
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.
- dcsommer 3y ago
  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.
  - Robotbeat 3y ago
    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.
djha-skin 3y ago
> "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.

Etheryte 3y ago

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.

MetaWhirledPeas 3y ago

> - 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?

dcow 3y ago
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.

bruce511 3y ago

>> 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.

naasking 3y ago

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.