That's what insurance is for. Something like this was discussed in my torts class in law school, except that was long before IoT devices existed so it was about things like lawn mowers.

The idea is that it might make the most sense economically to make the lawn mower manufacturer liable when users cut off a finger or toe, even if it was due to consumer stupidity instead of any negligence on the part of the manufacturer, because the manufacturer is in the best position to estimate the risks and purchase insurance to cover them.

Presumably, the manufacturer will pass on the costs of those insurance premiums to the consumers. The manufacturer still has an incentive to try to build safe mowers, because if their insurance company ends up paying out a lot the premiums will go up. They can pass those higher premiums on to the consumers, of course, but that will make them more expensive than their safer competitors.

The manufacturer is in a good position to deal with insuring for these injuries because they know how many mowers they are selling. Other candidates have less useful information. For example, a consumer usually has no idea what their chances are of suffering a lawn mower accident, so have no idea how to decide how much insurances is needed. Health insurance companies will have a good idea in the aggregate of how many of these accidents occur in a year, but they have no idea which of their customers use lawn mowers.

Done right, this should not hurt a market much.

I'm not sure it could work for IoT, though, because a lot of IoT devices are made by new companies that probably will not be around long. With things like lawn mowers, you could takes years to get around to cutting your hand off, and still reasonably expect the manufacturer to be around. Not so with a lot of IoT devices.

What are the outcomes for using insurance, and what are the outcomes for using regulation? Does anyone know the answers in a technical policy sense (not in a philosophical sense)? They are different tools useful for different problems.

Thinking out loud, insurance seems like a poor solution when people will suffer serious, irreparable harm. If the lawnmower severs a foot, then an insurance payout isn't really sufficient; regulations should prevent that from happening in the first place. More broadly, my point is that there are larger issues than economics.

> Presumably, the manufacturer will pass on the costs of those insurance premiums to the consumers.

In economics, that is not the case. Businesses don't price goods at 'cost-plus'; they don't look at their costs and add a profit margin. Think of the soda at the movie theater on one hand, and on the other the car being sold at a loss because the market is soft; think of software. Like all businesses, the lawnmower manufacturer already is pricing their product at the level that maximizes total sales revenue, which depends on supply and demand; raising the price will reduce revenue (probably because unit volume will decrease too much to be compensated for by per-unit revenue increase). If they could raise the price and bring in more revenue, they would have done that already.

There is an issue of elasticity: If your customers' alternatives are limited - i.e., if they can't go without your product, if there are limited competitors and substitutes - then you can raise prices more easily. A Van Gogh painting is highly inelastic; lawnmowers are much less so.

What isn't being mentioned here is that insurers will require insured companies to do a bunch of stuff in order to remain insured. Have some processes in place, do some things, and so on.

Just like your car insuruance isn't valid if you drink and drive, your software company insurance might not be valid if you aren't using source control and have no testing or code review proccess.

So in some ways, what you get out of insurance is market driven 'regulation'.

Possibly, because a rival insurance company can impose different conditions, insurers are incentivised to require only the stuff that really reduces risk, while regulators might make irrational regulations driven by moral panics in the press. Similarly, they might be more responsive to supporting new technqiues that reduce risk at lower costs, because customers will seek out an insurer that lets them use those.

Possibly, insurers are less suceptible to moral hazard, where regulator employees have close relationships with industry heavyweights and make policy that helps their buisness, at the expense of consumers and sector rivals. Insurers mostly want to make money.

Regulators might be better sometimes because their staff tend to be very mission driven (they want to fix the problem, not make money). They will get a kicking from the public if there is a big accident and laws and regulations did not prevent it, while an insurer is only punished if they don't satisfy current law. So a regulator might be more proactive.

I'd only add that the insurer's incentive to reduce risks to their profits is not always aligned with consumer's risks. As a simple example, the insurer may require the vendor to have consumers sign away their legal rights to reduce the risk of expensive lawsuits.

Bad question, false dichotomy: these are not apples-to-apples comparisons. How about some minimal regulations that include an insurance requirement?

So I agree: yes, the existence of tort law sometimes obviates the need for regulation; but has hardly banished regulation or the need for it entire!

Eh, more or less. Increases in the price of supplies sometimes do lead to an increase in the end price of consumer goods. I agree that this is more likely to happen for inelastic goods, though.

This is the problem.

And "solutions" like that can easily backfire, because they squeeze medium sized companies out of the market, who might stake out a middle ground between $20,000 Cisco hardware and $150 "disposable cameras" from Fly By Night Corp, by charging $200 for a product that actually guarantees patches for a specific number of years.

Because the liability risk raises the price the middle-ground company has to charge to the point that they can't compete with Fly By Night Corp who doesn't care. Which means more sales of insecure garbage products, because the customer no longer has the option to buy an affordable product that receives patches, and that customer can't afford the $20,000 industrial grade product, so more people end up with the insecure garbage.

It would be much more effective to just require manufacturers to provide security patches for e.g. 7 years. Fly By Night Corp still wouldn't do it, but then at least Samsung would.

Freedom Markets™ are best served by binding arbitration.

My comment about this got 0 attention though...

If we regulate insurance so that a product needs to be backed by a 10-year liability insurance, it might have 2 good outcomes to fix this:

1) the insurance company might ask a lot of hard questions and require audits, plans, etc 2) the insurance company might require escrow to the iot device's update mechanism in case of bankruptcy, so they can remote-brick the devices

It's unlikely that the reality would be so rosy though - mainly the claims against the insurance would likely be too small in many cases. It might help in 10 years against the biggest ddos botnets. Not nearly as good as direct regulation.

It sounds great if I'm MegaCorp with an entire department for dealing with this stuff, but as an independent developer trying to start something it's a horrible idea.

That might help the readers of HN, but not users in general. Most users won't bother installing security updates for their PC if it's not forced on them. Updating one's light bulbs with something off github is a non-starter.

Edit: To complete the thought, it's not generally that hard to flash devices that support it, so a report that says "X,Y and Z have exploits, here are some options" could go a long way. Making devices support some minimum standard of local upgradability would help immeasurably.

Who's going to update the firmware in your light bulbs using a patched open source version of the manufacturer's code?

Edit:

> it's not generally that hard to flash devices that support it, so a report that says "X,Y and Z have exploits, here are some options" could go a long way. Making devices support some minimum standard of local upgradability would help immeasurably.

You're right, it's not hard. But can you imagine regular users doing that? Anti-viruses, Microsoft, Apple, Google and all major browsers had to automate and force updates on users to keep devices secure.

I have a hard time believing that any significant portion of users will flash updated firmware onto IoT devices to fix security vulnerabilities. Heck, when was the last time you checked for firmware updates for your home router? I do this stuff for a living and I don't think I've updated my (current) router's firmware more than once in the last few years.

If you've already got a database of router versions, it's not hard to include how to submit a new firmware version in that database, whether it be a POST URL, any params and the expected payload(s) or a TFTP upload. At that point, the same device that generated the report could give you a management page that listed some options and semi-automated the process. Want to update fridge with out of date/exploitable firmware with community fridge firmware X? Click here. Want to update with community firmware Y? Click here. Want to update to newer/latest proprietary firmware? Click here.

I do agree it's not a solution to the problem. But it might help. It would also allow your techie friend to run an app on their phone or laptop when they come over and let you know, or handle it for you with a minimum of fuss.

This problem won't ever get better until someone starts being held accountable for exploitable network attached devices. I think part of the reason that doesn't happen is because it's not feasible with current norms of behavior to expect producers nor consumers to do so with any level of confidence. Providing tools for this may take us one step closer.

Personally I think a blend of regulations will be required. If devices sold are required to be updatable in one of a few ways, and workable firmware open sourced if obsoleted (or clearly marked or all labeling as may be entirely unsupported after 20XX), then it becomes feasible to require users to have some level of accountability over what they put on their local networks. I think it's the same as cars and the public road system. Cars have to adhere to certain standards to be street legal, and car makers must adhere to certain standard to sell their cars as street legal.

> Heck, when was the last time you checked for firmware updates for your home router?

Every 6-12 months, generally when I'm checking why performance is bad at the moment. But I'm not getting a report, so I only check when it's on my mind.

Ideally we would have this suggestion in addition to a stick to ensure people have an incentive to sell relatively secure hardware.

Try walking into Home Depot and asking the salesperson how to update the firmware on the lightbulbs he is selling. You will get your sanity questioned, especially once you explain _why_ it is important to update.

We have them for practically everything. End users can't figure it out, the manufacturer (say Microsoft) doesn't give two craps, so a third party (>90% of my career) involves solving those problems for users.

If things were open sourced, that'd make my job insanely easier in terms of man hours invested in any project.

I've literally had to spend >100 hours diagnosing that Dynamics CRM 2013's main data import tool has a bug that they refuse to fix. (Ever since it launched.) The import wizard refuses to actually load TIMESTAMPS (as well as some other columns) in even though it specifically supports setting that column. So when you do a data import, ALL of the user's data is out of order. That's completely unacceptable for any business to have their e-mails, notes, all have the same timestamp and no proper ordering. So "all" you have to do is first diagnose that this is the problem, then find this super obscure website where a guy made a fix except his code is half completed and full of errors, then install the entire CRM SDK stack. Learn how to write a C# plugin that exploits the CRM SDK. Write the corrected version of this guys code. Compile it. Use the CRM SDK toolkit to "attach" the plugin to your CRM. Figure out (no docs) what messages/events the plugin is supposed to actually trigger on with no error messages (while it takes >5-10 mins of user input every test to find out if it worked and then remove all the data again from the DB.)

If that was open source, that'd be a one line of code fix and I wouldn't have to play the "prod the black box" game of trying to figure out exactly where the failure point is. Hell, just adding a debugger would be insanely powerful. And that was just "one" story I have with "one" product that I support out of dozens if not hundreds.

So that's the thing. Regardless of whether a manufacturer open sources or not, people like me still have to fix the damn problem. Failure isn't an option. The checks have to go out. The lung machine has to keep blowing. And whether or not the business makes it easy or hard, doesn't enter the equation (except in terms of cost and man-hours). Nobody cares that you want to protect your IP. They care that their damn time clock doesn't work and they've got millions of dollars of product to ship while their employees stand outside of a locked automatic door.

So the real question is simply: Do you love, or hate, the people who support your software? Because we're still here, every day, slogging through insane problems by poking blindly in the dark. Closed source software breaks just as often as open source. The difference is, that the essential third-party (me) has to bill 10X as many hours to fix the problem. So if you're a business, it's in your best financial interest to demand open-source code whenever not prohibited (security constraints, HIPPA, whatever).

Closed-source is like buying a car and pretending it'll never break down, or that the manufacturer has the time, energy, and willpower to come down to your house and fix it. Some might go that far. The other 99% won't. And if there's a piece of software that has zero bugs, I haven't seen it in my lifetime.

So to bring this back to IoT. When a clients IP Camera goes down, they don't give a crap why. They need it back up. Yesterday. And they especially don't appreciate buying expensive hardware that ends up having security flaws... and worse... that is physically impossible to close. The clients aren't going to easily understand, "I paid $3,000 for it, and it works fine, but I should NEVER use it because it could be hacked?" That's like buying a car and a recall hits that says "the locks no longer work" and instead of fixing the locks, or allowing a third-party to fix the locks, everyone is just supposed to stop driving their car. You'd never see that in the real world, but somehow "software is magic" so it plays by different rules.

Or at least, an even more modest regulation, simply allowing all consumers to hack their own devices without fear of violating any laws.

More simply, they could make all reverse-engineering legal, but then the copyright/IP lobby would strongly oppose.

Unless said regulation was the ability to actually own your device and install your own firmware, doubly so once it becomes unsupported?

They probably don't even have the (usable) source code.

https://www.arm.com/news/2017/10/a-common-industry-framework

Put pressure on ISPs to make them take responsibility for traffic originating from their networks. They have the the tools to notify customers if customer is sending suspicious traffic (and if necessary, they can temporarily shutdown the connection).

Copyright law is not in agreement with this. Reasonably, a manufacturer could argue that follow up installments of the software are still actively sold. Then one question is why the fixes wouldn't be ported back to the old release and I guess because differences in the code require significant effort to adapt the fix.

Regulation should seek to equalize ...

> manufacturers liable for the damages caused by security holes in their devices

This is not easy if a chain of bugs in different programs is used to create an exploit. And it would be damaging to warranty wavers especially in open source. After all, the server side will likely run full fledged open source stack. This is where service providers step in. Google would probably like to do monitoring and instrumentation as a service, among others.

What reasonable case is there for making them not liable for the damages caused?

After what period of time? Microsoft updated Windows XP after the official end-of-life of the OS for consumers with the patch to the Samba protocol to prevent WannaCry, but if they hadn't bothered, would they still be liable? Should they?

Are they obligated to update pirated versions of their OS?

Is the manufacturer liable if they release a software patch but the product owner doesn't apply the upgrade? What share of the liability should each party take?

Software is largely immune to liability litigation in the USA because the current legal status of it is not legally "a product". Converting it to "a product" for the purposes of liability is a major sea change for our understanding of what business models can be applied to software, licensing, ownership, etc.

Also, does the average product programmer carry some sort of programming insurance? Are we going to force every web developer and every open source programmer to carry insurance, to be licensed to program, and to live up to specific ethical standards?

I'm not saying these are undesirable changes, just that they are changes and there are a ton of issues programmers don't foresee that should be discussed before making

Surely the right idea in principle, though. I'm just not sure how realistic is it to implement in a smart manner.

It's interesting to see how the US citizen ordering the product of a back alley company in Shenzhen via Alibaba is supposed to recoup his damages. It's impossible, period.

With wired IoT devices: segment your home network, always use a trusted gateway application and never allow your IoT devices direct WAN access. With wireless devices, all bets are off, since you don't know at all who can access them (i.e. they can interpret WiFi frames in unassociated state directly in silicon, and you'll never now, even if your stack is completely open source) if they are in the vicinity.

Then they will sell two versions of the same product. One lets you voluntarily waive that requirement for the same price as today, or a "normal" version where it costs orders of magnitude more.