1572187 - Extend match patterns to handle custom protocol schemes

Status: NEW

(WebExtensions :: General, enhancement, P3)

Description

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

With an ability to register programmable protocol handler list of protocol schemes will grow and current implementation of match patterns need to change to be able to handle that.

For more details see
https://github.com/mozilla/libdweb/issues/26
https://github.com/mozilla/libdweb/issues/103

Comment 1

[Shane Caraveo (:mixedpuppy)]

Issue 103 has a reasonable way to make it work. I wonder if activeTab permission handles the problem for 26.

We'd probably want our pattern matching to have an api that allows adding schemes that are registered via any protocol handling, or at least allow those defined in the hard coded list plus ext+* and web+*. Rob has done some work on exanding matching for privileged extensions, so maybe he has a thought or two on this.

Comment 2

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

We'd probably want our pattern matching to have an api that allows adding schemes that are registered via any protocol handling, or at least allow those defined in the hard coded list plus ext+* and web+*. Rob has done some work on exanding matching for privileged extensions, so maybe he has a thought or two on this.

It seems like it might make sense to consult dynamic list we're gonna add for registering schemes
https://bugzilla.mozilla.org/show_bug.cgi?id=1569733

Comment 3

[Rob Wu [:robwu]]

(In reply to Shane Caraveo (:mixedpuppy) from comment #1)

Issue 103 has a reasonable way to make it work.

Another alternative is the declarativeContent.ShowPageAction API that I'm working on in bug 1465995, because the underlying URLFilter is significantly more expressive than a match pattern.

I wonder if activeTab permission handles the problem for 26.

We'd probably want our pattern matching to have an api that allows adding schemes that are registered via any protocol handling, or at least allow those defined in the hard coded list plus ext+* and web+*.

If we want to treat these ext+/web+/dweb schemes as a first-class match pattern, then we need to know the format of the schemes upfront, in order to validate match patterns (and refuse to load an extension if its manifest contains an incorrect match pattern).

While it is technically possible to support new schemes in match patterns, I'd like to only go in that direction if we have no fitting alternatives.

Rob has done some work on exanding matching for privileged extensions, so maybe he has a thought or two on this.

For extension consumers, the format of match patterns is quite strict. It has to match the format as defined here. Privileged extensions may also access resource: and about:-URLs. APIs whose interface are defined in terms of MatchPatterns are subjected to these restrictions (e.g. content_scripts, page_action.show_matches).

There are other APIs that also use MatchPatterns, but whose validity is not restricted to the above schemes. For example:

• urls in webRequest's request filter. Any URL that is considered to be a valid match pattern (one of the requirements is having a permitted scheme), can be used. So although "data:" is not part of the MatchPattern definition, extensions can still try to match these requests if they have the permission to access all hosts (e.g. <all_urls>).
• targetUrlPatterns of the menus API have no restrictions on the schemes. Unrecognized schemes are treated as if they have no host (unless they are listed in HOST_LOCATOR_SCHEMES; a scheme should be in this list iff nsIURI thinks that it has a host).

From looking at libdweb's Readme.md, it seems that the scheme has a "host", but it has no connection with "host" from http(s)/ftp schemes. This means that we cannot easily treat new schemes as a first-class match pattern without also seriously refactoring our permission message generation code.

What are other use cases for the perceived need to support more arbitrary schemes in match patterns?
Is there a need to run content scripts in pages from third parties, or only in pages from your own protocol handler? (this is not clear from 26). If it's just your own extension, we can implicitly grant access to the custom protocol when the protocol is registered by its own extension, like we do for moz-extension: scheme.

Comment 4

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

 If we want to treat these ext+/web+/dweb schemes as a first-class match pattern, then we need to know the format of the schemes upfront, in order to validate match patterns (and refuse to load an extension if its manifest contains an incorrect match pattern).

While it is technically possible to support new schemes in match patterns, I'd like to only go in that direction if we have no fitting alternatives.

I think fundamental problem is extension IPFS might be providing implementation for protocol ipfs:// while extension annotator might wish to add content scripts for all pages coming from ipfs://*, dat://*, etc... So depending on order second extension may or may not refuse to load.

From looking at libdweb's Readme.md, it seems that the scheme has a "host", but it has no connection with "host" from http(s)/ftp schemes. This means that we cannot easily treat new schemes as a first-class match pattern without also seriously refactoring our permission message generation code.

I'm not sure what you mean by connection to with "host" from http(s)/ftp but generally libdweb URLs have host component used for origin separation and usually it corresponds to an authority represented via cryptographic hash. In that regard it is same as in http(s) / ftp except it's not about where but more about who.

What are other use cases for the perceived need to support more arbitrary schemes in match patterns?
Is there a need to run content scripts in pages from third parties, or only in pages from your own protocol handler? (this is not clear from 26). If it's just your own extension, we can implicitly grant access to the custom protocol when the protocol is registered by its own extension, like we do for moz-extension: scheme.

I think generally starting with allowing an add-on to use all the web extension APIs with protocol it provides is a good start, which I think what you suggest here. I suspect if this experiment turns out to be success third party add-ons will end up wishing to use range of web extension APIs on pages coming from these protocols, but it seems to me that allowing extension to use APIs on own protocol is probably a good enough solution until it proves to be successful & even then more likely it would be a handful of protocols so maybe mentioned lists would be all that it takes.