Re: [w3c/ServiceWorker] Self hosted applications (Issue #1668)

I would like to weigh in on this, since I have been running up against a very similar issue and use-case and I think there is an argument to be made that the web as a platform should care about this use-case.

## What's the issue?
I have been prototyping a PWA meant to configure and control IOT devices on your local network. The specific devices are ESP32 MCUs that get provisioned through [Improv](https://www.improv-wifi.com/) and are running [ESPHome](https://esphome.io/index.html). My intention is to provide a light-weight, low friction flow to provision, configure and control these devices that is independent from any additional infrastructure. In theory, the web seems like a great platform for this. 

Each of these IOT devices exposes a simple REST-full web API as well as an EventSource/SSE to push updates and events to the controlling client application.
Being low powered IOT devices their web server implementation does not come with SSL/HTTPS support out of the box. That said, it's technically not impossible to deploy SSL/HTTPS to these devices and maybe [this is exactly what should happen](https://github.com/esphome/feature-requests/issues/2432).

However even with SSL/TLS support on these devices a major issue remains, which is that the SSL/TLS certificate system heavily relies on the public DNS system for identity verification and generally it's not possible/convenient to acquire a commonly accepted certificate for the private address space IP addresses/domains. While it is technically *possible* using custom root CAs and self-signed certificates, this approach is neither convenient nor particularly user-friendly.

In theory it is possible to workaround these limitations by deploying a PWA on a SSL/TLS public web server and ask your users to change their UA settings to allow insecure content for that website. This will allow the PWA/website to establish mixed content connections to local IP addresses / hostnames. The steps involved are neither simple, easy to communicate and at with that amount of friction involved one would probably rather prompt their users to install a native app out of their respective app store.

## Why should the web as a platform care?
The IOT space in general is a growing market and for various reasons (performance, reliability, privacy as well as simple economics) there is a [major push by almost all relevant players in this space](https://csa-iot.org/all-solutions/matter/) to move to more local control and fulfillment. The web platform could be a strong contender to provide a transparent, low friction and open frontend for these systems. However to fill this role the web needs to somehow adapt to this new local world in which trust isn't provided through certificates and public DNS, but, I guess, by the fact that something lives in your own local, (virtual) space.

## What needs to be done?
I don't really have specific proposals. I frankly don' think I have sufficient knowledge in the web security space to make concrete suggestions. But ultimately I think some form of relaxing of secure origin / mixed content policies might be required. Obviously in a way that doesn't negatively affect the public web and that may opt-in/limited to local networks and/or whitelisting. For example, maybe a Service Worker or PWA can ask for the permission to access the local network (similar to how native mobile platforms do this for native apps) and once granted can treat hosts in the private ip address and host name space as secure origins, like it already does out of the box for some [very specific and limited number of hosts and protocols](https://stackoverflow.com/questions/51958643/secure-origin-other-than-https).

Overall I am not trying to suggest any specific action or change, but would like to facilitate a discussion around if this is a use-case that the web platform should care about and try to support. While I'm more than happy to help explore options I think ultimately other people probably have a better understanding of what is possible and most suited to be done. 

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1668#issuecomment-1763665536
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1668/1763665536@github.com>

Received on Monday, 16 October 2023 03:23:08 UTC