Hacker News Reader

Comment by Mister_Snuggles | Hacker News Reader

I'd love to see the INTERNET of Things be replaced by the INTRANET of Things.

Remote access can be handled through a VPN, so there's no need for a remote server. I'm assuming that the device in question has computing hardware that's at least on par with a $9 CHIP.

What's really needed is for secure and easy to set up VPNs (to connect back to your home network) to become a thing, then the remote access problems are taken care of. After this, each IoT device's app just needs to look for the device and possibly give the user a gentle VPN reminder if it can't find it.

Of course, a VPN introduces a lot of extra work for the user. Even the steps to connect/disconnect from the VPN add enough friction that some people won't bother.

View on HN

So as a rough straw man sketch of how such a thing could work:

1. Consumer grade routers include a secure VPN endpoint. Whenever the router connects, it registers its internet-facing address with some vendor-specific DNS service under a name unique to that router but persistent at least until the router is factory-reset.

2. Devices on the local WiFi network can request a VPN access token. Optionally this requires a separate password set in the router, or pressing a physical button on the router a la WPS. As part of provisioning the token, the vendor-specific DNS name is also provided to the device. The provisioning process requires connecting back to a listening socket on the client device.

3. Devices (eg your mobile phone / tablet) provisioned with a VPN access token can then connect back in to your local network remotely. Each VPN access token is time-limited, configurable on the router but generally something in the range of 7 to 60 days. After the token expires you must connect back locally to the local network to renew it - renewal is blocked over the VPN connection itself.

4. The router interface can be used to list and manually revoke access tokens.

5. The client device can automatically connect to the VPN, eg when requested by an app for one of these IoT devices. On operating systems like Android and IOS, access to the VPN should be restricted to a specific granted permission.

I like this idea.

I honestly think most of the pieces are there. My old router, an ASUS RT-AC56U, has an OpenVPN server built in. It also supports dynamic DNS through an Asus-provided service. iOS (and probably Android) supports VPN-on-demand.

This is basically all of the infrastructure needed to do what you suggest.

The only piece missing is the easy-to-use provisioning/management piece.

It's not totally secure, but why not just a physical button that enables a bluetooth device that transfers a token?

I think you could even have a BT pin, so it would require a little security (eg, neighbors don't have your pin). It should be relatively straightforward to have a BT profile for "token authority".

It certainly would be reasonably easy to use on most devices: just press button and connect to the token device.

I think it makes more sense to use the WiFi radio, if for no other reason than adding a BT transceiver to the BOM is probably a nonstarter.

The VPN does introduce a lot of complication, what if we had publicly routable IP addresses from any network in the world and then just used default deny policies on our firewalls to secure networks and encrypted protocols to secure data?

Someone should really get to work on developing such a technology stack. /s

Sarcasm aside, I completely agree with you and as soon as someone offers iPhone/Siri level functionality in a simple package I think people will eat it up. I know the whole "personal cloud" thing is not new but as people realize the implications of putting all their data in the hands of complete strangers I think the market for such a device will take off.

Apple is in a good position to do this. Unfortunately, they keep paring down their product line and I could reasonably see them dropping the Airport products.

Maybe the OpenVPN guys can do it? They've got clients for every platform and seem to be present in some consumer-grade routers. Infrastructure-wise, iOS has on-demand VPN capability and I'm sure Android does too.

All the pieces are there, the only thing it needs (as though it's a simple problem - it's not) is someone to wrap it up in a slick and easy-to-use interface.

There are a lot of details that have to be done right. Backups in the cloud still make a lot of sense but there need to be serious guarantees on the security of the backed up data. Decentralized backups could be a solution to this but come with their own problems like can you trust your cousin and brother in law to run servers as reliably as Amazon?

I would love to see some of the features of iCloud moved into an Airport type device with expandable storage and modular hardware that I can simply swap out when it fails. I realize Siri level capabilities would take more hardware than the typical router contains but I feel like a Mac mini may even have the necessary horsepower to do the amount of cloud computing my iPhone requires in a day.

The hard parts are creating the map data to begin with and training the voice recognition but once those are complete why can't I just run them on local hardware?

I wouldn't advocate getting rid of "the cloud" in general, but I'd advocate rationalizing it.

For your examples:

- Backups - Agreed, these make sense and need the appropriate security guarantees.

- Siri - I can't think of anything it does that requires the voice recognition stuff to operate in the cloud. If this could all be done on-device, but with the ability to reach out to the cloud as required that would be cool.

- Maps - I'm torn. On one hand, it could be a local thing, but on the other hand there is a LOT of value added by it living in the cloud. Whenever my bus is moving slow, my first instinct is to pull up Google Maps and see where the accident is. It's shockingly accurate.

And some other stuff:

- File syncing/sharing (like Dropbox and friends) - Doesn't NEED to be a cloud service, this could be as simple as a USB hard drive attached to a router or as complex as a 12-bay NAS. What I'd love to see in this space is a universal API that app vendors can use - no more dealing with some apps that are Dropbox only when I want to use SugarSync or OneDrive etc. Then the storage provider would just provide an app that implements that API and everything that wants to store files in the cloud could use it.

- Email - I think what we have for email these days is really a great example of how things should work. Don't want to invest a lot of time and effort? Sign up for Gmail. You can use the web, or you can use a choice of native clients easily. Willing to put in the work? Buy a domain, get yourself a Digital Ocean droplet (or colocate a box - your choice!), and run your own.

You're right of course, the cloud certainly has great advantages and isn't going anywhere. I still struggle to find an application where my personal data needs to be sent to a cloud service to provide the level of convenience we have today.

I would rather none of my map usage or geolocation data ever went to the cloud. Yes, Google does aggregate a lot of valuable information but that could be consumed by personal devices directly instead of giving Google the ability to combine our travel habits with our eating habits and our browsing habits.

Bus arrival data isn't big or complex, Google just aggregates it which is why you go to maps but they don't actually put a GPS/Cellular device on every bus (excluding android phones >_>). They aggregate location data from the bus operator sources. I don't need to know where every bus in the United States is at every moment like Google does. I just need to know when my bus is reaching a stop near me. My home server could easily hit the same services Google does to get arrival data per stop or even just stay up to date on all the routes in my area or city.

Bus arrival data is public so there's no reason for me to store it locally but my usage of that data is personal and is something I want to own and control end to end.

Agreed.

A bear that records voices and gives remote access should not need to store data on a server. Store the data in the bear. That's the way these types of bears have always been. The only thing new here is remote access...

Storing my kid's private voice recordings on your server is just plain creepy even if you don't leave it wide open.

Sure! But in this case, part of the functionality was that friends and family could send voice messages to the bear, which are then approved by the parent in app, before being pushed to the bear.

Based on how well the company is doing, it seems like this isn't really functionality that is deserved but it does sound like the justification for storing (some) messages is reasonable.

The bear could have something as powerful as a $9 CHIP inside that could handle all of the storage/playback/approval/etc needs. The only thing missing is the remote access, which should be solved at a different place in the network.

I know HN frowns on this kind of thing, but you username gives me hope one of the CloudPets has gone sentient and is leading a revolution for IoT security. "Don't let what happened to me happen to you[r stuffed animal]!"

A VPN could create a false sense of security. After all the device is still untrusted, and will need to connect to the internet even just to do security updates.

We have good security measures for connecting to servers (which is what IoT devices are) so why reinvent the wheel? Why not require devices to have normal TLS certificates and map the internal IP address to a subdomain of the manufacturer. That way browsers can access the device using CORS, and the normal XSS protections will apply. Authenticate and authorise using a well known standard like OpenID, OAuth or JWT.

whats really needed is an actual un-fucked-with consumer grade encryption standard that is headless, touchless and on forever with no offswitch.

Alas, that wont happen either

Reply on news.ycombinator.com