Earlier quoted context omitted.
I want a simple device like this: 1. It plugs into the wall 2. You can plug an appliance of some sort into it 3. The device has a USB interface 4. The device has a WiFi interface 5. When I plug in the device with the USB interface, it looks like a serial device 6. The device has a very simple protocol that you can use to set it up, over the serial interface 7. You can optionally have the device join a WiFi network, a…
If you are OK with building it yourself, you could do this with an ESP8266, a USB to serial cable, a solid state relay, a power brick, and some miscellaneous things like a power cord and a socket (and ideally some case to put all this in for safety). The ESP8266 is a micro controller with built in WiFi and network stack and a serial interface, and several digital I/O pins you can use to interface to other things. Var…
More awful IoT stuff
151–160 of 245 posts
Re: More awful IoT stuff
#152The short version: they introduced terrible vulnerabilities on your network, they violated the GPL and they were also just bad at being... Overall: the hardware seems fine, the software is shoddy and the security is terrible This article begins and ends with two great tl;dr for IoT. There is value in this. Just look at the prevailing cluelessness, and be much better than that to stand out from the pack. In fact, how…
Point two comes in play only if the user experience is horrible, otherwise it's acceptable.
Regular consumers rarely think about point three.
Re: More awful IoT stuff
#153I just blogged about this yesterday. In short: > The line in the sand for me is: network vs cloud-based systems. I want things to be network connected, but I want it for my own network only. I want to be able to control my coffee pot, but only from home. If I choose to expose this over the internet, great! It's up to me to make sure it's secure. I don't want anyone making that decision for me. I also want it to be up…
>I want things to be network connected, but I want it for my own network only. I want to be able to control my coffee pot, but only from home.
and
>I also want it to be upgradeable,
So let's be super-super clear.
You do want it to be upgradeable. That means you want it to be able to be better in the future than the day you bought it. (Otherwise it's not an upgrade.)
So.
You want to be able to enjoy upgrades.
Meanwhile, are you sure that you 100% definitely want non-technical users who plug in the device and never want to take any further action, to ever enjoy the benefits of any automatic upgrade they don't need to know or touch or think about? You want to monopolize upgrades for hackers, and deny them to 99.999% of world's population, right?
You don't want devices to stay on the latest version pushed by their companies, by default? (By default).
I want to be super-clear about your thinking on this.
It's a binary line in the sand. Either devices do, or they don't, upgrade by default whenever the company decides to push a version. I don't update my version of Chrome - Google does, whenever they want. I didn't set it that way. I agree it's best practice.
Do you want to deny this benefit to all purchasers of all IOT devices? (Genuine question.)
The conclusion I've come to is the opposite one that you've come to. I've come to the conclusion:
-> The default settings should have an option "Stay on latest version. Upgrades will be applied automatically." You as a hacker can turn it off to instead get the behavior you suggest.
If the user does not disable that option:
-> By default devices should ping to see if their company wants to push an update.
-> If there's nothing to ping because their companies have gone out of business or the product is no longer supported, then they should stay on their current version and NOT stop working or be bricked. A Nest-like debacle shouldn't happen. Devices shouldn't be bricked by an end to support.
-> If the device has its ping answered it should download the update and check that it is signed with a key in its list of accepted keys, however, only if it successfully reaches a revocation server and the revocation server does not say the key is revoked. It should have a set of possible keys, and if they have all been revoked then it should never apply another automatic update. If it can't reach the revocation server it should never apply an update.
-> Since you're a hacker you can just add a file to the filesystem into the list of keys. This is fine because anyone who can read your device's filesystem in person can already do anything, such as replace the contents of the file after it has been checked, verified, and decrypted, but before being run. So this is not a vector that concerns us. This means that code-signing doesn't destroy anything of your own control over your own device, nor place an inordinate burden on you.
-> Once a signed update has been received it will just be run as root regardless of its contents.
In practice what the scripts should do is copy the current filesystem to an Updated filesystem, then use the scripts to modify the Updated filesystem. It should then issue a reboot command and the device firmware should attempt to reboot into the Updated filesystem. If successful and tests pass then the Updated filesystem becomes Current. If it fails then after a while the firmware will reboot to the old version. The device in this case (via scripts) reports to the server, by encrypting with the non-revoked key, that its update failed. It will then go back to pinging for updates as normal. The server can choose whether and when to push another update, or what other update to push. So if devices in the field are failing to update then the server operator can turn off the push of the updates and fix the problem.
That's it. This is the architecture that I envision.
What do you think? It's the exact OPPOSITE conclusion from the one you've reached. It is far, far beyond the line in the sand that you've drawn.
But your line in the sand means you want the benefits of upgrades, but you want your non-technical dad (or mom), grandparent, non-technical boyfriend or girlfriend, cousin, all the people buying the device and driving the price down for you, not to enjoy upgrade benefits.
Are you sure this is what you want? Positive?
Re: More awful IoT stuff
#154I just blogged about this yesterday. In short: > The line in the sand for me is: network vs cloud-based systems. I want things to be network connected, but I want it for my own network only. I want to be able to control my coffee pot, but only from home. If I choose to expose this over the internet, great! It's up to me to make sure it's secure. I don't want anyone making that decision for me. I also want it to be up…
Re: More awful IoT stuff
#155Re: More awful IoT stuff
#156Earlier quoted context omitted.
Well, if it's a project with lots of contributors, any one of them can sue¹. If no contributor can be identified, it's probably unenforceable, yes, though IANAL. ¹I believe there are some exceptions, like having contributed only an insignificant fraction of the whole work.
That reasoning works until the judge considers damages. Then let's say it's a small developer, not too much work, and no commercial interest in the code. Damages are limited, in western law, to, well, damages. You need to have suffered a financial loss, the other party needs to have violated the license/contract/law/... and you need to show the causal connection between the two. Let's say you contributed 500 lines of…
Re: More awful IoT stuff
#157Earlier quoted context omitted.
If you are OK with building it yourself, you could do this with an ESP8266, a USB to serial cable, a solid state relay, a power brick, and some miscellaneous things like a power cord and a socket (and ideally some case to put all this in for safety). The ESP8266 is a micro controller with built in WiFi and network stack and a serial interface, and several digital I/O pins you can use to interface to other things. Var…
Don't even need to make it yourself, Itead sells the Sonoff for $4.85 + S&H. It's an ESP8266 connected to a relay, with integrated AC-DC power supply and a properly designed, physically isolated PCB. Two caveats are that it doesn't directly have a USB plug. The serial header is exposed and you can reprogram the device with your own firmware to make it report whatever you like, but you do need a USB-Serial cable and m…
Re: More awful IoT stuff
#158I also mentioned this in a recent blog post: https://www.jsondata.io/blog/2016/iot-needs-a-cloud/ > Right now, the cloud - especially for IoT - isn't a healthy ecosystem. Your shiny new smart thermostat might as well be dialing into AOL on a dedicated landline. And unlike public services, these proprietary service providers lack long-term guarantees of service availability. > What we need is a push for openness and i…
Re: More awful IoT stuff
#159The short version: they introduced terrible vulnerabilities on your network, they violated the GPL and they were also just bad at being... Overall: the hardware seems fine, the software is shoddy and the security is terrible This article begins and ends with two great tl;dr for IoT. There is value in this. Just look at the prevailing cluelessness, and be much better than that to stand out from the pack. In fact, how…
Perhaps because the large mass of consumers only care about the first point (how the hardware looks in their home)? Point two comes in play only if the user experience is horrible, otherwise it's acceptable. Regular consumers rarely think about point three.
Re: More awful IoT stuff
#160Earlier quoted context omitted.
So everything it does, it does badly? To me, that's not 80% of the way there, that's more like -80%.
Come on, the last thing he reviewed sent everything in plaintext, had no root password, called out to multiple chinese servers, ran ssh via a hardcoded password that was something like a simple word, and didn't have any way of actually updating the code on the device. Oh, and it barely even functioned as a lightbulb... This is lightyears better than that, and yeah they fucked up a bunch of stuff, but it at least show…
It keeps honest people honest.