Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Custom Protocols in WebExtension #164

Open
5 of 7 tasks
lidel opened this issue Nov 3, 2016 · 17 comments
Open
5 of 7 tasks

Support Custom Protocols in WebExtension #164

lidel opened this issue Nov 3, 2016 · 17 comments
Labels
kind/discussion Topical discussion; usually not changes to codebase kind/maintenance Work required to avoid breaking changes or harm to project's status quo status/blocked/missing-api Blocked by missing API status/blocked/upstream-bug Blocked by upstream bugs status/deferred Conscious decision to pause or backlog
Milestone

Comments

@lidel
Copy link
Member

lidel commented Nov 3, 2016

(living summary: updated @ 2018-09)

This issue tracks browser extension support for various protocol schemes and URIs according to four stages of the upgrade path for path addressing and IPFS Addressing in Web Browsers memo, namely:

URLs:

ipfs://{cidv1b32}http://127.0.0.1:8080/ipfs/{cidv1b32}
ipns://{hash}http://127.0.0.1:8080/ipns/{hash}

URI:

dweb:/ip[f|n]s/{hash}http://127.0.0.1:8080/ip[f|n]s/{hash}

This issue also tracks (currently nonexistent) ways to address/workaround how Origin is calculated (Problem #2)

WebExtension APIs

Universal API

No such thing yet (but see WIP work in comments)

Firefox

Chrome / Chromium

Brave

Muon-based (deprecated in 2018)

Chromium-based

  • Basically same challenges as Chromium right now

Related discussions

@lidel lidel added this to the v2.0.0 milestone Nov 3, 2016
@lidel lidel changed the title Support Custom Protocols Support Custom Protocols in WebExtension Feb 6, 2017
@lidel
Copy link
Member Author

lidel commented Feb 25, 2017

Support for simplified redirect-based protocol handler (simple redirect, no origin support) landed in Firefox 54:

This a a thin UX on top of Navigator.registerProtocolHandler():

Note that this is just a redirect:

This means the address in location bar changes (Origin barrier is broken) and there are different security context for public and local gateways (different cookies, etc).

And yes, this is Firefox-only.

@lidel
Copy link
Member Author

lidel commented Mar 17, 2017

It seems that this new API has the same naming limitation as Chrome, firefox-54.0a2 says:

Reading manifest: Error processing protocol_handlers.0.protocol: Value must either: be one of ["bitcoin", "geo", "im", "irc", "ircs", "magnet", "mailto", "mms", "news", "nntp", "sip", "sms", "smsto", "ssh", "tel", "urn", "webcal", "wtai", "xmpp"], or match the pattern /^(ext|web)+[a-z0-9.+-]+$/

This means we can't support ipfs://hash anymore and are forced to use web+ipfs://hash 👎

@Kubuxu
Copy link
Member

Kubuxu commented Mar 18, 2017

When we get official registration of the schema we should be able to request the exemption to be added.

@lidel
Copy link
Member Author

lidel commented Sep 10, 2017

I've just tested a ridiculous PoC that restores support for ipfs:// dweb: etc in WebExtension:

  • We know that:
    • permission <all_urls> fires onBeforeRequest for every URL
    • when URL starting with an unknown protocol is entered in location bar, a browser url-escapes entire address and converts it to a search query, e.g:
      ipfs://QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnRhttps://www.google.com/search?q=ipfs%3A%2F%2FQmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR&ie=utf-8&oe=utf-8&client=firefox-b-ab
  • So what happens if you:
    • detect requests with URL containing url-encoded :/ ( %3A%2F)
    • find ones that match a query starting with one of custom protocols: /=(ipfs|ipns|dweb)%3A%2F(%2F[^&]+)/
    • extract IPFS path and check if passes IsIpfs.path test
      • if so, replace request to search engine with request to resource at public gateway 'https://ipfs.io/' + extractedIpfsPath
      • if not, return original request

Well.. it just works 🚀 🙃 (not sure if I am proud or ashamed, probably both)

Expect PR in near future. My plan is to polish and ship this workaround as the default behavior, so that there is no functional regression when users update from v1.6.0 to v2.x.x.

Of course there will be a preference that disables this: to pass review at Mozilla and in case someone really wants to search for ipfs://QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR

Update 2017-12-27: this hack does not work on Android – see #348

lidel added a commit that referenced this issue Sep 17, 2017
This is an implementation of ridiculous idea from:
#164 (comment)

I am really sorry.
lidel added a commit that referenced this issue Sep 27, 2017
This is an implementation of ridiculous idea from:
#164 (comment)

I am really sorry.
@lidel lidel added the kind/discussion Topical discussion; usually not changes to codebase label Sep 27, 2017
@lidel lidel added the area/libdweb Work related to new APIs from Mozilla/libdweb label Aug 15, 2018
@lidel lidel added this to the libdweb demos milestone Aug 17, 2018
@lidel lidel removed the area/libdweb Work related to new APIs from Mozilla/libdweb label Aug 17, 2018
@lidel
Copy link
Member Author

lidel commented Sep 9, 2018

FYSA some recent developments (Q3 2018):

@lidel
Copy link
Member Author

lidel commented Sep 12, 2018

If DWeb protocols get safelisted, we need manifest.json/protocol_handlers feature parity to solve UX issues mentioned in arewedistributedyet/arewedistributedyet#23 (comment)

Filled a Chrome bug: Extensions API should implement manifest.json/protocol_handlers.

@lidel lidel added the status/deferred Conscious decision to pause or backlog label Sep 22, 2018
@ingokeck
Copy link

According to the URI syntax in RFC3986, it should not be "ipfs://{cidv1b32}", instead it should be "ipfs:{cidv1b32}". Same for {hash}. The extention should then use its default IPFS instance to retrieve the object {cidv1b32}. See https://tools.ietf.org/html/rfc3986#section-3

'//' denotes a specific instance. So an IPFS service on localhost could be addressed with "ipfs://localhost/{cidv1b32}", while IPFS running on ipfs.io would be "ipfs://ipfs.io/{cidv1b32}"

@lidel
Copy link
Member Author

lidel commented Jan 21, 2021

Those are good points, thanks for raising them @ingokeck
We would love to be as compliant with RFCs as possible, as long we don't compromise Origin isolation (details below), so this needs deeper analysis.

  • 💚 For the sake of UX, I believe both should work. For example, you can use ipfs:bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi in Firefox today and if you have IPFS Companion installed, it will resolve just fine. If we flip the default, the reverse should be true as well.

  • 💛 Removal of // needs discussion with Brave, Opera, and other community members, but I suspect the only reason for // is technical debt in web browsers and being pragmatic. Browsers are HTTP-centric and existing implementation leverage this property of RFC3986:

    Non-validating parsers (those that merely separate a URI reference into
    its major components) will often ignore the subcomponent structure of
    authority, treating it as an opaque string from the double-slash to
    the first terminating delimiter, until such time as the URI is dereferenced.

    For example Brave v1.19 uses CID as "authority" component and build Origin based on it. This provides us with security sandbox per content root (CID), but has a side-effect of // in the address bar.

    TLDR Origin isolation is way more important than being visually compliant with RFC// can be removed only if Origin isolation per CID is maintained, which I don't believe is possible atm.

  • 💔 ipfs://localhost/{cidv1b32} is incompatible with our security model given how addressing is implemented in browsers

    • Each CID needs to create own Origin, and this will put all CIDs under single Origin, so a big NO.
    • Yes, this could be special-cased, but is very unlikely any vendor will want to touch critical code paths for the sake of cosmetics. In the past we looked into something simpler with Suborigins and even that did not go anywhere: Suborigins  in-web-browsers#66

@lidel
Copy link
Member Author

lidel commented Mar 17, 2023

5 years after Firefox, Google Chrome is now willing to implement the protocol_handler for registering custom handlers via web extensions: w3c/webextensions#317 (comment)

@lidel
Copy link
Member Author

lidel commented Sep 3, 2024

Igalia is working on Chromium improvement to allow redirect-based handler registration with protocol_handlers in browser extension manifest. Completed the design document (The protocol_handlers Web Extension's Manifest key) with the permissions management and conflict resolutions, and shared the design document with Google for feedback.

Assuming that eventually lands in Chromium-based browsers, the next step will be to allow using the API for pointing protocol scheme at Service Worker, instead of URL. This will allows for keeping ipfs://cid in the address bar, and use it for Origin-based logic natively.

This will take even more time, for now the idea is tracked in:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/discussion Topical discussion; usually not changes to codebase kind/maintenance Work required to avoid breaking changes or harm to project's status quo status/blocked/missing-api Blocked by missing API status/blocked/upstream-bug Blocked by upstream bugs status/deferred Conscious decision to pause or backlog
Projects
No open projects
Status: Needs Grooming
Development

No branches or pull requests

6 participants