32 ms·

Introducing chrome.scripting

172 points by pentagrama 5y ago

duskwuff 5y ago
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?
- rektide 5y ago
  yes. endless creative solutions, hosed. but it also won't really stop people who would do dynamic scripts. itcll just damn the casuals, the sensible would-be greasemonkey users. google can't be so stupid as to believe these pathetic snivelling excuses they throw at us about security. we don't need dynamic scripts to dynamically make workloads, because we can build interpreted virtual machines with JavaScript that will run whatever dynamic code we want, without the executing code being dynamic. this is all a sick sick sick dance to take power from users. to make extensions less obviously useful. it's absolutely gross. none of the presented arguments hold any water, and it's obvious. or they really just are very bad at this, don't see the obvious, & are escalating a problem unnecessarily, while hurting the well intending friendly would have been enthusiasts.
  - dan-robertson 5y ago
    I think chrome developers probably do care a lot about security (and performance and privacy). There is a big conflict of interest because chrome is developed by an enormous on-line advertising company and online ads, ad-blockers, and malware pretending to be ad-blockers may cause security, performance, or privacy problems. It is an interesting thought experiment to wonder what chrome would be like if it were more independent, but I think it is wrong to assume that the developers are deliberately malicious or uncaring about users’ interests.
    - colordrops 5y ago
      > It is an interesting thought experiment to wonder what chrome would be like if it were more independent Firefox? Brave?
    - rektide 5y ago
      it just seems so trivial to me too build a small interpreted system that circumvents the "no dynamic JavaScript" rule. so so so trivial. so the only people hurt are the regular humans. there was a simpler example on hn within the last week or two, but for example, json-rules-engine demonstrates how json might be a dynamic program, without ever needing to call eval or Function dynamic code: https://github.com/CacheControl/json-rules-engine https://github.com/CacheControl/json-rules-engine this would need to be extended with some html constructs. which is certainly possible. or take evaljs and preload in some html functions! > You might be working in a JavaScript environment where eval() isn't allowed (and you have a genuinely good reason why you want to use it). Maybe this'll slip under the radar. https://github.com/marten-de-vries/evaljs https://github.com/marten-de-vries/evaljs surely the people pitching these so called security measures grok just how many dump trucks of nonsense these so called protections they offer us are. about a week ago maybe even it would have sounded ok. but since that time, we've had a big announcement that wizer can now run spidermonkey js engine in webassembly. there's industrial grade js machinery we can run, free from these constraints, nested inside the web platform. with that, this v3 announcement is a week too late to hold even a drop of water. https://news.ycombinator.com/item?id=27370138 https://news.ycombinator.com/item?id=27370138 I believe they want to do something good too. but they are ineffectual & doing amazing amounts of damage in their grasp to give us this pretend fake security.
      - shadowgovt 5y ago
        If you can make a proof-of-concept, that'd be a good thing to share on HN.
      - rektide 5y ago
        I have suggested using Wizer's spidermonkey wasm to the Tampermonkey "v3" issue[1]. [1] https://github.com/Tampermonkey/tampermonkey/issues/644#issuecomment-857838249 https://github.com/Tampermonkey/tampermonkey/issues/644#issu...
      - dotproto 5y ago
        > it just seems so trivial to me too build a small interpreted system that circumvents the "no dynamic JavaScript" rule While it's possible to build an interpreter in JS, doing so in an extension is an unambiguous violation of the Chrome Web Store Developer Program Policy. The goal isn't to make abuse impossible so much as to limit potential attack vectors in order to make enforcement more tractable.
    - ROARosen 5y ago
      > I think it is wrong to assume that the developers are deliberately malicious or uncaring about users’ interests They are not 'uncaring' for users interests, they are just more caring to their company's interests than to those of their users.
- ROARosen 5y ago
  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/chromium-extensions/hQeJzPbG-js https://groups.google.com/a/chromium.org/forum/#!topic/chrom...
  - hypertele-Xii 5y ago
    Seems to be exactly the intended effect. Tampermonkey essentially bypasses extension store security entirely by running "extensions" off-store, making people vulnerable to malware the browser vendor can't police.
    - zarzavat 5y ago
      Users could achieve even better security by turning their computers off.
    - ROARosen 5y ago
      > Seems to be exactly the intended effect This API change is making it worse for Tampermonkey than for malware. "Malware" extensions canstill be explicitly "sideloaded" to Chrome in developer mode. Closing this API means Tampermonkey won't be able to run even when sideloaded. If this was truly their only concern they could have just blocked Tampermonkey and comparable extensions from the webstore. , rendering just as 'safe' as any other sideloaded chrome extension.
- TechBro8615 5y ago
  Maybe CloudFlare/Apple can add MITM scripting as a feature of Private Relay.
- dotproto 5y ago
  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.
Lex-2008 5y ago
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`?
- teraflop 5y ago
  It's not mentioned in this page or the Manifest V3 design document[1], but buried in the "Migrating to Manifest V3" article[2], there's a slightly cryptic note: > In addition, MV3 disallows certain CSP modifications for extension_pages that were permitted in MV2. The script-src, object-src, and worker-src directives may only have the following values: self; none; Any localhost source, (http://localhost http://localhost, http://127.0.0.1 http://127.0.0.1, or any port on those domains) In other words, scripts with access to the extension APIs are no longer allowed to specify the "unsafe-eval" CSP, and so they can no longer call eval(). [1]: https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3NzzhHzc-qnk4w4PX-0XMw8/edit https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3Nzz... [2]: https://developer.chrome.com/docs/extensions/mv3/intro/mv3-migration/ https://developer.chrome.com/docs/extensions/mv3/intro/mv3-m...
- ROARosen 5y ago
  See here: https://news.ycombinator.com/item?id=27442622 https://news.ycombinator.com/item?id=27442622
daxelrod 5y ago
> 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?
- teraflop 5y ago
  > 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/1nPu6Wy4LWR66EFLeYInl3NzzhHzc-qnk4w4PX-0XMw8/edit#heading=h.icj5clwxt3mw 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.
  - daxelrod 5y ago
    > As I understand it, this is what they're really aiming to prevent: dynamically-loaded code that runs in the extension's privileged context. Thank you, this is extremely helpful for me understanding the security model here, and explains what I was missing.
  - dotproto 5y ago
    For clarity, injecting a script that is not included with the extension is expressly disallowed by the Chrome Web Store Developer Program Policies. > Some common violations include: > > * Including a <script> tag that points to a resource that is not within the extension's package https://developer.chrome.com/docs/webstore/program_policies/#:~:text=additional%20requirements%20for%20manifest%20v3 https://developer.chrome.com/docs/webstore/program_policies/...
ROARosen 5y ago
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&desc=2#c23 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
- tyingq 5y ago
  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.
  - ROARosen 5y ago
    I understand he was referring to a different API than the one discussed. My question is if the API change he was referring to is still being implemented in Manifest v3 (I've edited my comment accordingly).
    - deleted 5y ago
      [deleted]
    - tyingq 5y ago
      I don't think Google has said when extensions with Manifest V2 will no longer work. And, technically, you can still use the blocking webrequest in a Manifest V3 extension, if the extension is "force installed". I think they are waiting for the hoopla to die down a bit before they close the door hard.
    - ece 5y ago
      It seems like Firefox will support Manifest v3 in a way that doesn't break compatibility with other browsers and support the blocking webRequest API as well: https://blog.mozilla.org/addons/2021/05/27/manifest-v3-update/ https://blog.mozilla.org/addons/2021/05/27/manifest-v3-updat...
stickfigure 5y ago
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?
- teraflop 5y ago
  Content scripts can be loaded into a page either statically, when the page URL matches a regex listed in the manifest, or dynamically, by calling chrome.tabs.executeScript (in V2) or chrome.scripting.executeScript (in V3). Once the content script is loaded, AFAIK its execution behaves the same no matter how it was loaded.
tooker 5y ago
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.
- edoceo 5y ago
  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?
  - Lammy 5y ago
    That seems doomed to eventual irrelevance since web standards are now constantly-moving goalposts also authored by companies like Google.
    - d3nj4l 5y ago
      This is my place to plug once again that Slack still doesn't support calls on Firefox, over four years since they were launched.
  - smolyeet 5y ago
    Until Firefox us taken seriously by tech companies not google , it's inevitable. I've yet to encounter a website that doesn't work on chrome , but FF is a gamble between it not being supported or prevent ad tracking breaks it. Can't use teams in web despite it running a bit better than desktop , can't use most of my apple websites for work, least not without some extension so it's really just frustrating. Honestly if chrome introduced bottom url bar and extensions without limitations... I'd switch back. I didn't switch for privacy but because chrome mobile is is clunky as a web app and I use my phone a lot during the day.
    - breakingcups 5y ago
foob 5y ago
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 https://github.com/intoli/remote-browser
- ROARosen 5y ago
  > 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.)
  - xyzzy_plugh 5y ago
Crazyontap 5y ago
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.
- xwolfi 5y ago
  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)
- rektide 5y ago
  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.
  - mikelward 5y ago
    Seems like an opportunity for another browser, e.g. Edge, Opera, Vivaldi, etc.
    - pandeiro 5y ago
      Moved off it to Vivaldi, haven't looked back.
- perryizgr8 5y ago
  > 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.
heavyset_go 5y ago
Yet another decision that uses safety and security concerns as a cover for corporate concerns.
- pandeiro 5y ago
  You think they would actually do that?
deleted 5y ago
[deleted]
jasonhansel 5y ago
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.
- holistio 5y ago
  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.
  - dannyw 5y ago
    The right way to look at it is that Google wants to maintain control over the web, and remove the ability for user-agents to do anything that threatens their bottom line (i.e. ability to block ads). Manifest v3's proposed content blocking is hilariously crippled, that Google can simply start generating random class IDs and there's no way for uBlock origin to block ads anymore.
- shadowgovt 5y ago
  You don't have to publish an extension to side-load it.
- contriban 5y ago
  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
perryizgr8 5y ago
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.
- shadowgovt 5y ago
  You want to install a third-party keylogger? Sure, we'll let you ship your own password to a dark web clearinghouse...
  - perryizgr8 5y ago
    Yeah, if the user wants that, why not?
    - shadowgovt 5y ago
      Because the set of users who actually want that is dwarfed by the set of users who got tricked into installing that keylogger.
      - Arnavion 5y ago
        Those users can continue using their coddling browsers on their coddling operating systems.
        throwaway3699 5y ago
        Most people are not technology professionals and enthusiasts like this forum is. Should normal people be forced to put their life savings on the line because they didn't understand the difference between Manifest V2/V3?
lawl 5y ago
So they're killing userscript managers. This and the other manifest v3 shit with adblocking, google needs to die soon.
- dotproto 5y ago
  Manifest V3 does not currently support user script managers, but we are planning to address that gap in the coming months.
SimeVidas 5y ago
For a second I thought this is a domain.
somehnacct3757 5y ago
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.
- tooker 5y ago
  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.
- orangepanda 5y ago
  > 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.
  - somehnacct3757 5y ago
    Or in this case, does less. I think if Manifest V3 had 1:1 capabilities with MV2, less people would care. Google has oodles of devs and infinite money; so their culture doesn't balk at rewrites. In the real world, treading water to stay on the Chrome Web Store with MV3 will muscle out huge swaths of a company's product roadmap. Our execs didn't even know what manifest versions are a year ago. Now Google is on everyone's shit list. If your API change is so jarring that non-technical people have to think about it, you're doing it wrong! This is less of an API change and more of a platform redefinition.
  - heavyset_go 5y ago
pandeiro 5y ago
More Big Tech protecting us from ourselves. Awesome.
tak5651 5y ago
Microsoft Edge would work too?
visarga 5y ago
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.
- dotproto 5y ago
  Sure. If you're the only one using it, you can just run the extension locally as an unpacked extension. Check out the step-by-step getting started guide: https://developer.chrome.com/docs/extensions/mv3/getstarted/ https://developer.chrome.com/docs/extensions/mv3/getstarted/ For your case, you'll probably want to save the bookmarklet as a JS file, let's say content.js, and inject in when you click the extension's icon. Here's the basics to get you started. manifest.json { "name": "Demo", "version": "1.0", "manifest_version": 3, "permissions": [ "scripting", "activeTab" ], "background": { "service_worker": "background.js" }, "action": {} } background.js chrome.action.onClicked.addListener((tab) => { chrome.scripting.executeScript({ target: {tabId: tab.id}, files: ['content.js'], }); }); content.js alert('It worked!');
soapdog 5y ago
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...
invisible 5y ago
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.
peanutz454 5y ago
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.
- dotproto 5y ago
  Yes-ish? So the extension itself is basically a bundle of web resources like HTML, CSS, and JS files. Today, the only way an extension can ask Chrome to automatically inject a content script on a page is to declare what scripts should be injected on which sites in the extension's manifest. For example… "content_scripts": [ { "matches": ["*://*.nytimes.com/*"], "js": ["content-script.js"], "run_at": ["document_start"] } ], This snippet from a manifest file will inject a file in the extensin's bundle called "content-script.js" onto all New York Times web pages the user visits right as the page start loading. The downside to this approach is that this is a static declaration; after the extension is installed it can't say "hey Chrome, I also you want you to inject that same script on BBC websites. In the quote you highlighted, what I was trying to say was that we are also planning to give extensions the ability to modify the set of content scripts while the extension is running. This means the extension will be able to ask Chrome to automatically inject the same script on BBC websites.

172 points by pentagrama 5y ago

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?

rektide 5y ago
yes. endless creative solutions, hosed. but it also won't really stop people who would do dynamic scripts. itcll just damn the casuals, the sensible would-be greasemonkey users. google can't be so stupid as to believe these pathetic snivelling excuses they throw at us about security. we don't need dynamic scripts to dynamically make workloads, because we can build interpreted virtual machines with JavaScript that will run whatever dynamic code we want, without the executing code being dynamic. this is all a sick sick sick dance to take power from users. to make extensions less obviously useful. it's absolutely gross. none of the presented arguments hold any water, and it's obvious. or they really just are very bad at this, don't see the obvious, & are escalating a problem unnecessarily, while hurting the well intending friendly would have been enthusiasts.
- dan-robertson 5y ago
  I think chrome developers probably do care a lot about security (and performance and privacy). There is a big conflict of interest because chrome is developed by an enormous on-line advertising company and online ads, ad-blockers, and malware pretending to be ad-blockers may cause security, performance, or privacy problems. It is an interesting thought experiment to wonder what chrome would be like if it were more independent, but I think it is wrong to assume that the developers are deliberately malicious or uncaring about users’ interests.
  - colordrops 5y ago
    > It is an interesting thought experiment to wonder what chrome would be like if it were more independent Firefox? Brave?
  - rektide 5y ago
    it just seems so trivial to me too build a small interpreted system that circumvents the "no dynamic JavaScript" rule. so so so trivial. so the only people hurt are the regular humans. there was a simpler example on hn within the last week or two, but for example, json-rules-engine demonstrates how json might be a dynamic program, without ever needing to call eval or Function dynamic code: https://github.com/CacheControl/json-rules-engine https://github.com/CacheControl/json-rules-engine this would need to be extended with some html constructs. which is certainly possible. or take evaljs and preload in some html functions! > You might be working in a JavaScript environment where eval() isn't allowed (and you have a genuinely good reason why you want to use it). Maybe this'll slip under the radar. https://github.com/marten-de-vries/evaljs https://github.com/marten-de-vries/evaljs surely the people pitching these so called security measures grok just how many dump trucks of nonsense these so called protections they offer us are. about a week ago maybe even it would have sounded ok. but since that time, we've had a big announcement that wizer can now run spidermonkey js engine in webassembly. there's industrial grade js machinery we can run, free from these constraints, nested inside the web platform. with that, this v3 announcement is a week too late to hold even a drop of water. https://news.ycombinator.com/item?id=27370138 https://news.ycombinator.com/item?id=27370138 I believe they want to do something good too. but they are ineffectual & doing amazing amounts of damage in their grasp to give us this pretend fake security.
    - shadowgovt 5y ago
      If you can make a proof-of-concept, that'd be a good thing to share on HN.
    - rektide 5y ago
      I have suggested using Wizer's spidermonkey wasm to the Tampermonkey "v3" issue[1]. [1] https://github.com/Tampermonkey/tampermonkey/issues/644#issuecomment-857838249 https://github.com/Tampermonkey/tampermonkey/issues/644#issu...
    - dotproto 5y ago
      > it just seems so trivial to me too build a small interpreted system that circumvents the "no dynamic JavaScript" rule While it's possible to build an interpreter in JS, doing so in an extension is an unambiguous violation of the Chrome Web Store Developer Program Policy. The goal isn't to make abuse impossible so much as to limit potential attack vectors in order to make enforcement more tractable.
  - ROARosen 5y ago
    > I think it is wrong to assume that the developers are deliberately malicious or uncaring about users’ interests They are not 'uncaring' for users interests, they are just more caring to their company's interests than to those of their users.
ROARosen 5y ago
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/chromium-extensions/hQeJzPbG-js https://groups.google.com/a/chromium.org/forum/#!topic/chrom...
- hypertele-Xii 5y ago
  Seems to be exactly the intended effect. Tampermonkey essentially bypasses extension store security entirely by running "extensions" off-store, making people vulnerable to malware the browser vendor can't police.
  - zarzavat 5y ago
    Users could achieve even better security by turning their computers off.
  - ROARosen 5y ago
    > Seems to be exactly the intended effect This API change is making it worse for Tampermonkey than for malware. "Malware" extensions canstill be explicitly "sideloaded" to Chrome in developer mode. Closing this API means Tampermonkey won't be able to run even when sideloaded. If this was truly their only concern they could have just blocked Tampermonkey and comparable extensions from the webstore. , rendering just as 'safe' as any other sideloaded chrome extension.
TechBro8615 5y ago
Maybe CloudFlare/Apple can add MITM scripting as a feature of Private Relay.
dotproto 5y ago
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.

Lex-2008 5y ago

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

teraflop 5y ago
It's not mentioned in this page or the Manifest V3 design document[1], but buried in the "Migrating to Manifest V3" article[2], there's a slightly cryptic note: > In addition, MV3 disallows certain CSP modifications for extension_pages that were permitted in MV2. The script-src, object-src, and worker-src directives may only have the following values: self; none; Any localhost source, (http://localhost http://localhost, http://127.0.0.1 http://127.0.0.1, or any port on those domains) In other words, scripts with access to the extension APIs are no longer allowed to specify the "unsafe-eval" CSP, and so they can no longer call eval(). [1]: https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3NzzhHzc-qnk4w4PX-0XMw8/edit https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3Nzz... [2]: https://developer.chrome.com/docs/extensions/mv3/intro/mv3-migration/ https://developer.chrome.com/docs/extensions/mv3/intro/mv3-m...
ROARosen 5y ago
See here: https://news.ycombinator.com/item?id=27442622 https://news.ycombinator.com/item?id=27442622

daxelrod 5y ago

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

teraflop 5y ago
> 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/1nPu6Wy4LWR66EFLeYInl3NzzhHzc-qnk4w4PX-0XMw8/edit#heading=h.icj5clwxt3mw 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.
- daxelrod 5y ago
  > As I understand it, this is what they're really aiming to prevent: dynamically-loaded code that runs in the extension's privileged context. Thank you, this is extremely helpful for me understanding the security model here, and explains what I was missing.
- dotproto 5y ago
  For clarity, injecting a script that is not included with the extension is expressly disallowed by the Chrome Web Store Developer Program Policies. > Some common violations include: > > * Including a <script> tag that points to a resource that is not within the extension's package https://developer.chrome.com/docs/webstore/program_policies/#:~:text=additional%20requirements%20for%20manifest%20v3 https://developer.chrome.com/docs/webstore/program_policies/...

ROARosen 5y ago

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&desc=2#c23 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

tyingq 5y ago
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.
- ROARosen 5y ago
  I understand he was referring to a different API than the one discussed. My question is if the API change he was referring to is still being implemented in Manifest v3 (I've edited my comment accordingly).
  - deleted 5y ago
    [deleted]
  - tyingq 5y ago
    I don't think Google has said when extensions with Manifest V2 will no longer work. And, technically, you can still use the blocking webrequest in a Manifest V3 extension, if the extension is "force installed". I think they are waiting for the hoopla to die down a bit before they close the door hard.
  - ece 5y ago
    It seems like Firefox will support Manifest v3 in a way that doesn't break compatibility with other browsers and support the blocking webRequest API as well: https://blog.mozilla.org/addons/2021/05/27/manifest-v3-update/ https://blog.mozilla.org/addons/2021/05/27/manifest-v3-updat...

stickfigure 5y ago

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?

teraflop 5y ago
Content scripts can be loaded into a page either statically, when the page URL matches a regex listed in the manifest, or dynamically, by calling chrome.tabs.executeScript (in V2) or chrome.scripting.executeScript (in V3). Once the content script is loaded, AFAIK its execution behaves the same no matter how it was loaded.

tooker 5y ago

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.

edoceo 5y ago
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?
- Lammy 5y ago
  That seems doomed to eventual irrelevance since web standards are now constantly-moving goalposts also authored by companies like Google.
  - d3nj4l 5y ago
    This is my place to plug once again that Slack still doesn't support calls on Firefox, over four years since they were launched.
- smolyeet 5y ago
  Until Firefox us taken seriously by tech companies not google , it's inevitable. I've yet to encounter a website that doesn't work on chrome , but FF is a gamble between it not being supported or prevent ad tracking breaks it. Can't use teams in web despite it running a bit better than desktop , can't use most of my apple websites for work, least not without some extension so it's really just frustrating. Honestly if chrome introduced bottom url bar and extensions without limitations... I'd switch back. I didn't switch for privacy but because chrome mobile is is clunky as a web app and I use my phone a lot during the day.
  - breakingcups 5y ago

foob 5y ago

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 https://github.com/intoli/remote-browser

ROARosen 5y ago
> 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.)
- xyzzy_plugh 5y ago

Crazyontap 5y ago

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.

xwolfi 5y ago
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)
rektide 5y ago
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.
- mikelward 5y ago
  Seems like an opportunity for another browser, e.g. Edge, Opera, Vivaldi, etc.
  - pandeiro 5y ago
    Moved off it to Vivaldi, haven't looked back.
perryizgr8 5y ago
> 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.

heavyset_go 5y ago

Yet another decision that uses safety and security concerns as a cover for corporate concerns.

pandeiro 5y ago
You think they would actually do that?

deleted 5y ago

[deleted]

jasonhansel 5y ago

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.

holistio 5y ago
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.
- dannyw 5y ago
  The right way to look at it is that Google wants to maintain control over the web, and remove the ability for user-agents to do anything that threatens their bottom line (i.e. ability to block ads). Manifest v3's proposed content blocking is hilariously crippled, that Google can simply start generating random class IDs and there's no way for uBlock origin to block ads anymore.
shadowgovt 5y ago
You don't have to publish an extension to side-load it.
contriban 5y ago
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

perryizgr8 5y ago

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.

shadowgovt 5y ago
You want to install a third-party keylogger? Sure, we'll let you ship your own password to a dark web clearinghouse...
- perryizgr8 5y ago
  Yeah, if the user wants that, why not?
  - shadowgovt 5y ago
    Because the set of users who actually want that is dwarfed by the set of users who got tricked into installing that keylogger.
    - Arnavion 5y ago
      Those users can continue using their coddling browsers on their coddling operating systems.
      - throwaway3699 5y ago
        Most people are not technology professionals and enthusiasts like this forum is. Should normal people be forced to put their life savings on the line because they didn't understand the difference between Manifest V2/V3?

lawl 5y ago

So they're killing userscript managers. This and the other manifest v3 shit with adblocking, google needs to die soon.

dotproto 5y ago
Manifest V3 does not currently support user script managers, but we are planning to address that gap in the coming months.

SimeVidas 5y ago

For a second I thought this is a domain.

somehnacct3757 5y ago

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.

tooker 5y ago
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.
orangepanda 5y ago
> 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.
- somehnacct3757 5y ago
  Or in this case, does less. I think if Manifest V3 had 1:1 capabilities with MV2, less people would care. Google has oodles of devs and infinite money; so their culture doesn't balk at rewrites. In the real world, treading water to stay on the Chrome Web Store with MV3 will muscle out huge swaths of a company's product roadmap. Our execs didn't even know what manifest versions are a year ago. Now Google is on everyone's shit list. If your API change is so jarring that non-technical people have to think about it, you're doing it wrong! This is less of an API change and more of a platform redefinition.
- heavyset_go 5y ago

pandeiro 5y ago

More Big Tech protecting us from ourselves. Awesome.

tak5651 5y ago

Microsoft Edge would work too?

visarga 5y ago

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.

dotproto 5y ago
Sure. If you're the only one using it, you can just run the extension locally as an unpacked extension. Check out the step-by-step getting started guide: https://developer.chrome.com/docs/extensions/mv3/getstarted/ https://developer.chrome.com/docs/extensions/mv3/getstarted/ For your case, you'll probably want to save the bookmarklet as a JS file, let's say content.js, and inject in when you click the extension's icon. Here's the basics to get you started. manifest.json { "name": "Demo", "version": "1.0", "manifest_version": 3, "permissions": [ "scripting", "activeTab" ], "background": { "service_worker": "background.js" }, "action": {} } background.js chrome.action.onClicked.addListener((tab) => { chrome.scripting.executeScript({ target: {tabId: tab.id}, files: ['content.js'], }); }); content.js alert('It worked!');

soapdog 5y ago

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

invisible 5y ago

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.

peanutz454 5y ago

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.

dotproto 5y ago
Yes-ish? So the extension itself is basically a bundle of web resources like HTML, CSS, and JS files. Today, the only way an extension can ask Chrome to automatically inject a content script on a page is to declare what scripts should be injected on which sites in the extension's manifest. For example… "content_scripts": [ { "matches": ["*://*.nytimes.com/*"], "js": ["content-script.js"], "run_at": ["document_start"] } ], This snippet from a manifest file will inject a file in the extensin's bundle called "content-script.js" onto all New York Times web pages the user visits right as the page start loading. The downside to this approach is that this is a static declaration; after the extension is installed it can't say "hey Chrome, I also you want you to inject that same script on BBC websites. In the quote you highlighted, what I was trying to say was that we are also planning to give extensions the ability to modify the set of content scripts while the extension is running. This means the extension will be able to ask Chrome to automatically inject the same script on BBC websites.