Because otherwise you're in the business of explaining to non-technical users how to open up ports in their NAT firewalls and do other fun things required to make the device Just Work(tm) from any Internet connection.

It's important IMO for device vendors to offer as many options as possible in that regard. Ideally it should be possible to use a given device with a paid service sponsored by the manufacturer, a free service run by anyone else, a private server running on the customer's own LAN, or with no external servers at all.

If you want to use it outside your network, then you do it the old fashioned way, by setting up a vpn to your router.

Config-by-phone or config-by-cloud is definitely the way to go for consumer gear -- see Roku or Chromecast for great examples.

Insecurely designed, networked embedded devices are a serious issue. Look at the botnet based on CCTV cameras for an example. A company that doesn't care about security is still going to produce crap devices and isn't going to update, but for a company that cares about security, ability to patch devices in the field is an absolute necessity to stay on top of vulnerabilities.

The ability to add features and keep your device 'fresh' is a nice bonus.

I can turn my dumb non-internet connected thermostat up if i'm at home, the interesting thing about a Nest is that i can turn up the thermostat before i leave work and the house will be warm when i get home. The internet connection is the value-add. If you don't like internet connected devices that's cool, but IoT devices can't have the same feature set if you remove the internet connection. the call-home is not useless. If you want to argue that certain devices don't need an internet connection, that's fine. and in many cases i'd agree. but arguing that the whole class of devices that is defined by being connected to the internet doesn't need an internet connection is pretty silly.

Meditating that through a standardised storage connector would mean the IoT apps have very little to do.

That could be something like SFTP, but there are some interesting things like https://remotestorage.io/ that allow you to write your own storage provider so decentralised apps can choose their own data store/change storage later without changing the app.

to allow a "secure" connection (plus all the snooping and reporting).

as near as i can tell, there's no way to concoct a device to run on a home network which an average consumer's browser will be happy talking SSL to.

(if anyone knows a way i'd love to hear it.)

https://letsencrypt.org/2017/07/06/wildcard-certificates-com...

DNS poison within LAN (or proper internal DNS, or even HOSTS if DIY) for .product.tld Product initiates letsEncrypt for: uid.product.tld And posts some form of identity proof to vendor, setting up a link to carry out letsEncrypt challenges.

Verification negotiated between letsEncrypt and the vendor via public resolution of uid.product.tld

Device completes cert process with letsEncrypt and installs cert to the device.

LAN now has TLS to uid.device.tld internally (via DNS spoof/poinon) and vendor hasn't seen the cert. (but, if not DIY, the vendor is distributing a DNS poisoner in their product)

() Caveat: I've still not set up letsEncrypt in the wild, so don't know it's limitations, but from the doc's the above looks doable.

The lack of ability to have a browser TLS to *.local without an internal CA or non-public root and the endpoint management to goes with either is a pain.