Safelist 'ipfs' and 'ipns' schemes

[javifernandez]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: HTML
• Specification or proposal URL:
  • https://html.spec.whatwg.org/multipage/system-state.html#safelisted-scheme (current text)
  • https://github.com/whatwg/html/pull/7911 (proposal)
• Caniuse.com URL (optional):
  • https://caniuse.com/#feat=mdn-api_navigator_registerprotocolhandler
• Bugzilla URL (optional):
  • https://bugzilla.mozilla.org/show_bug.cgi?id=1631446
• Mozillians who can provide input (optional): @annevk, @asutherland, @martinthomson

Other information

This issue is an excerpt of #/339, which was stalled for a long time partially due to the confusion added by the inclusion of several and quite different dweb schemes in the same proposal. Instead, I'd like to focus on 'ipfs' specifically.

In the mentioned previous issue there was some concerns that are worth bring here now:

• how would these single-origin-HTTPS-based gateways for distributed technology ensure content is suitably isolated (security-wise)?
• So this relies on the provider of the handler following good hygiene. In the example given, this is achieved by using unique per-IPFS-origin origins (it probably also requires that dweb.link is on the PSL and some other stuff).

These concerns have been discussed in the issue, so I'll provide a quick summary here:

• *.dweb.link is on the Public Suffix List https://github.com/publicsuffix/list/blob/cde0cd4275cfd5c50f45e4e0146c70be3036c935/public_suffix_list.dat#L13022-L13024
• ipfs and ipns are registered at IANA https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
• ipfs / ipns protocols are already whitelisted for extensions: https://searchfox.org/mozilla-central/source/toolkit/components/extensions/schemas/extension_protocol_handlers.json#19
• The gateway approach provides unique Origin per IPFS content identifier (CID) for regular users, and lets us do opportunistic protocol upgrade for power users: request will be redirected to local IPFS node if user installed our browser extension, or handled natively if a browser vendor decides to ship with a built-in node in the future.

[javifernandez]

I consider interesting to bring here a definition of the 'safelist' concept mentioned in the HTML Spec issue #339; I believe it could help us to determine whether the IPFS scheme should be added to the list or not.

A scheme would be candidate to be included in the 'safelist' when it meets the following criteria:

• An RFC (or equivalent) describing the scheme.
• Evidence that the scheme is likely to be used with registerProtocolHandler on the web. This might include an existing ecosystem of non-web applications using the scheme in a way that would make sense as a webapp, or widespread use of an equivalent web+ scheme.
• The scheme doesn't correspond to a technology we would otherwise consider harmful.
• Multiple browser implementors interested in adding the scheme (this is a pre-existing requirement for any changes to HTML).

[javifernandez]

Although it's still debatable if the criteria described above is widely agreed, I'll use it at least to described the current status of the IPFS scheme:

• [ ] An RFC (or equivalent) describing the scheme.
  • https://www.iana.org/assignments/uri-schemes/prov/ipfs
  • https://github.com/ipfs/specs
• [ ] Evidence that the scheme is likely to be used with registerProtocolHandler on the web.
  • Mozilla whitelisted (patch) DWeb protocols for use in WebExtension context (Firefox 59).
  • Firefox AddOn IPFS-Companion uses the registerProtocolHandler API
  • It's supported in Chrome, Brave, Opera and Edge
• [ ] The scheme doesn't correspond to a technology we would otherwise consider harmful.
• [ ] Multiple browser implementors interested in adding the scheme (this is a pre-existing requirement for any changes to HTML).
  • Chrome shipped a change to add ipfs to the safelist since 86 (this implies any Chrome based browwser, Brave, Opera, Edge)
  • Since Safari doesn't implement the registerProtocolHandler API, this means that only Firefox support is relevant now

[annevk]

Note that a provisional scheme registration isn't really equivalent to an RFC. An RFC or equivalent would be a specification published by a standards body, with multiple independent implementations.

[javifernandez]

Note that a provisional scheme registration isn't really equivalent to an RFC. An RFC or equivalent would be a specification published by a standards body, with multiple independent implementations.

Sure, I guess I'll try to provide the info and let others determine if it'd be enough to fulfill the requirements.

[autonome]

hey @annevk!

An RFC or equivalent would be a specification published by a standards body

Which standards bodies which qualify?

with multiple independent implementations.

Can you share more about how you evaluate this? There are various implementations of IPFS in different languages, with different capability levels (similar to HTTP), developed by different people.

[annevk]

https://wiki.mozilla.org/ExposureGuidelines#Ensure_that_the_feature_is_standardized has some guidelines around this. Multiple independent implementations is something that is typically assessed by standards bodies, though the quality of that assessment varies.