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.

[1] - https://github.com/intoli/remote-browser

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.

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.

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

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?

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.

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.

> 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?

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.

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.

undefined

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?