3 ms·

> Missing from your quote: The alternative is freedom. Philips doesn't have to lock their devices. > If Philips (and other companies, obviously this doesn't rel

by cryo 9y ago

> Missing from your quote: The alternative is freedom. Philips doesn't have to lock their devices. > If Philips (and other companies, obviously this doesn't relate to just Philips) would provide a community access to their devices and software rather than locking them out, I believe that this problem would not exist. The problem is technical and won't be fixed by just opening the software. > There are plenty alternatives of securely interacting with an IOT device. Please name just one which works for webapps, beside HTTPS. > So if vendors are annoyed with browser warnings, it's because /they/ are doing the wrong thing, not the browsers. Homekit is nice but not available to webapps, apps of course can take advantage of several security mechanisms. My whole rant is about browsers and HTTPS in non public networks. For webapps which want to talk to IoT devices there is only HTTPS and there is _no_ sane way to provide robust, local!, access to a LAN device via HTTPS. Here are some requirements: (actually real, I'm working on a IoT'ish product) * webapp must be served via HTTPS, either from the IoT device or vendor site * it just works! if webapp served from IoT device, the user shall not be required to install certificate or set exception (because it then looks like scary as hell malware) * the webapp must work offline (service worker or appcache) without internet connection * webapp must be able to talk directly to the device, no cloud or vendor server inbetween * the IoT device which provides a secured REST API might be in in a LAN which is NOT connected to the internet -- so the '<random-stuff-id>.vendor.com DNS resolves to device IP with an Lets Encrypt CA' approach won't work here (otherwise nice hack) To my knowledge it's technically not possible to build such a HTTPS secured webapp in a local network today without breaking the mentioned requirements.

bjpbakker 9y ago
> The problem is technical and won't be fixed by just opening the software. I strongly disagree. Main reason is that if Philips opened their firmware to the public, it would have had different protocols by now than just HTTP with a poor mans JSON API. > Homekit is nice but not available to webapps, apps of course can take advantage of several security mechanisms. That's why basically my point is to /not/ use a web app to control local insecure IOT devices. > Please name just one which works for webapps, beside HTTPS. Use locally resolvable DNS names and wildcard certificates signed by commonly trusted (public) CAs. It's been done before (Plex does something like this IIRC). * update: I just noticed another comment [1] that mentions Plex with a link to some technical details [2]. [1] https://news.ycombinator.com/item?id=14751768 https://news.ycombinator.com/item?id=14751768 [2] https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/ https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...
- qb45 9y ago
  > it would have had different protocols by now than just HTTP with a poor mans JSON API. Sure, but now you can't control the gadget from the browser and the vendor needs to write an application or something for whatever shitty OS you want to use. > Use locally resolvable DNS names and wildcard certificates signed by commonly trusted (public) CAs. It's been done before (Plex does something like this IIRC). Not that simple. Public CAs will likely only give you certs for domains you own (like plex.direct) and your users generally don't have nameservers authoritative for such domains on their LANs (maybe you could pull it off if you are a router vendor, but not with IoT light bulbs) so they have to query your public nameserver and the system fails without Internet connection. And there is no easy solution: if your light bulb could register an xxx.philips.com domain via UPnP on your router or via SMB on your Windows box, it would be very much unclear what exactly should prevent it from registering philips.com as well.
xg15 9y ago
I think this is part of the larger problem of the relentless "cloud first" movement that the whole industry seems to have adopted. I feel like there isn't any new software, device or standard in development by now that doesn't demand constant internet access and a dedicated background service. Even basic things that should have no business relying on internet access get swalloed by that. (Browsers, operating systems, cars...) The economic incentives that push everyone in that direction are obvious but I think in the end that will lead to more harm than good. That being said, I can understand that making IoT devices directly accessible from web page JS fü could cause some security headaches: As an example, apparently a lot of recent exploits were caused by programs opening a loopback-only REST service for IPC. Those services weren't secured because, hey, if someone can talk to loopback, the system is compromised anyway. The developers didn't realize that any webpage open in a browser can do that via script (respecting CORS) and so even loopback services should be considered exposed to the internet. I can imagine that an IoT device offering a browser-accessible REST interface might cause similar non-obvious attack vectors. So at the least, it would have to implement some kind of user management and authentication - which might be challenging for small devices. I think what we really need is some kind of dedicated standard for browsers talking to things on the LAN. Such a standard could then handle discovery, certificate management and authentication/permissions in one go - and would enable browsers to present a good UI for those steps. However, right now everyone seems to busy developing intricate rube-goldberg machines[1] to care and the agenda of the browser vendors seems to go in the opposite direction - so I don't have high hopes. I think practically, the most feasible step right now is to forego browsers and build an app instead. Then you have to deal with the headaches of app development but at least you get a nice user experience without any backend services... [1] https://twitter.com/isotopp/status/877444175708475393 https://twitter.com/isotopp/status/877444175708475393

by cryo 9y ago

bjpbakker 9y ago

> The problem is technical and won't be fixed by just opening the software. I strongly disagree. Main reason is that if Philips opened their firmware to the public, it would have had different protocols by now than just HTTP with a poor mans JSON API. > Homekit is nice but not available to webapps, apps of course can take advantage of several security mechanisms. That's why basically my point is to /not/ use a web app to control local insecure IOT devices. > Please name just one which works for webapps, beside HTTPS. Use locally resolvable DNS names and wildcard certificates signed by commonly trusted (public) CAs. It's been done before (Plex does something like this IIRC). * update: I just noticed another comment [1] that mentions Plex with a link to some technical details [2]. [1] https://news.ycombinator.com/item?id=14751768 https://news.ycombinator.com/item?id=14751768 [2] https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/ https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...

qb45 9y ago
> it would have had different protocols by now than just HTTP with a poor mans JSON API. Sure, but now you can't control the gadget from the browser and the vendor needs to write an application or something for whatever shitty OS you want to use. > Use locally resolvable DNS names and wildcard certificates signed by commonly trusted (public) CAs. It's been done before (Plex does something like this IIRC). Not that simple. Public CAs will likely only give you certs for domains you own (like plex.direct) and your users generally don't have nameservers authoritative for such domains on their LANs (maybe you could pull it off if you are a router vendor, but not with IoT light bulbs) so they have to query your public nameserver and the system fails without Internet connection. And there is no easy solution: if your light bulb could register an xxx.philips.com domain via UPnP on your router or via SMB on your Windows box, it would be very much unclear what exactly should prevent it from registering philips.com as well.

xg15 9y ago

I think this is part of the larger problem of the relentless "cloud first" movement that the whole industry seems to have adopted. I feel like there isn't any new software, device or standard in development by now that doesn't demand constant internet access and a dedicated background service. Even basic things that should have no business relying on internet access get swalloed by that. (Browsers, operating systems, cars...) The economic incentives that push everyone in that direction are obvious but I think in the end that will lead to more harm than good. That being said, I can understand that making IoT devices directly accessible from web page JS fü could cause some security headaches: As an example, apparently a lot of recent exploits were caused by programs opening a loopback-only REST service for IPC. Those services weren't secured because, hey, if someone can talk to loopback, the system is compromised anyway. The developers didn't realize that any webpage open in a browser can do that via script (respecting CORS) and so even loopback services should be considered exposed to the internet. I can imagine that an IoT device offering a browser-accessible REST interface might cause similar non-obvious attack vectors. So at the least, it would have to implement some kind of user management and authentication - which might be challenging for small devices. I think what we really need is some kind of dedicated standard for browsers talking to things on the LAN. Such a standard could then handle discovery, certificate management and authentication/permissions in one go - and would enable browsers to present a good UI for those steps. However, right now everyone seems to busy developing intricate rube-goldberg machines[1] to care and the agenda of the browser vendors seems to go in the opposite direction - so I don't have high hopes. I think practically, the most feasible step right now is to forego browsers and build an app instead. Then you have to deal with the headaches of app development but at least you get a nice user experience without any backend services... [1] https://twitter.com/isotopp/status/877444175708475393 https://twitter.com/isotopp/status/877444175708475393