Hostnames for localhost HTTP gateway

[lidel]

Motivation

• At some point in the future we may have native protocol handler (libdweb+[PoC] libdweb experiment: protocol handler API ipfs-companion#533 or similar), but for now the URL in address bar remains fugly less than pretty
• The latest Companion extension supports DNSLink-based redirects from URLs like http://docs.ipfs.io to a local go-ipfs gateway at http://127.0.0.1:8080/ipns/docs.ipfs.io/
• Our public gateways start to support cidv1b32 in Subdomains (CID as a Subdomain #89), which restores Origin-based isolation between websites. This also means we don't want to redirect such URLs to local gateway as it would remove this isolation.

Requirements

I wonder if there is a way of generating vanity hostnames pointing at localhost that:

• does not require lookups to an external DNS server
• keeps HTML content in secure context
• works out-of-the box on windows, mac and linux
  • alternatively we can add heuristics to pick method based on user's platform
• lets us introduce subdomain-driven Origin isolation for locally running gateway
• (nice to have, but we can work around this for embedds) does not trigger mixed-content warnings when IPFS resource from localhost is embedded on HTTPS website
  • it is what happens when /ipfs/{cid} is redirected from public gateway running on https to a custom one running on http
  • this may be the blocker: AFAIK only 127.0.0.1 and ::1 are whitelisted by browser vendors (eg. firefox #903966) but localhost is not (that is why Companion uses raw IP)
  • as of 2019-10 localhost is a secure context in both Firefox and Chrome. Firefox does not support subdomains (foo.bar.localhost is not a secure context)

If anyone has unconventional ideas, feel free to comment.

Candidates

*.localhost

Current status

🔒 – window.isSecureContext === true
💢 – window.isSecureContext === false

Status	Firefox	Chrome
127.0.0.1	🔒	🔒
localhost	🔒	🔒
foo.bar.localhost	💢	🔒

References

• https://w3c.github.io/webappsec-secure-contexts/#localhost:

  Section 6.3 of [RFC6761] lays out the resolution of localhost. and names falling within .localhost. as special, and suggests that local resolvers SHOULD/MAY treat them specially. For better or worse, resolvers often ignore these suggestions, and will send localhost to the network for resolution in a number of circumstances.

• Let 'localhost' be localhost
  • [DNSOP] DNSOP Call for Adoption - draft-west-let-localhost-be-localhost
• bugzilla:
  • Stop treating 'localhost' as securely delivered for the purposes of Secure Contexts
  • Consider hardcoding localhost names to the loopback address
  • Stop treating "http://localhost/" (by name) as mixed content
• chromium
  • Intent to Implement and Ship: Treat http://localhost as a secure context
  • Issue 589141: *.localhost should be considered secure
• go-ipfs
  • localhost subdomains do not work on Firefox and Safari

[lidel]

Candidate: http://{fqdn}.ipns.localhost
Test URL: http://docs.ipfs.io.ipns.localhost:8080/ipns/docs.ipfs.io
Result:

• Linux 👎 (Works on a box with unbound, does not resolve on stock Debian)
• Windows: ?
• Mac: ?

[olizilla]

There are some occult tricks for browsers on mac and windows; you can do some automagic with this https://en.wikipedia.org/wiki/Proxy_auto-config

I found it via https://github.com/KishanBagaria/frwrd

[lidel]

[..] you can do some automagic with this https://en.wikipedia.org/wiki/Proxy_auto-config

Changing proxy setting globally is not a good idea, however Firefox provides browser.proxy API with a very interesting property:

use the proxy.onRequest event listener to intercept web requests, and return an object that describes whether and how to proxy them.

This would enable us to use PAC-like processing only for IPFS requests.
(Right now we just redirect them)

[lockedshadow]

Linux -1 (Works on a box with unbound, does not resolve on stock Debian)

Seems like that it also depends on myhostname plugin for /etc/nsswtich.conf, which is not installed by default in Debian. With this plugin installed and activated, the test URL actually redirects to http://{local_gateway}/ipns/docs.ipfs.io/ when IPFS integrations and DNSLink support is enabled in IPFS Companion, and just open as is when IPFS integrations disabled in add-on.

From man nss-myhostname:

The hostnames "localhost" and "localhost.localdomain" (as well as any hostname ending in ".localhost" or ".localhost.localdomain") are resolved to the IP addresses 127.0.0.1 and ::1.

[lidel]

I think switching from 127.0.0.1 to ::1 where possible is the best we can do right now, given cross-platform constraints.

Having local gateway at ::1 looks less intimidating:

For now, this can be enabled manually via:

$ ipfs config --json Addresses.Gateway '["/ip4/127.0.0.1/tcp/8080","/ip6/::1/tcp/8080"]'

A proposal to extend default Addresses.Gateway with /ip6/::1/tcp/8080 is at ipfs/kubo#5905

[lidel]

Update: there may be a way to support http://<cidv1b32>.ipfs.localhost on every platform supporting HTTP Proxies – see proposal in ipfs/kubo#5982