▲ 172 points
back
161 comments
I'm one of the authors of a browser automation framework called remote-browser that's built on top of the Web Extensions API [1]. The meaning behind the name is that you have access to a Web Extension API browser object in the client environment that gives you remote access to the full API. That offers enough power to do complex browser automation tasks along the same lines of what you can do with Selenium or Puppeteer, but simply using vanilla JavaScript and the Web Extensions API instead of tons of browser-specific implementation code and a custom automation API. If Firefox follows Chrome's lead on removing executeScript, then it will effectively kill the remote-browser project.
I find it very unfortunate that the capabilities of browser extensions are being crippled. I understand that there are significant security issues with browser extensions, but the same general purpose APIs that allow abuse simultaneously allow really wonderful and powerful things to be built. As a developer who loves extending and personalizing their browser, it's simply depressing to see that go.
> I understand that there are significant security issues with browser extensions
Sure, there are significant security issues. Since when is that a reason to disable a user-originated threat vector? As long as the user in question is informed and alerted to the potential security risks shouldn't it be within the user's purview to decide what to allow and what not?
Even if this line of argument cannot be said for every purpose - and I understand there is a potential for abuse and misinformation about misrepresenting any specific extension - but for instance say Tampermonkey, which the user needs to first download from the webstore then the user needs to also download the script, can't there be sufficient warning that what the user is doing is potentially harmful? Or a requirement from the webstore that Tampermonkey somehow also alert users before loading any remote scripts?
If a user decides to downright download malware we let them (Given, Chrome would block it but you can override that manually) why wouldn't the user be allowed to override these risks (i.e. you can enable it only in development mode etc. with a requirement that such extensions provide sufficient warnings etc.)
I get annoyed with the 'think of the (metaphorical) children' school of safety. If you want to do something to improve people's safety awareness - make actual browser dialogs and chrome distinctive and unforgable (maybe a special window chrome or something).
Half the time now, I just close tabs because I'm not sure that lil 'x'(close) on the ad that popped up isn't part some malware. When its too easy to duplicate 'official' looking stuff, people become numb to seeing it all the time.
I have some personal projects I might finally get a chance to work on a bit and they were all intended to use remote-browser, now you have me worried.
however I see no reason why firefox should follow chrome on this? Also my natural paranoia in regards to the motivations of Google make me think maybe executeScript is too powerful and allows the extension makers to do things that are not malignant, but just against the corporate interests of Google.
I think you’re using the wrong API. For remote automation you should be using the chrome devtools protocol[1]. It is meant for your purposes and gives you full script injection functionality and dom access.
What is being crippled here? The API is being moved to another objects and restructured in a way that's not as haphazard for actual extension development and distribution.
If this doesn't work for your specific use case, write a wrapper object - your point is that the API was stable with V2, but it will still be with V3 and you should be able to rely on that.
Am I missing something?
They already disallowed remote code loading in extensions with a Chrome Web Store policy update nearly two years ago. They didn't have to invent a new API full of breaking changes to do it.
Just one example of the many disingenuous arguments in this post.
They didn't need to start from scratch to achieve the stated goals of security and performance. For Manifest V3 to be a rational conclusion, there must be additional unstated goals. Such as destruction of ad blockers, a desire to no longer maintain extension support or Chrome Web Store, or the need to run CWS with a skeleton crew.
None of these unstated goals benefit users or developers which is why we have to endure a gaslighting campaign about how smart and great Manifest V3 is.
I think extension developers have been crystal clear from day one about how regressive this change is.
> They already disallowed remote code loading in extensions with a Chrome Web Store policy update nearly two years ago. They didn't have to invent a new API full of breaking changes to do it.
Blog post author here. This comment is incorrect on two main fronts.
First, the Chrome Web Store's Developer Program Policy did not prevent the use of remote code, it only forbade the obfuscation of remotely loaded code. An alternative, stricter reading of the policy was that extensions could not use remotely hosted code to obfuscate it's operations. Regardless of which of these interpretations you favor, using remotely hosted code in Manifest V2 extensions is not forbidden by our policies.
Second, I strongly disagree with the implication that policy changes could have addressed the abuse issues we're seeing. Even if we did have policies disallowing the use of remotely hosted code, that does not somehow compel developers to comply or simplify the enforcement process. I have a ton of respect for my colleagues in review, but policy enforcement is complex and virtually impossible to get right 100% of the time. So, some amount of malware will get through review, some number of users will be exploited, and some amount of harm will result. How much harm should we accept as "the cost of doing business", especially when we have a way to address a major exploit vector?
Speaking as a developer, I'm not exactly thrilled to lose capabilities that I've been using responsibly because other people are exploiting them. On the other hand, as a member of the team maintaining this platform I don't see a practical alternative to address the problems that arbitrary code execution presents for the average user.
> They didn't have to invent a new API full of breaking changes to do it.
Isnt that what google normally does? Instead of fixing an existing product, throw it away and introduce a new shiny thing, that does the same thing.
Could not agree more! Firefox begining to support V3 is also extremely troubling; regardless of the compromises they are offering for adblockers. We need to resist this.
One thing I've often found strange about Chrome and extensions is how there is no support for it in the mobile version and it's been downloaded 1B+ times and nobody complains about it.
While the capability for running extensions on mobile chrome has always been there and is quite evident with the chrome forks like "Kiwi browser" which runs every chrome extension including ublock just fine.
It only shows how Google must have deliberately decided to purposely never support extensions on mobile from day one.
I mean it's much harder to give something and take it back, so you generally phase out functionality out by citing security issues and that's what I think is this whole v3 fiasco is all about too.
Google's biggest source of revenue is from web ads. They deliberately choose to not have extensions on the mobile version as it would mean that users could install ad block extensions, causing them to miss out on potential earnings from mobile ads.
> it's been downloaded 1B+ times
Play store download numbers are meaningless for a pre installed app. Chrome is installed by default on all Android phones and you cannot remove it. If you disable it, often some other things like webview do not work well.
Firefox's app (at least on Android, not sure about iOS) lets you install some extensions, notably uBlock origin.
> and nobody complains about it.
Lots of people complain about it. Maybe fewer for a few years now that we know it is missing and Google really doesn't care about adding this feature... ever.
I complain about mobile chrome being a hostile anti user shit show multiple times a quarter on the internet. it's an incredibly cursed thing that the place users need the most chance to improve their lot, they are given nothing.
It's maybe not that they don't support extension per se, just that they implement much more features and include much more feedback on mobile, so no need to let people do it themselves ?
I use less and less extensions, not even the dark mode ones now that websites are changing too (I wish HN would too)
Raymond Hill of uBlock Origin has claimed[0] when this was introduced that this update would make uBlock Origin ineffective. Does anyone know if that's still the case?
[0] https://bugs.chromium.org/p/chromium/issues/detail?id=896897...
EDIT: I'm referring the the 'Manifest v3' update as a whole, not to the specific API change discussed in the article
Both things are under the "manifest v3" umbrella. He was complaining about the deprecation of the blocking version of chrome.webRequest
The change described here is something else under the same umbrella. Not the change he was talking about. But generally, the whole of "manifest v3" will render lots of useful extensions dead in the water. Any heuristic ad blockers, things like tampermonkey, etc. If you want things like that, you'll have to move to Firefox.
So, uh. What does this mean for extensions whose purpose is injecting arbitrary script/CSS content, like Greasemonkey or Stylus? Are they just out of luck?
The developer of Tampermonkey has already raised this concern when Manifest v3 was first introduced.[0]
[0] https://groups.google.com/a/chromium.org/forum/#!topic/chrom...
Original blog post author here. The short answer is that Manifest V3 does not currently support these extensions (or their broader use cases), but we want to support them and have some ideas that we plan to explore.
Maybe CloudFlare/Apple can add MITM scripting as a feature of Private Relay.
V3 is a cancer. As a full time extension developer I am dreading the notion of chrome successfully deprecating V2. Hopefully developers can rise up against V3 before it's too late.
What changes are you most concerned about? How does Manifest V3 negatively impact your extensions?
You may want to consider getting involved in the recently announced WebExtensions Community Group in order to discuss your concerns with the future of browser extensions with browser vendors and other extension developers.
http://w3c.org/community/webextensions https://github.com/w3c/webextensions
What action can we take? Switching browsers is hardly going to make G blink.
Edit: I want add, recently built my own Firefox - pulled out all the Pocket shit and tweaked the UI a bit "my way". Was actually not that hard. I'd love to see 20 forks of Firefox trying different things. Also, anyone know what happened to Librefox?
As the Tampermonkey devs put it:
> Every little userscript would then have to become an own extension. Anyone who wants to do that has to pay $5 to be able to publish an extension.
So this seems like a good way for Google to make money...and to exert more control by moderating the contents of userscripts.
Is that the right way to look at it? I don't believe this can ever scale to an amount that is even visible to Google.
Even by poorest-country standards, a one-time $5 is pretty reasonable. It's basically only a minimal deterrent against unlimited generations of bots.
Now compare that to what Apple charges
You don't have to publish an extension to side-load it.
> While Manifest V3 extensions can't use code that isn't bundled with the extension
Does this mean they're not allowed to write to the DOM? Because if they are allowed to write to the DOM, they can just add a script tag that loads a script from an arbitrary URL.
Also, the example shows a use of fetch. What keeps the script from eval-ing a string from the result of that fetch?
Am I misunderstanding the security model here?
> Because if they are allowed to write to the DOM, they can just add a script tag that loads a script from an arbitrary URL.
By my understanding, this is still possible. If you dynamically inject a script tag, your code runs in the JS context of the page itself.
On the other hand, the chrome.tabs.executeScript API referred to in this article injects a "content script", which runs in an isolated world and has access to all of the same extension APIs that statically-deployed code does. As I understand it, this is what they're really aiming to prevent: dynamically-loaded code that runs in the extension's privileged context.
There's a section at the end of the design doc that explicitly lists preventing arbitrary code execution in page contexts as a non-goal, at least for now: https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3Nzz...
> Also, the example shows a use of fetch. What keeps the script from eval-ing a string from the result of that fetch?
As I mentioned in another comment, Manifest V3 bans the use of eval() in extension code. If you inject a script tag into a page, that script may or may not be allowed to call eval(), depending on the page's content security policy.
> Because if they are allowed to write to the DOM, they can just add a script tag that loads a script from an arbitrary URL.
No they couldn't, because CSP still applies. Even if the extension itself can inject a script element as DOM node, the actual loading of the script's source would still get blocked because it's not being loaded from a trusted source.
We need a browser project whose explicitly stated goal is to act as the user's agent. No, Mozilla's "open internet" nonsense doesn't cut it anymore. There's no point in an open internet if every web browser acts against its users.
Every decision taken by the browser developers should only keep in mind the requirements of the users. You want to play DRM content? Sure, we will get that certification but also provide extension APIs that let you save the stream to your disk.
You want to block ads? Sure we will let you load an extension that will do that. No store, no signing, no crap.
> we will get that certification but also provide extension APIs that let you save the stream to your disk.
That means they will not get the right certification for DRM. The main reason behind them is to prevent saving the stream.
So they're killing userscript managers. This and the other manifest v3 shit with adblocking, google needs to die soon.
Yet another decision that uses safety and security concerns as a cover for corporate concerns.
When all browsers were finally coalescing into a unified API for WebExtensions, Google comes in and just throws in a whole new namespace with a new API...
hmm, they don't mention `eval()` being blocked in executed functions. Is it mentioned elsewhere?
Also, can't executed function just add `<script>` tag with given `src`?
Is it possible to write an extension for personal use and have it inject JS and extract information from my own browsing activity without much red tape?
I have a script that would read out the page (TTS) and save the passages it reads to a log, for now it is a bookmarklet.
This seems like a response to The Great Suspender fiasco. There are some conspiracy theories about Google, but that situation was potentially really bad for users. Nobody really knows how bad it actually was given how many installs the extension had.
And yet the situation could happen again today without anyone being the wiser for months.
Sorry, I am not very technical. But does this line from the article mean that your extension can run other scripts?
Specifically, we wanted to add support for dynamic content scripts and to expand the capabilities of the executeScript method.Possibly dumb question, but I'm confused by the apparent overlap:
What's the difference between chrome.scripting and a content script that you pass messages to?
More Big Tech protecting us from ourselves. Awesome.
For a second I thought this is a domain.
Microsoft Edge would work too?