Hacker News Reader

Comment by ilc | Hacker News Reader

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 it "Check for updates" if there are none, it tells the user it is at "End of Software Updates" and "Certain services will be disabled." etc.

We can't stop the issue. We can decide what to do once a vendor decides to stop updating... and make sure that final revision is as safe as it can be. Preferably non-networked (including bluetooth etc).

View on HN

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 are now. If a vulnerability is discovered before expiration, presumably it would give the market and consumers leverage to hold the manufacturer's feet to the fire.

I think no nonsense update expiration dates is a very easy win.

Bricking the device after expiration or if it can't communicate is just a non-starter for me. Many devices can find a second life if manufactures were incentivized to open their hardware vs close it. Under a brick after expiration scenario I worry manufactures will be incentivized to lock down or prevent tampering to avoid exposure to torts that this rule might open up.

How would opening up the hardware solve the issue for the average consumer? Let's say the official update channel goes dead on your smart fridge, the company has gone out of business. What would happen in that scenario for the average consumer (not someone who posesses the skills or will to tinker around with the firmware and such)?

My comment is more about not incentivizing locking down hardware vs incentivizing opening it up so I can't speak a lot to your questions.

> How would opening up the hardware solve the issue for the average consumer?

At the risk of going off-topic, what I will ask you is, why do you feel that opening hardware requires a consumer have special skills? I'd argue that open hardware wouldn't have to limit adoption to those who possess the skills. I think requiring special skills is a bug because currently manufacturers don't even consider the idea of a second life for products.

I'm not saying that hardware shouldn't be open in some form or another (at least in a way that doesn't stifle innovation, maybe also taking another look at how the patent system works and such).

I guess I'm just having trouble visualizing how this problem gets solved for the average joe consumer in a world where hypothetically the hardware is open. Who pushes the security patches out to the devices? All of that has a cost in terms of bandwidth, maintenance, etc. If it's a community effort, what happens when the device gets old enough where no one is really working on it anymore, no more community updates, people have moved on, etc. How does liability work in a world with community-driven updates? What happens if a buggy community update is pushed and the smart fridge malfunctions and causes a flood / damages? What about supply-chain attacks and such?

I guess for the code-literate subset of consumers, they can just go to the github repo and see exactly what is changing and where, but for the non-code-literate consumers, how do they know what kind of updates they are getting from the community?

What about a middle-ground option? Where towards the end-of-life for the product, you are asked a question if you want to switch to a different update channel than the manufacturer default, and if there is no response recorded after X amount of days or whatever, the device just bricks itself?

I don't want my TV to "expire". I want to be able to use it with a gumstick if I still like it!

I think of IOT devices as a continuum:

One one end, Alexa and friends, which is a brick without Amazon. Good luck fixing that in a real way.

On the other, a washing machine. It'll wash clothes for 10-15 years, just fine. It may only get security updates for 5... but who cares. So it can't tell me by app when my clothes are done, it is still very useful.

TVs, Cars, etc... all fit on this line in a way.

And remember: People will use these devices past their expiry. They will get rooted, and turned into botnets and other crap. We have to choose our evils. I merely want a safe device at the end. Regardless of how long or short it lives.

> On the other, a washing machine. It'll wash clothes for 10-15 years, just fine. It may only get security updates for 5... but who cares. So it can't tell me by app when my clothes are done, it is still very useful.

> TVs, Cars, etc... all fit on this line in a way.

Sure but you are missing an entire category of devices that revolve around home automation. Think light switches, dimmers, faders, plugs and door bells. These types of devices have an interface but also need IoT to be useful but not necessarily the cloud. If I install something like this in a light panel, it seems a little odd to me to "kill the IoT" of the device. It loses tremendous value. Again think of the incentives. Should we be incentivizing manufacturers to create devices that can so easily be created that lose value that I may have invested in as a part of a renovation?

Can we create/incentivize an ecosystem of IoT devices that can live without the manufacturer tying these devices to a cloud service or the Internet in general?

Let's find ways to incentivize second lives vs another renovation 5 years from now when my light switches and outlets no longer get updates.

It is a continuum. Your light switches are close to the Alexa side of it alas.

Yes, we should. But alas, the incentives run the exact reverse today. Today they get to monitor your usage of the lights, resell the data, etc.

You are part of the product.

OTOH: If I look at this as a vendor, where else where the light switch go for updates?

I'd be VERY hesitant to direct wire any IOT device into my house, if I wasn't comfortable ripping it out in 6mo, when the company decides to desupport it and kill the app.

For me this is a the exact opposite problem: I won't adopt until I know that these issues are ironed out, or I accept that the device is 100% disposable.

There's cases where I can't avoid it, TVs, Cars, etc. It is pushed on me, like it or not. For those, I truly do want safe mode, so I can pick how it networks.

To me this generation is lost. I accept that. It is sad. I want to win the NEXT one, or the one after. And only by making the life cycle EXPLICIT will we do that.

When a customer goes into Home Depot and says "My lightswitch stopped working in 2 years, you got something that will live longer this time?" The problem is self solving.

IMHO the biggest problem is that there is no end-of-life date made clear to the user. I think if the purchaser could clearly see the support lifetime on the box then they can make an informed decision. Maybe this model that costs 50% more but is supported for 10y rather than 2 is a better deal after all.

I don't think we need to kill the device. Ideally it would somehow be made clear to the user when it drops out of support. But I would rather have the consumer informed and capable of making a decision than taking away their control to keep using the device.

I never said to kill it. I said to kill it's IOT functionality. There is a very big difference.

Think of a washing machine. It'll still wash clothes... it may not ping the internet portal anymore, it isn't "safe".

Reply on news.ycombinator.com