macOS Sonoma leaves `*.localhost` handling at the mercy of ISPs

[michaelfig]

Describe the bug

refs #1006

Reported by @SMotaal, and we investigated it together.

Using *.endo.localhost is not adequately supported under Safari for macOS 16.2.

Unlike Firefox and Chrome, which always use their own HTTPS DNS servers that support *.localhost in an RFC-compliant way, Safari uses the system default DNS resolver, which is probably backed by whichever Internet Service Provider is in use.

Not all such providers support *.localhost, which makes Safari unusable for the current Endo Daemon.

Steps to reproduce

1. on macOS 16.2, ping example.endo.localhost
2. it may work, depending on your ISP, or it may give ping: cannot resolve example.endo.localhost
3. If the ping failed, try the 1kce demo, and attempt to open it in Safari.
4. Safari will display a failure as well.

Expected behavior

There are workaround public wildcard localhost DNS providers. It would be useful to be able to specify a command line argument or environment variable to generate *.endo${localhostSuffix} URLs, where the default localhostSuffix = '.localhost'.

With that being supported, the Endo daemon host match regexp should be more tolerant of the specified URL suffices, something like:

    const match =
          /^([0-9a-f]{32})\.endo(\.[^:/#?]+):([1-9][0-9]{0,4})$/.exec(host);

Platform environment

• What OS are you using? macOS 16.2
• What version of Node.js? Node v20.6.1
• Is there anything special/unusual about your platform? no
• What version of Endo are you using? kumavis-1kce-demo

Additional context

This works under Safari on macOS 15.

Screenshots

[michaelfig]

I added more details to an inconclusive WebKit bug that's been open since 2016

[kriskowal]

What we know so far is that this *.endo.localhost strategy is unsuitable for confinement for a number of reasons including this issue, the other being that browsers are uneven about treating localhost subdomains as isolated origins. There are a number of alternatives, and we might employ some or all of them as they have varying pros and cons.

1. The pet daemon can be configured to use an alternate wildcard subdomain. I set up *.parezenonopa.com to this end and verified that it works. I believe there are some limitations to its ability to confine cookies. The strategy relies on the registrant to maintain the domain and not swap the wildcard DNS with a site that scoops your local storage etc.
2. A native application can embed a web view with a custom protocol that simply proxies e.g., endo://*/ to the local HTTP server. SocketSupplyCo does not support this mode, not yet anyway, but a MacOS app or iOS app can embed a WKWebKitView with a custom protocol handler. I presume the same can be accomplished for Windows and Android.
3. The pet daemon could require the installer of a weblet to reserve a port number and host at 127.0.0.1:$PORT/$NONCE/. This might look like endo install weblet weblet.js --port 8181 at the CLI.

I expect the third option is the most viable in the short-term.

[michaelfig]

reserve a port number and host at 127.0.0.1:$PORT/$NONCE/

That would be acceptable.

[kriskowal]

I have added the metamask-grant-2024 label because solving this problem is necessary to prove the viability of the daemon design.