To not control any industrial processes remotely? I hope you realize that requiring that would make solar and wind farms completely non-viable, among many, many other things.
Leased lines, MPLS, custom routing setups, hell just a VPN that fails closed. There are so many options for doing this, all more secure that just slapping a device online behind whatever router the cheapest ISP gave you.
The problem is that many of these setups are put behind essentially consumer connections, but with a better support contract or simply fitted with a 5G modem and a SIM card from the cell provider with the cheapest plan.
Building a WAN isn't magic, but it does require working with (competent) ISPs and paying the higher cost.
Seems like 95% of devices could be managed with a hardware filter that only allows through a handful of very rudimentary signals (more like Morse code than a full digital transmission), and then of course a properly designed on-device API that defines those signals and doesn't allow you to trigger a defrost remotely, when that should only ever be done with somebody physically present for example.
I'm interested to know how many "legacy" controllers no longer patched by the manufacturer are operating solar and wind farms today.
If it's a lot, maybe the manufacturers should be compelled to provide security patches if remote control is required to operate their products. For the sake of national security, of course.
That's funny, last I checked my fridge keeps food reliably cold with no internet connection, and most supermarkets have people around all the time to notice such a failure, a plan around such a failure, and expect to have such a failure periodically since fridges break down anyway.
Meanwhile you can use analog gauges if you need perfect max temperature monitoring.
That's what always pisses me off about this. Someone brought up "Hey, if we connect this to the internet to enable that feature, someone will start hacking fridges and hurting our customers, and I don't think the stupid page with a temperature graph on it is worth that tradeoff", and some ass told them to get over it and implement it.
Raymond Chen used to write about feature development at Microsoft, specifically how every single new feature idea started from a negative position, since it requires support and testing and engineering and thought, and has future repercussions, so it's often not a good idea to just add box checking features.
Microsoft believed this in the 90s. For things like UI functionality. That's the effort and thought and restraint required to have a consistent UI, for things to be thought out.
Somehow, between then and now, the industry threw all that thought away, and now everything has 400 totally unused, half implemented, utterly broken features.
Why are we here? "Move fast and break things" just breaks everything eventually. Someone, somewhere, eventually has to fix stuff.
To not control any industrial processes remotely? I hope you realize that requiring that would make solar and wind farms completely non-viable, among many, many other things.
Leased lines, MPLS, custom routing setups, hell just a VPN that fails closed. There are so many options for doing this, all more secure that just slapping a device online behind whatever router the cheapest ISP gave you.
The problem is that many of these setups are put behind essentially consumer connections, but with a better support contract or simply fitted with a 5G modem and a SIM card from the cell provider with the cheapest plan.
Building a WAN isn't magic, but it does require working with (competent) ISPs and paying the higher cost.
Remote control does not mean "has a public IP address."
Yes you might need to be able to centrally monitor and manage things but that should be happening on a private network.
A public IP address may be a necessity, but with a properly configured VPN it is irrelevant whether anyone knows the public IP addresses.
Surely, there must be a way that does not force the devices onto world wide web..
Seems like 95% of devices could be managed with a hardware filter that only allows through a handful of very rudimentary signals (more like Morse code than a full digital transmission), and then of course a properly designed on-device API that defines those signals and doesn't allow you to trigger a defrost remotely, when that should only ever be done with somebody physically present for example.
3 replies →
I'm interested to know how many "legacy" controllers no longer patched by the manufacturer are operating solar and wind farms today.
If it's a lot, maybe the manufacturers should be compelled to provide security patches if remote control is required to operate their products. For the sake of national security, of course.
If they didn't do it that way, some bad things would happen: sometimes a fridge would fail and the food in that fridge would spoil.
* Fridges are welcome to send a panic message.
* Fridges are read-only through their remote interface.
Both of these can be true if you must connect them to the internet.
You're saying remote control stops a fridge failing? Or a fail spoiling the food?
I doubt the fridge has a remote-controlled robot arm to unload itself.
I have no idea what the mechanism would be, I was just enjoying the irony of the worst case being that individual fridges would fail sometimes.
That's funny, last I checked my fridge keeps food reliably cold with no internet connection, and most supermarkets have people around all the time to notice such a failure, a plan around such a failure, and expect to have such a failure periodically since fridges break down anyway.
Meanwhile you can use analog gauges if you need perfect max temperature monitoring.
That's what always pisses me off about this. Someone brought up "Hey, if we connect this to the internet to enable that feature, someone will start hacking fridges and hurting our customers, and I don't think the stupid page with a temperature graph on it is worth that tradeoff", and some ass told them to get over it and implement it.
Raymond Chen used to write about feature development at Microsoft, specifically how every single new feature idea started from a negative position, since it requires support and testing and engineering and thought, and has future repercussions, so it's often not a good idea to just add box checking features.
Microsoft believed this in the 90s. For things like UI functionality. That's the effort and thought and restraint required to have a consistent UI, for things to be thought out.
Somehow, between then and now, the industry threw all that thought away, and now everything has 400 totally unused, half implemented, utterly broken features.
Why are we here? "Move fast and break things" just breaks everything eventually. Someone, somewhere, eventually has to fix stuff.
> "Move fast and break things" just breaks everything eventually. Someone, somewhere, eventually has to fix stuff.
That's termed Post-IPO problem. :)