7 ms·
If I'm a dude in my workshop making children's toys, I'm on the hook for strict product liability the rest of my life in I made dangerous toys. If I'm a one ma
by repiret 10y ago
If I'm a dude in my workshop making children's toys, I'm on the hook for strict product liability the rest of my life in I made dangerous toys.
If I'm a one man contractor building a house, certain categories of mistakes I'm on the hook for for the rest of my life.
I don't think it would be unprecedented for IoT device makers to be on the hook forever for certain categories of security flaws. It is not like security flaws grow spontaneously like rust a car. They are all in there from the beginning, whether they are known or not. Most of the IOT security flaws that I have heard about could have been easily prevented with security conscious design and development practices. If we want to have secure IOT devices, then we need to hold people accountable for making insecure ones.
- paulddraper 10y agoAnother example would be automobiles. Manufacturers do recalls and provide replaces more many, many years. Ford isn't on the hook for the Model T, but it does do recalls for decades-old Saturns.
- repiret 10y agoAlthough it is irrelevant to the point you're making, I feel I should point out that Saturn was a General Motors subsidiary, so it is not Ford that is making Saturn recalls.
- paulddraper 10y agoDammit, you're right. Gah. Well, yeah, in any case, even a defunct subsidiary (of GM, not Ford) is getting recalls decades later. High-tech has different standards than the rest of the world.
- lostlogin 10y agoOne slight difference is that people actively try to do bad on a large scale with software while toys, cars and houses can be used nefariously but short of ramming your truck into a Christmas market, the scope for large scale damage is usually more limited.
- CJefferson 10y agoChildren are continuously trying to come up with new ways to hurt themselves with toys, and if they do you can expect to get in serious trouble.
- lostlogin 10y agoChildren and the odd litigious adult maybe, but not nation states.
- cptskippy 10y agoConsumer Product Safety Litigation is huge. I would imagine there's plenty of people out there trying to find ways to hurt them selves in every way imaginable.
- JustSomeNobody 10y agoAs others have pointed out, children are always trying to do crazy stuff with their toys. But, even if this weren't true, so what? Just because software gets picked on, it should be given a pass? Um, no.
- lostlogin 10y agoNot a pass, no. However software attracts a level of attack the is pretty much out of the realms of any other industry though. A fair few countries seem to weaponise software in peacetime, and use what they create.
- mr337 10y agoThe contractor building a house has specific warranties that vary state by states (in the US). http://real-estate-law.freeadvice.com/real-estate-law/construction/contractor-warranty.htm http://real-estate-law.freeadvice.com/real-estate-law/constr...
- danielweber 10y ago> They are all in there from the beginning, whether they are known or not Some things only exist because of the environment. If I went back in time to 2001 and tried to get people to take CSRF attacks seriously, they would lose me when I started talking about opening multiple tabs. For me personally, this kind of product liability is like giving me a big bag of money, because of my profession. But this is a huge can of worms opening up and we don't even know it's going to lead to better security.
- TheSpiceIsLife 10y agoIf I'm a dude in my workshop making children's toys, I'm on the hook for strict product liability the rest of my life in I made dangerous toys. I'm not sure this is strictly true. Stanards change over time and old toys might not meet the new standards. Sometimes product recalls occur, other times the change is so broad and insignificant an advisory may be issued or no advisory is necessary. Point being it isn't always so clear-cut. With software and hardware it is possible for new vulnerabilities to be discovered as new attack methods are developed. Also, forever could be too strong. No one is going to complain about vulnerabilities in token-ring network protocols.
- luma 10y agoThe trouble with your analogy is that state-sponsored teams of children aren't working day and night to find new ways to make your toy dangerous that you could never have thought of at the time. I get that D-Link sucks, and their security practices right out of the box were "bad", but what is "bad"? In the eyes of the FTC and US law, what constitutes "good" and "bad" practice? How do I ensure that I am holding myself to those practices when a product ships? What is my responsibility for vulnerabilities found after the product shipped? Let's say for example I ship a widget with an IP address and something like Heartbleed shows up 4 years later and my device is vulnerable. Am I on the hook for patching all the systems in the field? What are my obligations here?
- throwaway729 10y ago> state-sponsored teams of children aren't working day and night to find new ways to make your toy dangerous that you could never have thought of at the time. I'm not so sure that's true anymore. Lots of kid's toys are internet-connected these days...
- oh_sigh 10y agoDid you read the article? > the FTC says the company failed to protect its routers and cameras from widely known and reasonably foreseeable risks. It sounds like they shipped the devices with known security flaws. This is not at all related to not updating your software when new security flaws are found.
- jdmichal 10y agoJust a heads up, from HN guidelines: > Please don't insinuate that someone hasn't read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that." I agree here. Your first sentence can be entirely removed and your point will still stand. Except now the receiver won't have to be in a defensive position about their reading comprehension.
- sigmar 10y ago>Am I on the hook for patching all the systems in the field? What are my obligations here? This complaint seems to have nothing to do with patching. Did you check out any of the actual text? Their complaints are about disregarding security norms from 2007 (backdoors, injection flaws), using hard-coded passwords, and posting their private signing key publicly.
- hueving 10y agoThis analogy is stupid. There is a difference between these things breaking under normal use and being activly attacked. You're not on the hook as a contractor for a house if it's vulnerable to missile attacks.
- acomar 10y agoI bet you'd be on the hook for installing a door without locks though.
- nradov 10y agoThe active attacks are the equivalent of "weather" on the Internet. It's nothing like protecting against violent crimes. If I bought a new house and the roof leaked after only 5 years of regular weather I would certainly expect the contractor to fix it, and file a construction defect lawsuit if they didn't.
- yoaviram 10y agoThe alternative to strict product liability is to make sure the IOT decide you provide has a clearly defined and enforced end of life.
- problems 10y agoThis is a ridiculous comparison - there are standards for these things, toys and buildings, provided by governments and insurance companies that you can simply meet and then disclaim almost all liability in the future. Nothing like this exists for security. No one wants to insure your product is secure, even if they've fully audited it themselves - it's too easy to miss something and make a mistake, especially so in the C-centric world. Software security is a minefield much more so than standard building codes, child safety laws or meeting the best of standards insurance companies may request of those things. The only alternative here is that we go all-in. Everyone who develops software is individually responsible for it, we all pay insurance for our ability to develop software. Because just about any piece of software can be a huge security liability. Sounds like a scary world to me, one in which I would have never gotten involved in software development.
- kefka 10y agoNot really. I can think of 2 examples that have decades-long involvement and action. Lead and asbestos. And it appears that the FTC is forming the basis of liability in software, which nearly every company doing software doesn't warranty.
- problems 10y agoWere people who made things from lead and asbestos decades earlier held liable for not knowing they would be found bad decades later? No (or at least, not to my knowledge), instead people just had to buy new things. Standards change. New security vulnerabilities are discovered. Liability doesn't stand in these cases. If you can't possibly find every security vulnerability in your product, you shouldn't be held liable for the inability to do so. You have to disclaim that, as I'm sure D-Link does.
- nommm-nommm 10y ago> Were people who made things from lead and asbestos decades earlier held liable for not knowing they would be found bad decades later? My knowledge of this is really fuzzy now (I had to learn about it for a college ethics course) but I believe that for asbestos manufacturers knew about the health hazards for years and covered it up.
- ghurtado 10y ago> If I'm a one man contractor building a house, certain categories of mistakes I'm on the hook for for the rest of my life. Should contractors that built houses in the 60s be held liable for using things like asbestos and lead paint? Should car manufactures from the 70s be held liable for using non-tempered glass and other unsafe features? What about CO2 emission standards? The topic of product safety cannot be divorced from the historic timeframe in which it is considered.
- nommm-nommm 10y ago>It is not like security flaws grow spontaneously like rust a car. They absolutely can. Its well know that cryptography algorithms "decay" over time as computer power increases. There was a time where encrypting with DES was secure, DES is no longer secure due to increase in computing power. In 50 years I doubt we'll be using many of today's algorithms. Its exactly like a car slowly rusting over time. That's even assuming support is possible. I may have a stroke so I no longer have the ability to support my product.
- rpedroso 10y agoI think the correct tradeoff is to judge the malfeasance of the product based on what security precautions were reasonable at the time the product was created. Granting that "reasonability" is a very fuzzy standard, it seems obvious that a product with 30 year old crypto should not be subject to lawsuits because someone got solved integer factorization on real hardware.
- hannob 10y ago>They absolutely can. Its well know that cryptography algorithms "decay" over time as computer power increases This is bullshit. No reasonably modern crypto algorithms has ever been broken. If you use any crypto algorithm in your less-than-10-year-old product that gets broken it's because you shipped a product with sub-standard crypto. There was a time when people thought DES is secure, but that time was in the 80s and early 90s. Nobody will blame you for bad crypto if you released software in that time.
- nommm-nommm 10y agoAnd a new car today also probably won't be rusted in less than 10 years time, what exactly is your point? >Nobody will blame you for bad crypto if you released software in [the 80s and early 90s]. So you are 100% agreeing with me. Security expert Bruce Schneier expanded upon what I said back in 1998: >Cryptographic algorithms have a way of degrading over time. It's a situation that most techies aren't used to: Compression algorithms don't compress less as the years go by, and sorting algorithms don't sort slower. But encryption algorithms get easier to break; something that sufficed three years ago might not today. >Several things are going on. First, there's Moore's law. Computers are getting faster, better networked, and more plentiful... Cryptographic algorithms are all vulnerable to brute force--trying every possible encryption key, systematically searching for hash-function collisions, factoring the large composite number, and so forth--and brute force gets easier with time. A 56-bit key was long enough in the mid-1970s; today that can be pitifully small. In 1977, Martin Gardner wrote that 129-digit numbers would never be factored; in 1994, one was. >Aside from brute force, cryptographic algorithms can be attacked with more subtle (and more powerful) techniques. In the early 1990s, the academic community discovered differential and linear cryptanalysis, and many symmetric encryption algorithms were broken. Similarly, the factoring community discovered the number-field sieve, which affected the security of public-key cryptosystems. https://www.schneier.com/essays/archives/1998/05/the_crypto_bomb_is_t.html https://www.schneier.com/essays/archives/1998/05/the_crypto_... The ironic thing is this article also said "I recommend SHA-1"... SHA-1 was broken 7 years later.
- icantdrive55 10y agoThere's statute of limitations. The bad house example, in CA, runs 10 years. Don't know about children's toys, but I bet they lobbied to hard to protect the industry. There's statue of limitations on everything except murder.