lidel
commented
5 years ago Oh wow, a lot to unpack here.
After reading the draft with proposed changes I wrote down some highlights with interesting changes and potential pain points (below).
Will follow V3 as it unfolds, but it is very likely it will bring us additional maintenance cost.
Restrict the blocking capabilities of the webRequest API
In Manifest V3, this API will be discouraged (and likely limited) in its blocking form. The non-blocking implementation of the
webRequestAPI, which allows extensions to observe network requests, but not modify, redirect, or block them (and thus doesn't prevent Chrome from continuing to process the request) will not be discouraged. As an alternative, we plan to provide adeclarativeNetRequestAPI . The details of what limitations we may put in thewebRequestAPI are to be determined. [..]
- While deciding whether a request is to be blocked or redirected, the
declarativeNetRequestAPI is given priority over thewebRequestAPI because it allows for synchronous interception.
- Evaluation of
declarativeNetRequestrulesets is performed during theonBeforeRequeststage of a network request.
We use blocking capability of webRequest API to inspect headers, detect IPFS resources, do DNSLink lookups and other things – src/lib/ipfs-companion.js#L95-L97:
browser.webRequest.onBeforeSendHeaders.addListener(onBeforeSendHeaders, { urls: ['<all_urls>'] }, ['blocking', 'requestHeaders'])
browser.webRequest.onBeforeRequest.addListener(onBeforeRequest, { urls: ['<all_urls>'] }, ['blocking'])
browser.webRequest.onHeadersReceived.addListener(onHeadersReceived, { urls: ['<all_urls>'] }, ['blocking', 'responseHeaders'])Personally I don't think this change will stick in the form proposed in the draft as having declarativeNetRequest as the only blocking option makes it impossible to write things like uBlock Origin or uMatrix, which could create terrible PR for Google, given their Ad business.
If the worst comes to the worst, for the basic functionality we may be okay with declarativeNetRequest and some elaborate rules for redirecting https?://*/ip(f|n)s/* and https?://*.ip(f|n)s.*/, but supporting DNSLink in current seamless form may be difficult/impossible (or would require user action/opt-in per site).
Replace background pages with ServiceWorkers
We plan to replace background pages with ServiceWorkers, registered at install time and granted access to extension APIs. [..] We will be able to reduce the amount of extension-specific code since, instead of implementing a custom background-running presence, we can extend the existing ServiceWorker context. Most importantly, the platform will evolve with the open web; as improvements to ServiceWorkers and the web platform are made, the extensions platform benefits from those same improvements.
We need a stable, persistent background presence to be able to run embedded js-ipfs node. It does not sound like SeviceWorkers, which is often killed by the browser when idle. I hope there will be an inexpensive and reliable way to keep SW alive in WebExtension context.
If not, @Gozala had some ideas on keeping ServiceWorker alive in https://github.com/ipfs/in-web-browsers/issues/137#issuecomment-450530548, but the net result will be to actually use more CPU by artificially keeping it alive than when having a background page.
Restricting Origin Access
In Manifest V3, host permissions will be granted by the user at runtime (similar to activeTab, but with options for the user to choose to always run on a specific site or all sites), rather than install-time.
In Manifest V3, we want activeTab-style host permissions to be the default, with a number of extra options. Instead of being granted access to all URLs on installation, extensions will be unable to request
<all_urls>, and instead the user can choose to invoke the extension on certain websites, like they would withactiveTab. Additional settings will be available to the user post-installation, to allow them to tweak behavior if they so desire.[..] In the default case (click-to-run), it is clear to the user when the extension is running, and has a safe default (not running on any site). When the user chooses to invoke the extension on a given site, there is implicit understanding that the extension will "see" the contents of the page.
This sounds bad, as it suggests by default it will be click-to-run, but in later section about host permissions support for <all_urls> is described as open question:
Open question: Should
activeTabbe removed in favor of specifyingin the host_permissions key of the manifest?
Also, this blogpost from 2018 suggests how the UI will look like:
Beginning in Chrome 70, users will have the choice to restrict extension host access to a custom list of sites, or to configure extensions to require a click to gain access to the current page.
Cross-Origin Communication
Beginning in Manifest V3, content scripts will not be given special privileges regarding the requests they can make. If a content script needs access to data fetched from a cross-origin server that requires authentication, it can proxy the request through its background page using extension messaging.
As long they limit this restriction to Content Scripts, we should be fine.
We do CORS-but-not-really to IPFS API only from the background page. "Not really" because we remove Origin header from requests made to API URL by js-ipfs-http-client running in WebExtension context to remove need for manual whitelisting via Access-Control-Allow-Origin at go-ipfs: src/lib/ipfs-request.js#L119-L151.
Promise-Based APIs
Extension APIs will be promise-based. The older callback version will continue to be supported.
I was about to say its cool, as there will be no need for mozilla/webextension-polyfill, but we will probably need a polyfill for all the other breaking changes. Time will tell, so far issues to follow:
- Migrate apps/extension APIs to use Promises instead of callbacks
- Extension APIs should be also exposed under
browser.*to match the WebExtensions spec
Dynamic Content Scripts (P2)
we can allow extensions to dynamically add and remove, or enable and disable, content scripts. This would allow extensions to only add these scripts once they have permission to do so.
There are additional situations in which this is beneficial, as well. Currently, the advice for extensions wishing to dynamically inject scripts based on some knowledge at runtime is to use the
tabs.executeScript API; however, this is insufficient for certain use cases. In particular, this cannot (reliably) insert a script before the page finishes loading, which is a feature that content scripts provide. Allowing dynamic content scripts would solve this use case.
This is good news, as it would solve issue with window.ipfs described in https://github.com/ipfs-shipyard/ipfs-companion/issues/362#issuecomment-362231167
(browser.contentScripts works in Firefox, but it's not implemented in Chrome yet)
Refactoring of various APIs
Additional work and duplicated code, but nothing critical.
Sad realization: even if Firefox follows these V3 API changes, for some time it won't, while Chromium will, so it will be like writing websites in 90s with similar level of code duplication for achieving the same thing in two different browsers :|
ps. what a perfect issue number :ok_hand:
Gozala
nonchip
meandavejustice
guest271314
whizzzkid
SgtPooki
BigLep
As flagged by @dignifiedquire the proposed webextention api changes under the banner of the v3 manifest work will reduce the scope of what ipfs-companion is able to do to bring ipfs to the browser
Proposed changes: https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3NzzhHzc-qnk4w4PX-0XMw8/edit?usp=sharing
Tracking issue: https://bugs.chromium.org/p/chromium/issues/detail?id=896897&desc=2
Most significant is the move away from the webRequest api to the declarativeNetRequest api https://developer.chrome.com/extensions/declarativeNetRequest
The
webRequestapi is blocking. Chromium asks the webextention what to do about each outbound http request at runtime. IPFS Companion makes use of this to let the user toggle between redirecting ipfs addresses to a local daemon or the public gateway.The
declarativeNetRequestrequires extentions to tell chromium in advance, what urls patterns they wish to block or redirect by defining them statically as rules in themanifest.jsonThere may well be other important changed for us in that doc, but this one stands out as the most significant.