4 ms·

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.

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.