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?