Hacker News Reader

Comment by CaptSpify | Hacker News Reader

I 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 upgradeable, and hackable. I'm willing to pay a lot of money for standalone quality devices, but nobody is supplying!

View on HN

Would you feel comfortable with end-to-end encryption via an open, documented, free protocol? This is literally my raison d'être as a company, so I'd be interested to hear your comfort level.

What I've got is a platform that 1.) makes it substantially easier for IoT developers to get their devices to market and 2.} enforces end-to-end encryption and affirmative consensual sharing. It works by running as a background service on both the IoT device and on any connecting computers. In a similar vein to IPFS, the service magically switches between local and nonlocal networks dynamically, so it doesn't matter if your interent connection goes out; as long as you have power (and a local server set up, but I'd like to add P2P capability over LAN in the near future) you're good to go.

I realize this isn't the whole device you want, but is that a starting point you'd be interested in?

That absolutely sounds like a good starting point. Any more info?

Definitely. First a disclaimer: I've held off on creating a dedicated post for this until the code is stable (as in not crashing) enough for other people to play with the demo. That will hopefully happen tomorrow, or possibly Friday. At that point I'll be posting here on HN as well as several subreddits. Until then, I'd request it not be posted on social media, so I can maximize the impact of the potential exposure.

+ Golix is the name of the protocol: https://github.com/Muterra/doc-golix

+ Hypergolix is the background service I've written to implement it, which is backed by a PaaS on AWS: https://www.hypergolix.com

+ This is a demo of Hypergolix: https://github.com/Muterra/py_hypergolix_demos/tree/master/e...

Cheers, and thanks for the feedback!

I've been debating about hooking my garage door opener up using a built-in feature so I could open the door from my iPhone. I don't trust that whatever central site I'll be connected to is safe. If I _knew_ the vendor had implemented your protocol/software well, and I _knew_ your software was safe, yeah, I'd use it. But I don't know those two things, so no way am I hooking my home's door up to the Internet...

Still probably more secure than most remote garage door openers tbh

In my case you actually do know that the vendor is using the protocol. You would have to be running the protocol on (in this example) your iPhone in order to talk to it. Everything is client-side verified and enforced by encryption.

You wouldn't have any guarantee that the garage door opener isn't also running a separate web connection in the background, but arguably unless you're actively monitoring your LAN (or just plain radio) traffic you don't have that anyways.

Put a different way, you can't prevent your manufacturer from, for example, adding a SIM card and wireless connection to your garage door opener. At some point you have to trust them.

When you say I'd have to be running the protocol, wouldn't I really be running their garage door opener app? In other words, how do I know your protocol is being used?

If they were using the protocol, they have two options:

1. Roll their own implementation (highly discouraged). Increase their development burden. Introduce higher maintenance burden. Slightly more flexibility for app deployment. And run the risk of my company disallowing interoperable embedded commercial implementations out of security concerns for the users. Basically, at this point the company is better off not using the protocol.

2. Use our implementation (Hypergolix). Massively decrease development and maintenance burden. They now have an install dependency, though, so distribution is a bit more complicated. Significant reduction in time and money invested in the app.

The critical point is this: with option 1, you're correct in that you don't know the protocol is in use, but it's extremely likely that they wouldn't be using it here, nor advertise that they were. With option two, you know that they are using it, because you have to manually install the application to run the protocol.

With #2 do I know they are using your additional install? Would your app indicate their app was a registered client and was sending commands through it?

It certainly could, as it has full knowledge of what's connected. That's quite a ways down the road though; for now we're focusing on Razpi <-> computer. Mobile deployment is much more complicated (also a much larger market though).

So totally this. I refused to buy a Nest for exactly this reason. In the words of the Cluetrain manifesto: 'We are not seats or eyeballs or end users or consumers. We are human beings - and our reach exceeds your grasp. Deal with it.'

I'm not here to be monetized by being glued to the hip to your infrastructure that may go away for any number of reasons (technical or non) and make my property suddenly stop working.

It's absurd that an IoT device contacts a server hundreds of miles away when I'm inside my house turning on my lights via wifi.

Apparently this is kind of a hard thing to handle. I battle with this and PS4 Remote Play -- about 80% of the time, RP will give up looking on my local network and go out to the internet to find my PS4... which is right here on the same network. If I cancel it and retry a few times it always ends up seeing it but man what a pain.

We've been using the term "endpoint hostile" to describe how networks are typically deployed, especially with IPv4.

"Endpoint hostile" networks are designed with a single use case in mind: accessing remote servers, usually via HTTP/HTTPS. Other use cases are prohibited or broken.

Here are some of the characteristics that would label a network as endpoint hostile:

- "Device isolation," which prohibits local LAN device communication. This is common on some WiFi networks. It's forgivable on a public WiFi but not elsewhere.

- Symmetric NAT

- Multiple levels of nested NAT e.g. consumer routers plugged into consumer routers. It's important to note that this makes everything flaky due to weird interactions and timeout behaviors. In our experience it's disturbingly common. We talked to one person whose company had at least five levels of this, requiring things like "ServerAliveInterval 10" in ssh_config.

- Lack of support for NAT hairpinning. (NAT can't NAT-traverse with itself.)

- Short NAT/firewall stateful connection timeout (120s is the RFC recommendation, but 30-60s is common and we've seen 15.)

- IPv6 absent (assuming it's available upstream) or deployed in a silly way (e.g. IPv6 NAT).

- Lack of support for local multicast or broadcast

- Aggressive edge firewall rules that prohibit UDP, non-standard TCP ports, etc. or that DPI traffic and attempt to block anything other than HTTP, SSH, and SSL.

- Badly implemented NAT ALGs for things like FTP and SIP that break other traffic.

- Lack of uPnP or NAT-PMP support.

- Mandatory proxy configuration.

- Middle boxes that modify traffic in general. This includes things that bork TCP in a misguided attempt to "optimize" it, things that inject HTTP headers (or worse JavaScript), things that modify DNS to strip A/AAAA records for "private" IPs or strip TXT records, etc.

Some of this stuff is just stupidity or brokenness, but much of it is implemented for "security" reasons.

I personally consider reliance on network edge controls for security to be a borderline-obsolete cargo cult practice, since the vast majority of today's vulnerabilities and attack vectors are unaffected by it and involve things like cloud services, e-mail, web, app updates, etc. I've worked in netsec/infosec and have seen a number of intrusions, and so far I have yet to see one in the past 10 years that was mitigated in any way by the presence of a firewall. Yet a generation of IT people thinks "firewall equals security" and I'm increasingly thinking this generation will have to just pass along.

This is exactly why the use of a remote server exists in so many IoT devices. Widely deployed home APs, even in USA, come with device isolation on by default or even not disableable.

Is there actually a good reason for this "feature" outside of airport and coffee shop WiFi?

Basically you have a 2000 mile data path to your light bulb because routers suck and networking engineers are cargo cult morons.

IMO: this is actually a good default setting. Home-router designers should assume that things are hostile by default. Of course, it should be dead-simple to turn this off as well.

I pretty vehemently disagree. We should be very reluctant to systematically break good things to protect badly written junk.

Let badly written junk burn. Then people will learn it's junk and stop using it or the developers and vendors will be forced to fix it.

Isn't it more like having a median barrier?

It's unnecessary if everyone drives competently, but it also successfully prevents people crashing through no fault of their own.

It also breaks or complicates use cases like "changing which direction you're going on the highway".

So you're in favor of Grandparents getting cryptowall from someone else connected to their WEP-encrypted wifi because screw them for using Windows XP and a cheap router? Off-switches for things like this are cool, because people who need them will find them, and people who don't won't.

This is remarkably similar to defeatable traction-control; people who care enough to figure out what that button does will push it and have fun. People who don't won't and they'll be safe.

Yes, if this is the cost. Loss of local connectivity is not a small degradation. It's like losing floating point math from your CPU or the ability of your car to go in reverse.

If we're building endpoint networks to prohibit local traffic, we are forcing a terrible architecture with terrible long-term privacy and security implications. Because of this, we will have a future where the NSA (and vendors, and advertisers, and the Chinese PLA, and ...) will literally know when you flush your toilet. In the future every interaction you have with every device in your house will be broadcast to third parties across multiple national boundaries and clouds.

... because we had to protect Windows XP machines from rare, marginal threat profiles. (Has anyone actually seen malware spread this way in the past 10 years in the wild?)

The potential criminal and totalitarian applications of a cloud-powered IoT world are incredible. Look into "nudge theory" for a starting point, and then consider things like:

http://www.theatlantic.com/technology/archive/2014/02/when-y...

http://www.ibmbigdatahub.com/blog/power-behavioral-fingerpri...

The decision of how to architect our communications infrastructure today and whether to, for example, permit local traffic could in the future determine whether or not we evolve into a borg-like totalitarian collective or a cooperative society of sovereign individuals. Communications infrastructure affects... well... how we communicate... which in turn affects every single aspect of human society and culture over very long spans of time.

It's a special case of a larger phenomenon called path dependence. Small choices that you make today based on what seem like rational reasons today can have huge differences in the long term outcome of things in the distant future. While the future isn't fully knowable, sometimes conceptual reasoning from first principles can tell us what the likely outcome of a particular path might be.

Also worth pointing out that the reason everything talks over HTTP now is because companies figured out that the only port on a typical user's computer that can be assumed to be free of bullshit pseudo-security rules is the port 80...

Sure. We've degraded the Internet from the Internet to the HTTP-to-AWS-gateway-net. Meanwhile security still sucks.

It's closer to losing ECC; if you need it you can get it and if you don't need it you don't even need to know it exists. You're being rather alarmist, don't you think?

> Has anyone actually seen malware spread this way in the past 10 years in the wild

Yup, had several IR cases (trending up) where this was determined to be the initial vector. Related: stop making this argument. Nothing is seen in the wild until it is (go back a few years and realize this argument was made about cryptowall-style malware).

I think you should re-read the end of my first paragraph; isolation should have an off switch. Give people the option and let them choose. Sorry if that's bad for your business model.

I also believe that trading real networks for supposed security would be a very bad move.

Network node security should not be delegated to the network. Not only would this necessitate forgoing very useful features that networks enable, you won't improve node security. Devices that are vulnerable by merely sharing a network with other nodes tend to have other more sever security lapses.

I agree that a button is simple way to switch between modes, but it will also make point-to-point the default. People don't change defaults, and companies will eventually cease to implement network capability as a result.

I'm all for better network security, but not at the expense of discarding the network itself.

I'm surprised that device isolation is common on home APs. Wouldn't that break some fairly mainstream things like Chromecast?

Yes. In fact, the Chromecast setup apps suggest disabling isolation if it cannot be connected to. Broken multicast support also prevents setup.

Same with the way Xbox One Streaming works. At least Sony has set up some kind of NAT traversal to allow proper remote play.

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, and you can choose to enable a simple REST web service

8. Whether you choose USB or Wifi, the device only does 3 things:

a. Tell you whether it is supplying power to the appliance

b. Supply power to the appliance, if not already doing so

c. Stop supplying power to the appliance, if not already doing so

edit:formatting

Will there be soft start, and if so do you count that as another feature?

Curious what you mean by "soft start"?

E.g. water pumps or air conditioners might be sensitive to the characteristics of the current/voltage waveforms when they first turn on.

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.

Various vendors sell small modules that couple an ESP8266 with some flash memory to hold your code. These often come with built in firmware that provides a serial interface similar to the old modem "AT" interface, but with commands for WiFi. There is a free SDK available for programming the thing in C/C++. There are several firmware replacements available. There is one that brings the Arduino environment to the ESP8266. There is one that offers MicroPython. There is one that offers Lua.

A solid state relay is a four terminal device. Two terminals are the control terminals, and two are the load terminals. Put a specified voltage across the control terminals, and the devices acts like a closed switch between the load terminals. If the control voltage is below the specified level, the device acts like an open switch between the load terminals. A typical SSR can handle AC voltage on the load terminals of well over what any standard household or office uses. The control voltage is typically around 3-30 V to close the virtual switch, which a logic one in a 3.3 V system (like the ESP8266) falls within, so you may be able to control the SSR directly from an ESP8266 I/O pin. (But you'd need to check the specs for the relay and make sure it doesn't require more current than the pin provides. If it does you might have to toss in a transistor to drive the relay).

This would be a good first project to get started in micro controllers or IoT or home automation or home sensing.

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 maybe to solder on some header pins. Also, it is meant to be spliced into a power cable - it has input and output wire terminals and not an outlet-type connector.

I have a couple of these, they're quite useful. One controlling a fan and another I spliced into a light switch to control some overhead lights.

https://www.itead.cc/sonoff-wifi-wireless-switch.html

http://tech.scargill.net/itead-slampher-and-sonoff/

This is exactly what I've been looking for. Where can I pick up some cheap adapters to get an outlet on one end and male plug on the other?

Get a power strip and a electrical enclosure from the hardware store or you can get a replacement appliance cord+wall outlet+electrical box. Also get a outlet wiring tester to make sure you wired it correctly (eg: didn't get hot/neutral/ground mixed up)

Make sure to put a 10A fuse in series, use wire rated for 10A and pass the ground wire through.

To add to this, the whole board pops out of the protective plastic enclosure with minimal effort and is pretty compact, so if you wanna build your own enclosure it's pretty easy.

You can use something like a two-prong lamp extension cable, I have one similar to these:

http://www.aliexpress.com/item/USA-Canada-2-Prong-Male-to-Fe...

Or just cut and splice the regular power cord, that's what I did with a room fan. The Sonoff has thick plastic covers for the terminals with little teeth to hold the wires in place as it's meant to be put directly in line with a power cable. Note that the relay inside is claimed rated for 10A, so I wouldn't power appliances with it. It also only switches the hot and neutral lines, so if you need a 3-pin connection you have to splice it to the line and neutral while keeping the ground line connected.

It goes without saying however that you should be extremely careful and only splice wires like this if you know what you're doing. Don't damage cable insulation while stripping, wire things up to the right connectors, don't leave exposed wires, use the correct wire gauges for your load, etc. Mains electricity is dangerous, yo.

Thanks for this. I had somehow never heard of this chip before. Link for the lazy: http://esp8266.net/

Anyone have recommendations for a relay that could handle 20A but would work with the ESP8266's 3.3V?

I've not used this, but it looks like it would fit the bill: https://www.sparkfun.com/products/13015

The datasheet says the control current is 7.5 mA at 12 V. It doesn't say what it would be at 3.3 V, so that would be the one thing I'd worry about. ESP8266 GPIO pins can source a maximum of 12 mA, so if you want to hook it up in a way that uses the GPIO pin as the current source there might be some issues.

I think to be safe, I'd just go ahead and add a transistor. That also can provide protection against a logical 1 being enough less than 3.3 V or a logical 0 being enough more than 0 V to cause problems.

You can find similar relays on Amazon for a bit less (search "solid state relay"), and even cheaper on AliExpress if you aren't in a hurry.

> If I choose to expose this over the internet, great!

And I can't even control which of my apps should not connect to the network. There are lots of fun apps e.g. games, photo editing etc. where internet connectivity is solely needed for ads. I'm OK with that. However I don't want them uploading any personal information to their servers. I wish I could stop that.

I'd argue that these guys are actually supplying. Just firewall it out to a specific network segment for these devices, have one box that interacts with it and modify it to your own liking, you have root on it afterall.

They're dirt cheap, they work, and you get root so it's completely upgradable and hackable.

Can't beat that really if you have decent security practices outside of the device.

It's definitely an investment in terms of time to beat it into shape, but it sounds like a fun weekend project to me.

heh, that's actually what I kind of do now with a couple of devices. Then I ban that vlan from the internet. I'm speaking more in general though: Too many IoT devices require cloud access to work properly. I don't want to put a hacky solution together, I'd rather things would out of the box. I don't like the idea of having to be defensive against my own equipment.

That's the part of the business model. IoT isn't about giving you some value - it's an extension of SaaS, but with the twist that it has to convince you to give service provider some value that they can then sell back to you.

Personally, I consider most of IoT products to be a waste of resources used to create them. It's a blatant promotion of shitty engineering in an attempt to get some money out of people.

The network model you describe sounds just like Apple's HomeKit.

Is that compatible with non-apple devices? I generally dislike apple philosophically, so I avoid their products.

Yes, but Homekit enabled boxes need to be licensed and apparently need a custom chip.

A look at the practicalities here: http://fortune.com/2015/06/09/ceo-apple-homekit-mess/

Or you implement a HomeKit bridge in software and use that to make non-HomeKit devices available in HomeKit, e.g. using https://github.com/nfarina/homebridge

I don't believe you need a custom chip, but HomeKit does require some advanced crypto that many low-end embedded devices probably can't support. See the dependency list for this open source Go implementation of the HomeKit Accessory Protocol: https://github.com/brutella/hc#dependencies

Edit: Missed this line in the original article:

The issue, according to Lombard, is that Apple HomeKit certification requires a co-processor to handle device authentication. That co-processor is where the device’s encryption key is stored and handles the computing associated with encryption.

Looks like (for security purposes) Apple wants a dedicated crypto co-processor. Probably a tamper-proof chip that stores a private key, similar in concept to Apple's Secure Enclave.

  > Is that compatible with non-apple devices?

Yeah, here is a list of a few products: https://support.apple.com/en-us/HT204903

HomeKit works with non-Apple connected devices like lights, switches, cameras, locks, etc. Apple doesn't actually make any such devices themselves. But as far as I know, you need an iOS or tvOS device to actually run the HomeKit framework and connect the devices together.

I applaud Apple for trying to make security for IoT devices less shitty. That said, Apple has never been able to make cloud services work well, and when they work at all they don't work on non-Apple platforms and they tend to get worse over time. So yeah, Apple's not an option for my home control needs either.

I'm in the same boat... Spent a couple years looking for a wifi thermostat that didn't require a cloud service. Actually I purchased a couple and hacked on them, but never hooked any of them up to my AC unit. Granted I had some pretty specific requirements (long list having to do with multiple zones/etc).

Not to long ago I settled for a couple of the venstar T7900's. They aren't perfect by any means, but they are light years ahead of anything else I could find. In fact they have a whole bunch of options that harken back to some of the early programmable thermostats. For example, out of the box you can control the max cycles/hour, or the number of degrees of variance from the setpoints. Buried in the menus are a wealth of options, including a few for limiting features available to "unprivileged" users. Funny enough, they can be subscribed to the power companies remote kill features, but the user is still in control and can disable the feature, which is probably why they are excluded from my power companies list of "smart" thermostats that qualify for rebates.

So, the cloud service can do a lot of things that aren't available from the published API, but running a local deamon and polling runtimes, setpoints, etc is all very straightforward, as is forcing a thermostat on/off from a server on the local network.

Anyway, that is my .02 for a thermostat that isn't owned by $megacorp/etc and can be disabled at the wim of a company that decides paying for a bunch of cloud servers is no longer in their interest.

> I'm willing to pay a lot of money for standalone quality devices, but nobody is supplying!

You could pay an amateur electronics hacker to make you such devices.

Well, I've been building my own with rpi's and whatnot. But I'd love to save time and just buy an off-the-shelf product that's been thoroughly tested, etc.

Agreed, I am following the same route. In many cases, I want my gadgets net-enabled primarily for timekeeping, since a lot of automation for me is really scheduling (and having to manually trigger things remotely is an edge case).

I have that, based on zwave devices. Can be bought off the shelf, requires some tinkering to set up usually when you want to do something that's not trivial, but is as flexible as you want it to be. Can run on raspi, there are diy sets for it etc. Ppl bitch about zwave being 'proprietary' but it's open/documented enough to be hackable to your heart's content.

Personally, I don't want to invest into a closed platform. Hackable solutions are nice, but I've purposefully avoided zwave because they aren't open source. Maybe I'm naive, but I'm holding out for something that actually is open-source, not seems to be open source.

Having never used zwave though, it sounds like your point is valid.

We're working toward some IoT developer products designed to allow global p2p connectivity for IoT devices over networks the user can control: https://www.zerotier.com/

ZeroTier already runs fine on embedded Linux, which is a large subset of IoT, and we've researched a lightweight port to FreeRTOS.

Interesting. So this would be something you set up on an existing device?

You could install it on a device and then remotely access it. The software handles a lot of complexity for you. We're working with several vendors about incorporating it as a network layer and then using our (to be released soon) SDK to allow iOS/Android apps to directly access things.

What do you think of this. I'm producing it:

https://www.facebook.com/kokonautweathersensors/

It's not using my network, but it's hackable enough that you can use it on your own network if you know how to flash it yourself.

Is it open source? that looks pretty rad. Are they available to purchase? Any plans for other devices?

What would you use this device for?

I haven't released the code for it yet, but there are plenty of tutorials online. It's using NodeMCU and a DHT11. If there's more interest in hacking the device, I can provide some blogposts or tutorial videos.

There are 5 available and 15-25 more are on the way. Please contact me if you're interested. I'm planning on selling it for around $35 and for the first few batches at $30 (as an early adopter discount). Email: antoniuschan99@gmail.com

For personal uses, I have a waterproof temperature sensor coming in, and plan to use that for my aquarium, so maybe I will produce that version. Also I am tinkering with electrical outlets that can be remotely triggered. So you can set the weather alarm to trigger appliances.

A few things:

Monitor the temperature in my office (I run a few servers)

Check the temperature outside. I'm close enough to a major city that everything uses that location, but often it's different from where I'm actually at.

My garage. Sometimes I have paints/stains/beer/etc that shouldn't be above/below a certain temperature.

I'll look at it more then email you

Cool, thanks!

Well, there's no point in waiting around for a company to make a local service their device connects to for us, since the incentive is not to deliver what we would really get the most use out of, but to deliver something that maximizes their revenue, likely though only accepting other devices of the same company, or those that have licensed access in some way. If we make a system that can be interacted with, we'll get some cheap cheap manufacturers that use it because they'll try anything, and if it catches, either we'll have a good system, or more likely, manufacturers will band together to create their own standard that's technically not as good but more likely to be supported widely.

I imagine something like the following would be good:

- Each component runs in it's own chroot/container/virt so the manufacturer can provide whatever they want, and the user can throttle it if it's poorly engineered.

- Discovery service that allows installed network server components to register with it for discovery. (Sun's RPC service, anyone?)

- Possibly also to proxy all traffic through discovery service, so network components have to specifically register for direct network access with very specific access limits if they want to use an internet service or talk to a company server.

- Separate file systems exposed for the application and stored data for each app, so a memory card card can be used for the data portion, and replacing hardware is fairly simple (after base software is installed, each application will discover it's configuration and stored data from the provided memory card). Possibly even a separation between data and config as well. IP cameras can spool all their recorded video to the data partition, which might be a large attached disk, but their config can be on a separate, easily swapped memory card, for maximum choice when upgrading.

- Let the manufacturers work out standardizing protocols for their industry, or not, and integrating with other apps, but let apps see the list of available apps, and request access to other ones, so devices from the same manufacturer or ones with a partnership can leverage each other.

- Lots of other stuff people will come up with along the way.

I imagine you could get any relatively cheap box, install the base software (linux distro of choice plus framework, or distro dedicated to this), and have it mostly work. Something like FreeNAS and similar projects.

Does anyone know of any groups out there working on something like this? Maybe some docker oriented distro that aims to be super simple comes closest?

Edit: Added another point or two.

This is a genuine question, and I think I've come to the opposite conclusion as you. You write:

>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?

>mom, grandmother, girlfriend,

But MEN can update things themselves, right.?

I've changed the phrasing, thanks. Men and women are enthusiastic users of technology.

I think your severely mis-interpreting what I'm saying.

> 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?

I never said nobody else can upgrade, or that having cloud services (for things like upgrades) available are a bad thing. What I want is a device that doesn't assume it will be connected to the cloud, and doesn't lose any usability if it's not connected to the cloud. I think the best option would be a product that has both: Cloud services, and standalone services, and "home-cloud" services that I can install on my own home server.

> 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.

I absolutely agree. By default I think auto-upgrades are a good thing. But I want to have the final control to turn those off if I want.

I actually really like your idea for how upgrades should be applied. I don't think it's the opposite of my desires though.

Thanks for this feedback!! :)

Sounds like you want better hardware. Which is what we ALL want.

Reply on news.ycombinator.com