MV3 Limitations Frustrations - Remotely Hosted Code

[LipSurf]

We use remotely hosted code in our extension LipSurf for a few reasons. Our extension has it's own "plugins" that are similar to TamperMonkey scripts to bring voice functionality to specific websites. There are far too many websites with far too idiosyncratic behavior to cover them all, and not everyone needs all the plugins. E.g. users with disabilities often need Gmail, YouTube, Reddit, and Google Calendar plugins etc, language learners need often want Duolingo, WaniKani etc.

Additional reasons we use dynamic scripts:

1) keep paid features behind a paywall - only if the user signs in to a paid account are scripts downloaded that have paid functionality. Without this, a user can trivially get access to paid features.

2) Allow for plugin development. Just like Tampermonkey, anyone is free to make a plugin for LipSurf, to easily add voice control to any website. They then need to load the plugin into the extension. This seems like it will still be possible if user-loaded code is allowed? Are there any official resources on that?

3) Keep the size of the extension minimal - don't include plugins that the user doesn't need... there's an infinite number of websites, but not all users use voice control on every website.

I understand why the Chrome Extensions team thinks it's a good idea to enforce MV3, to cut costs on reviewing extensions... but the power of Chrome Extensions is being so severely limited that the end users are going to suffer. Why can't a sensible middle-ground be found? For example:

* Charging an extra fee to review Chrome Extensions that are MV2

* Charging a fee to expedite reviews

* Only allowing registered companies to use MV2

* Warning the users of the dangers of MV2 or checking a waiver box

* Letting companies pay for a special security reviewed badge on CWS

There seems to be good alternatives that are less extreme than phasing out all remote code execution. It's a powerful feature that enables some of the most powerful extensions today. Extension development has only gotten more limited and frustrating over the years. As an extension developer, things really seem to be going downhill and it's not a promising platform to continue working with. More than introducing features, MV3 introduces limitations.

[Cuyler Stuwe]

Yeah. It's not about you or me, and it's not about the users. It's about Google.

When Google first introduced extensions, it was competing for market share. It needed to care about enabling the functionality that its users wanted, in order to attract users. It needed a powerful extension system in order to compete with Firefox, and so it was implemented as such.

These days, however, Chrome is now a dominant browser. Google as a company doesn't feel quite as much pressure to get users excited about their browser; Most people just install it immediately on a new system these days. Google is more concerned with liability ("security") and tends to have a company-wide focus on businesses over individual users. In the endless war between features and security, Google seems to feel that the businesses it's targeting would err on the side of a more-secure system that isn't capable of doing as much.

[Cuyler Stuwe]

On top of all of this, I think that over the past ~10 years or so, Google has been really infiltrated by an extreme philosophical/political shift away from libertarianism and more toward socialism. It's easy to see when you go onto Twitter and view the tweets of prominent Googlers.

Inherent to this shift is the assumption that large entities (governments, companies, etc.) should take responsibility for protecting individuals from themselves, rather than making it easy for individuals to take their own calculated risks.

Personally, I think that the day Google makes it hard to develop a decent ad-blocking extension is the day that browser share will start shifting back toward Firefox or something else. Google really does have extension developers to thank for Chrome becoming as popular as it did. Mandatory MV3, as it stands, may very well be the beginning of the end of Chrome's popularity. (!RemindMe: 5 Years)

[LipSurf]

Sorry I forgot to mention one important use-case for us:

* Allow for quickly updating broken plugins. Websites are constantly being updated and LipSurf needs to keep pace to have valid selectors for the most-current versions of websites. Currently, we can fix such issues in the remotely hosted code without going through a whole code review. With MV3 the whole extension would need to be updated, and it would remain broken for much longer given how long reviews have been taking. This means the quality will greatly suffer since problems can't be fixed quickly.

[hrg...@gmail.com]

Here's an idea for you people at Google.

Allow developers to upload the extension package separated in two parts: a main package and an optional package.

The main package is the usual package that users download and install when they click on "Add to Chrome".

The optional package is a collection of files that the extension (after installation) can optionally download and execute/inject in the same way it can be done in MV2 with remote files.

Why is this a good idea?

I'll use my own case as an example.

One of my extensions package is about 800KB is size. However, it optionally needs a large amount of JS and CSS files that are downloaded from https://cdnjs.cloudflare.com/ajax/libs/.

They are all third-party libraries that the extension needs for different purposes (jQuery, Lint, JSHint, CodeMirror, js-beautify, etc.). Which in total amount to about 14MB.

MV3 will force me to include all those files in the package. This will also force all users to download an ~15MB package unnecessarily because each user will need only a few files from the entire 14 MB collection of optional files.

Also, whenever I'll need to update my package, you will have to review a 15 MB package instead of just 800 KB. Which will surely increase the review time.

Then, after review, that over-bloated package has to be pushed to everybody in order to update their local copy of the extension.

If instead of all that unnecessary trouble, I could upload those extra 14MB of files as an optional package, then everything would keep working efficiently as is in MV2.

And you would only need to review that large optional package when I need to update it, which won't be very often because they are third-party libraries.

You could provide a special URL so that extensions have access to the files in the optional package. Such as:

https://chrome.google.com/webstore/optional_package/<EXT_ID>/path/to/file.js

Then the extension can freely choose to use any of those URLs as if they were files in the main package.

That way you keep control over everything the extension runs (which is one of your goals with MV3), but you avoid overloading the internet and everybody's computers with excessively big extension packages and you also alleviate the workload of your reviewers.

You could make this mechanism even better by allowing us to update individual files in this optional package.

That way, when the OP needs to update one of their broken plugins, they will only need to submit for review one or to files in the optional package, instead of uploading an entire giant new package that has to be reviewed all over again.

[LipSurf]

@hrg, I like that idea, and I like that your thinking of solutions. It would satisfy the 3rd and 4th problem I mentioned above for our usecase, and potentially even the 1st.

I could work with this to meet my first requirement if the optional packages names weren't made public as a part of the manifest, or anywhere else in the CRX provided to end-users. 

Then extension developers could authenticate the user as per usual, make an authenticated GET request to get a private "manifest" that would return the "keys" to the optional package name, which then an API (perhaps something like `runtime.getOptionalPackageURL`)

could use to return the contents of extra packages.

[Glen Chiacchieri]

Totally valid points and I like the solution provided by HRG. I think the main concern for MV3 was not necessarily cutting review times but tightening down security so that untrusted/unreviewed code couldn't be used in extensions (especially if the remote code got hacked or sold to a third party and replaced with something sketchy). It's my understanding that this is one of the big attack vectors for extensions.

[Evan Carothers]

How are you executing your remote code currently (as a content script, or injecting into the DOM?). From what I can tell you will still be able to load/inject/execute scripts in the global namespace/DOM (since there's no technical way for them to restrict this), only content scripts won't be remotely loaded. What we do with a similar use case is use configuration files (JSON) to indicate what sites content scripts can run on and what scripts to load, then use a generic extension-hosted content script on those pages to then load and execute the remote scripts in the global DOM context of the pages. See Simeons reply here for reference https://groups.google.com/a/chromium.org/g/chromium-extensions/c/EzpG87sNCQQ/m/gmL78qGTDAAJ (though I would love Simeon's confirmation on this). The downside of this approach is that it requires broad host permissions to be able to execute on any new pages we add for support.