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.
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
[2] https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...