Update safelisted decentralized schemes for registerProtocolHandler()

[fred-wang]

This commit updates the list of safelisted schemes [safelisted] related
to decentralization. Several requests for new schemes have been blocked
on [blocklist] but this latter approach is not pursued in the short term.
All schemes are documented at [iana].

1. Cryptocurrencies
   - Remove bitcoin documentation link as a source code comment since it's
     already referenced on IANA's page for URI schemes.
   - Add "ethereum".

2. dweb community [dweb]
   - Add "dat", "dweb", "ipfs", "ipns", "ssb", "cabal" and "hyper".

• At least two implementers are interested (and none opposed):
  • Firefox
  • Chromium
• Tests are written and can be reviewed and commented upon at:
  • https://github.com/web-platform-tests/wpt/blob/master/html/webappapis/system-state-and-capabilities/the-navigator-object/protocol.https.html (new protocols must be added)
• Implementation bugs are filed:
  • Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=651311
  • Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1631446
  • Safari: https://bugs.webkit.org/show_bug.cgi?id=73177 (registerProtocolHandler() not implemented)

(See WHATWG Working Mode: Changes for more details.)

---

💥 Error: Wattsi server error 💥

PR Preview failed to build. (Last tried on Jan 15, 2021, 8:01 AM UTC).

More

PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

🚨 Wattsi Server - Wattsi Server is the web service used to build the WHATWG HTML spec.

🔗 Related URL

Parsing MDN data...
Parsing...

If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.

[annevk]

I wonder if we need a bit more for the schemes not listed in https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml. To create better UI than listing the scheme, implementations would need to know their purpose. I suppose ideally we at least provisionally register them similar to all the [Dave_Thaler] entries there.

[fred-wang]

Thanks @annevk I guess that makes sense.

"Guidelines and Registration Procedures for URI Schemes" are here:

https://tools.ietf.org/html/rfc7595

The part about "Provisional URI Scheme Registration" is:

https://tools.ietf.org/html/rfc7595#section-4

The syntactic and not-already-used requirements are met for dweb, dat, ipfs, ipns and ssb ; it should be possible to find a spec for all of them. Regarding security considerations and other general guidelines, I guess the authors are probably in better position to address these.

I'll see what I can do here.

cc'ing @lidel who initially opened #3935

[domenic]

This seems good to me as-is, and thank you to @fred-wang for pushing forward and getting implementer interest where several others have failed. This will make web developers happy.

I personally don't think we need to block the spec/tests PRs on IANA formalities. We could have a separate bug about, e.g., linking all the <code data-x="">s to IANA registrations or specs or whatever, but I don't think it needs to be solved here. I'll let @annevk make the call.

[annevk]

Well the existing ones are registered I believe so there is some place to find more information about them. If we kept our own registry that would be okay as well, but having strings without any additional information seems bad as only git blame would give you something.

It's not so much about the formalities to me as it is about where to find more information.

[domenic]

My point is that currently there's no way to find more information from the spec; the spec doesn't link to any registrations or other specifications or anything. It's just a list of strings, and there's no requirement that the list be full of only-registered schemes. Indeed, it seems valid to add something like "asdf1234" to the allowlist if someone wants that; it doesn't hurt anything.

But, I don't care much.

[fred-wang]

Thanks @domenic and @annevk ; I think we can add reference to all of them, the minimum would probably be to have a technical spec for the protocol with a link describing the URI scheme? I tried to report the IANA thing to the protocol authors mentioning this, let's see how they react, I guess that would give us an indication of which schemes is important enough...

[annevk]

It should be fairly straightforward to get a provisional registration by emailing. If that doesn't work out, let's collect those emails here and I'll file a follow-up somewhere on what to do about the registry.

Apart from helping implementers having a place to find suitable information on URL schemes we're also implicitly requiring this from web developers through https://url.spec.whatwg.org/#url-writing:

Schemes should be registered in the IANA URI [sic] Schemes registry. [IANA-URI-SCHEMES]

And yeah, a further alternative could be to maintain a second registry of sorts in the HTML Standard, but that might get messy long term.

[fred-wang]

Just a quick update on this, I've tried to coordinate with the dweb communities on this. It seems they want more two more protocol schemes (cabal and hyper). I drafter some requests for IANA and hope to send them soon:

https://github.com/fred-wang/iana-uri-schemes-provisional-registration-requests

[annevk]

One other concern here is the "Hijacking all Web usage" security issue though I guess in a way that would be considered a success for these schemes and result in their removal as user agents add native support.

[fred-wang]

@annevk Right, this is mentioned in the blink-dev intent to implement thread: https://groups.google.com/a/chromium.org/d/msg/blink-dev/7nHTRUP1EGY/LYCOtg3IAwAJ (and copied from the original request by @asankah

"Conflicts with native support. Popular browsers in the future may, and specialized browsers currently do, implement native support for some of the distributed web protocols. Where native support for a protocol exists, the corresponding scheme will need to be removed from the safelist for each respective browser, and eventually from the spec. We believe that native support for a protocol would not reduce functionality for users and hence such a change would not be disruptive."

I think the dweb community considers improving non-native solutions (e.g. via web extension or http gateways) as an intermediate step to experiment & demonstrate their protocols as well as increase their user community, before a long term goal of native support.

[fred-wang]

I updated this PR to include new schemes proposed by the dweb community and do related decentralized scheme updates: add ethereum and remove documentation comment for bitcoin.

[domenic]

Just checking in; what's the latest status on this PR, and is the OP up to date in that regard? In particular:

• The OP says that both Mozilla and Chromium support this change, but Add new safelisted schemes for registerProtocolHandler() mozilla/standards-positions#339 contains some debate, and the blink-dev thread does not have any positive responses at the moment.

• The OP links to https://github.com/web-platform-tests/wpt/blob/master/html/webappapis/system-state-and-capabilities/the-navigator-object/protocol.https.html and has the "tests are written" box checked, but none of the protocols added in this PR are tested in that file.

• @annevk desires that everything we add be IANA registered. I know you've been doing a lot of this work, but also the list keeps expanding, so I'm not 100% sure if everything in the PR is registered. Could you confirm?

Again, thanks for driving this forward; I'm really hopeful you'll succeed where others have failed. I'm excited to merge this as soon as possible, but the information in the OP is a bit confusing for me right now.

[fred-wang]

@domenic yes sorry for the confusion. I updated the checkboxes

• There was no complaints in past blink-dev and WHATWG discussions on these schemes that's why I initially thought they could be extracted safely. But right now I still need to check with Mozilla and Chromium communities.

• The WPT tests on blocked on this change too. Adding tests will be straightforward, it's done here: Update test for registerProtocolHandler() to include decentralized sc… web-platform-tests/wpt#23652

• The list should be up-to-date. However, there are more requests at Add did: to registerProtocolHandler safelisted schemes #5561 (which can probably handled in the decentralized schemes), Add doi as safelisted scheme for the registerProtocolHandler() method #3080 and Add otpauth as a safelisted scheme for registerProtocolHandler() #5551 ; they also need WPT tests.

[fred-wang]

Just an update on this, the current list is

cabal
dat
did
dweb
ethereum
hyper
ipfs
ipns
ssb

• spec, WPT, mozilla and chromium patches have been updated accordingly.
• Chromium API owners approved this change
• still waiting feedback from Mozilla on Add new safelisted schemes for registerProtocolHandler() mozilla/standards-positions#339

[lidel]

FYSA Chromium implementation landed and Google shipped it with Chrome 86: https://www.chromestatus.com/feature/4776602869170176

[javifernandez]

Hi,

I'm trying to retake @fred-wang efforts to move this issue forward. I'm still trying to digest all the information from the discussions; If I've understood it correctly, the main blocker for this PR is the doubts expressed by Mozilla folks in the standard-position thread about this. I'll try to focus on this while I'm landing to this issue.

Just checking in; what's the latest status on this PR, and is the OP up to date in that regard? In particular:

The OP says that both Mozilla and Chromium support this change, but Add new safelisted schemes for registerProtocolHandler() mozilla/standards-positions#339 contains some debate, and the blink-dev thread does not have any positive responses at the moment.

In the Mozila's standard-positions discussion I see 2 concerns mainly; one about origins and another one, more general, regarding the PR targeting many different schemes which would imply an endorsement to their respective technologies.

I agree that reviewing each scheme separately would help to unblock the situation. I''ll be happy to start by creating a new PR for IPFS and IPNS, and then discuss there the other concern related to origins. Opinions ?