As someone involved in the WebExtensions Community Group who has been (slowly) trying to figure out what, if anything, we should do at the platform level around these use cases, I appreciate you raising and repeating this concern. I'd be obliged if you have any other recommended reading around this topic.
Oh, this is interesting! I assume most of the heavy lifting to identify and filter content is being performed by the content script. In practice have you see any issues with models accessing page content before the extension has been able to sanitize the page?
Do you mean Firefox on iOS? If so, that would require the firefox-ios project to adopt BrowserEngineKit, which is relatively new. Firefox for iOS WebExtension support is being tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1497374
Just took a quick glance at your extension and observed that it's currently using the "debugger" permission. What features necessitated using this API rather than leveraging content scripts and less invasive WebExtensions APIs?
Simeon from the Firefox Add-ons team here. Sorry about the rocky experience. I realize this is a bit late for your situation, but earlier this year the source code submission docs were updated with information about the default reviewer build environment[1].
It's not a huge improvement, but it sounds like one thing we could do to improve the communications process around build errors is to include a link to this documentation in the notification email sent to developers. I'll create a ticket for this now.
I was about to say "concurrent writes shouldn't be a problem because localStorage is synchronous and JS is single-threaded," but then I started thinking about multiple tabs, WebWorkers, and multi-process browsers and figured I should double-check the spec.
> Warning! The localStorage getter provides access to shared state. This specification does not define the interaction with other agent clusters in a multiprocess user agent, and authors are encouraged to assume that there is no locking mechanism. A site could, for instance, try to read the value of a key, increment its value, then write it back out, using the new value as a unique identifier for the session; if the site does this twice in two different browser windows at the same time, it might end up using the same "unique" identifier for both sessions, with potentially disastrous effects.
I don't know exactly what the the person you're replying to had in mind, but support for different parts of the manifest varies (especially in Manifest V3). While it's possible to write a single manifest that works in all browsers (with warnings), doing so requires more than a little specialized knowledge.
For example, Firefox does not currently support the `optional_host_permissions` top level manifest key. To work around this, developers can declare their optional host permissions in both the `optional_host_permissions` array for Chrome compatibility and in the `optional_permissions` array for Firefox/Safari compatibility.
Another example is that currently only Chrome supports `background.service_worker` in stable releases. To work around this, developers can write their MV3 background scripts in a way that's compatible with both service workers and event pages, then declare both in the manifest like so:
To my knowledge no browser supports transferring an extension's user base from one extension to another. If you want your users to switch, the only think you can do is show them a link of where to get the new extension they should install.
> The extension ID is derived from a private key that the developer uploads with the first upload to the app store
While what you described is possible, this process isn't required or the typical way an extension ID is generated. Typically developers just upload a ZIP file on their first submission, then CWS will generate and store a private key to sign the extension for public distribution.
> and the ID will change if any subsequent uploads include a different key.pem in their zip file
CWS should never change an existing extension's ID. The ID is what I uniquely identifies an extension. If the ID changed, Chrome clients wouldn't be able to request an updated version of that extension. CWS & Chrome do not support migrating users from one extension to another.
To the best of my knowledge CWS will reject an extension if the zip after the first submission contains a key.pem file.
> Therefore, if the extension ID changes, it's possible the owner changed.
If the extension ID changes, it's not the same extension.
> then the new owner could push changes without even needing access to that key.
This is mostly true, but there is one case where developers CANNOT update an extension without the PEM: if the dev signed the extension they submitted to CWS. To be honest I'm not even sure this is possible to do any more; as I recall this feature was a huge foot-gun and often ended up causing developers to lose their install base because they lost their private keys that they used to sign their own uploads.
> If the idea is that these DNR rules require non-fast-trackable thorough reviews, but dynamically updating them will bypass those thorough reviews, than I am at a lost to understand the logic of treating them as requiring thorough review.
While they solve similar problems, these are different systems with different constraints.
* In order to allow something through the review process without close examination, you need to be sure it will not compromise end users. The block, allow, and allowAllRequests actions are known to present minimal risk to user's web browsing activities. The same cannot be said for redirecting requests or modifying a request's headers.
* Dynamic rule registration logic can be statically analyzed for risk assessment purposes. For example, say you're looking at two extensions that both have dynamic rules. Extension A only dynamically register block rules based on remote configuration. Extension B has <all_urls> and passed an arbitrary JSON object to the updateDynamicRules call. Personally, I'd be very concerned about what Extension B could do at the developer's behest, whether intentionally or if the dev's servers are compromised. IMO Extension B may even cross the line on what store policy permits.
* Expectations for extension's static content are different from an extension's dynamic operations. If an extension has code that explicitly does something nefarious and that passes review, the review process will be raked over the coals by commentators. If an extension's static contents are benign but a developer makes it do something nefarious at runtime, there is more understanding that this behavior may not have been visible to reviewers during the review process.
I'm sure there are more differences worth mentioning, but I need to run.
As a final parting thought, if safe rules and fast track review were already implemented and dynamic rules were being proposed today, I expect we'd be having conversations about whether or not devs should be able to register unsafe dynamic rules. I think there's a realistic possibility that we wouldn't allow it. Or if we did, that this capability would be gated by a new permission with a warning.
No one does at the moment. The deprecation is on hold, but Chrome has stated that they "will provide at least 6 months between a timeline announcement and any experiments deprecating MV2 features": https://developer.chrome.com/docs/extensions/migrating/mv2-s...
> I wonder if the main obstacle to (actual) cross-browser extensions isn't so much technical but rather political.
Normally when browser folk talk about "cross-browser extensions," we're not focusing on the distributable package so much as the source code. As you suggest, there are a variety of reasons that browsers aren't terribly interested in having a single authoritative distribution channel. For that matter, the packaging format is explicitly not something we intended to discuss in the WebExtensions Community Group[1]. While we diversity in how extensions are marketed and distributed, we want the actual code of the extensions to be as reusable as (reasonably) possible.