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.)
> 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?
In a purely ethical sense, absolutely yes. But we're coming up on 30 years of people using the internet, and it's been clear for a while now that you simply cannot teach people what is safe and what is not in an absolute sense. Even highly technical, experienced users still make mistakes and install malware sometimes. Informing users is not effective, to a first approximation. System designers have a responsibility to protect the users of their systems.
> 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.)
These overrides should exist, but making them too easy will just lead to malware tricking people into triggering them. And some doors are so frequently abused or fundamentally vulnerable that they probably should be closed entirely — most people don't think we should still be embedding Java and Flash in webpages these days.
The problem with closing the API is that for even the most advanced users, it will now be impossible to get the (very useful) functionality these extensions provide.
I believe it was tptacek who once commented half-jokingly that the ideal thing to do would be to leave the API open to uBlock Origin exclusively and kill it for everything else. The privileges required by that extension and others like it are indeed very powerful and often abused. This is not a problem with an easy solution, your suggestions are essentially the status quo and the industry is beginning to move on from it.
The issue with that approach is that the next addon developer who comes up with something as useful as uBlock will not be able to develop that. Legacy carveouts protect past innovations but not future ones.
It’s open-source, and the author has a long history of supporting his product for free as an ethical good, even while some of his collaborators have went commercial and cashed out, once even taking the project name.
> 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?
If you've been following the Epic v. Apple case, you'd know some folks like Tim Cook strongly believe the answer is no, or in his words "they shouldn't have to [decide]."
As both a developer and a user, a lot of the software "freedoms" we have are superfluous, duplicative, and inefficient. As technology becomes more and more commoditized and 50,000 vendors all sell roughly the same thing, decision fatigue sets in. The walled gardens provide value not because they remove freedom but because they give you back something most people value more: time.
We don't all have time to sit around evaluating 1,000 similar packages, compiling and debugging them from scratch, just to get a simple app or game working.
The bleeding edge will keep on bleeding, but for the rest of us, good enough is good enough. It doesn't have to be perfect, it just has to work well enough and not add to our already-overwhelmed mental loads.
Well I’m a user and I don’t want to have to make that choice. For example I’m not a big fan of Facebook, but I do use it occasionally to keep in contact with some friends.
Suppose Facebook decided to move to a different third party store on iOS, maybe their own store, so they don’t have to list their data access and sharing policies, don’t have to go through app store review, etc.
Doing that forces me to choose between rigorous app review and disclosure, and using the Facebook app. I don’t want to be put in that position. One of the reasons I use an iPhone is because of that.
Regardless of whether you have the responsibility to make that choice or not, you are still responsible for dealing with the consequences of whatever choice has been made for you.
How is that any better that being responsible for making the choice in the first place?
That's not really a solution. The average user will not read security warnings, and will just click through them. Especially if they're being actively social engineered, the attacker can easily talk them through anything they don't understand.
The people who need this functionality are a very small minority. Tampermonkey has 10M installs which is phenomenal, but Chrome apparently has an estimated 2.5B active users. The tradeoff here is exposing billions of users to unnecessary risk, to save two orders of magnitude fewer of the most tech savvy users from an insignificant annoyance. I.e. just use a browser that supports the extensions you need instead.
This persistent infantilisation of users is going to lead to a crippled world. Basic computer security and hygiene is not rocket science. We should start teaching this from school level so even "ordinary" people can make informed choices rather than being confined to gilded cages whose perimeter will eventually expand to encompass even the tech folk, as the gatekeeping power of these companies grows ever larger, with malware attacks acting as the convenient foil.
Why SHOULDN'T phones and computers be "infantilized" the same way cars, microwaves, iPods, toasters, electricity outlets, etc. are? They're just another appliance, and 99% of people use their devices for information consumption & entertainment rather than content creation. Regular users shouldn't have to give up ease of use to satisfy developer needs. Android is so fragmented today precisely because Google decided to cater to OEMs instead of users first, and like it or not, the walled gardens ARE a lot safer than Windows/Android, regardless of whether you follow security best practices.
Most users don't need that level of power or customization and it just opens up not only attack vectors but general UX confusion. Hide that sort of thing behind an admin mode or whatever, but otherwise, yes, PLEASE hide dangerous functionality so people aren't exposed to them.
Users aren't asking to be treated like children, they just don't want to have to think about zero-days and layers of config menus because some developer in an ivory tower valued "muh freedoms" too much.
> The average user will not read security warnings
The basic point of my comment is that deprecating the capabilities or the current API just because there can be a security risk in some cases for the average user is harmful to the more advanced users.
You focus on one possible solution mentioned about warning dialogs. However, there are lots of different solutions available which would allow it to run only with knowing 100% that the user knows what they're doing aside from warnings.
There can be a command line flag --developer etc. just like there is for unsafe certs.
'Use a browser that supports it' is not a solution since - as you said - Chrome has the largest user base why would a developer put in the effort to develop a solution for a minorly used browser.
Since the major browser is closing this API there will be no possible use of this type of functionality for anyone - even the users who know what they're doing.
Product liability to the masses likely weighs much heavier as a concern to the developers of Chrome than does any harm done to “advanced users”. Beginner users often do what advanced users tell them too, anyhow.
>>I.e. just use a browser that supports the extensions you need instead.
Wonder how long that'll be an option. I use FF for all my browsing and its amazing how much stuff breaks if you're not using chrome. I'm thinking the re-captcha stuff should be used as evidence in a google anti-trust case :-P "Oh, your on firefox? here...lets identify all these pictures.."
The level of low effort negativity on HN these days is just exhausting. Chrome has a stellar track record on security all the way back to the launch, both on an engineering and product level. Why would it be surprising that they're continuing with that?
Malicious extensions are probably the biggest existential threat to the web as a platform. If browser regain the reputation for being insecure that they deservedly had 15 years ago, more and more serious business will move into mobile app walled gardens. This has to be solved.
But rather than accept the simple explanation, we get these inane conspiracy theories on what the true motivation is. No, it's not about ad blockers because the subject of this blog post is not a feature that ad blockers would use. And the same for the half dozen alternative explanations.
Seriously, what is wrong with you people? Can't you at least save the high school level cynicism for situations where an assumption of malice makes some sense?
Got any stats on what percentage of the browser install base has even one extension installed? Then we can come back to your "tHe biGgEsT eXisTenTiAL ThReAt" nonsense.
And how an assumption of malice doesn't make sense when we're talking about the world's biggest ad company doing something in the name of security that happens to cripple ad blockers -- well, suffice to say, you're probably not cut out for journalism.
It’s an oversimplification to chalk it up to some ulterior motive. Design decisions like this are hardly ever unilateral, and there are many competing interests.
> wouldn't the user be allowed to override these risks
It would seem like a useful compromise to have harmful features/functionality disabled by default for each new script - controlled at the individual script level.
If the user wants to invoke/allow the feature, they should be able to explicitly and manually enable it. Like the android app permissions: Allow access to x? [none, this time or always?]
And when there are hundreds of features... Scratch that. Even if there are ten features, the user will simply click "allow all" without paying attention to what's requested.
>shouldn't it be within the user's purview to decide what to allow and what not?
Imagine it this way: The local supermarket is selling a product which claims to be food but actually contains a highly toxic poison. And then someone justifies it still being allowed because it's still up to the buyer to choose to buy and consume it. It's on the user, the should be responsible to look for trusted brands that do not disguise poison as food or they could take it down to their local lab to test it for toxicity before consuming it.
It's obviously completely absurd to expect the user to protect themselves from malice like this which is rampant on browser extension stores.
> Imagine it this way: The local supermarket is selling a product which claims to be food but actually contains a highly toxic poison
Basically anything on sale if had in the wrong dose. Example: a can of a sugary drink is OK, drink 6 of them per day and it's going to be bad for your health.
Okay. How about buying something that was legitimately food when you bought it, but updates to poison - and there's really no choice about allowing updates, since previously safe foodstuffs can become poison if left as purchased - in your cupboard?
Why would it be sarcastic? Malware authors buy legitimate extensions for mountains of cash and then stick spyware in them. Users have no idea their previously good and trusted extension is now malware.
and here I think is the issue - it's hard for a closed source project to fully inform and alert anyone, at all. It's impossible to get a full understanding of a codebase that doesn't allow me to look at it, and I don't see why that would be different here. I can't understand security risks to Chrome (proper Chrome, not Chromium) because I'm not allowed to, therefore any extension at all could be dangerous in some way. So it is actually best to not allow the user to think about security for themself, because they can't have the necessary information. A developer can't look over every extension because they have better things to do with their time, so I think it makes sense that we end up with this incredibly restricted platform.
If your strategy for security can't be having an open and audited interface and implementation, the next best thing seems to be no interface.
If you feel like the only thing preventing you from understanding the security risks of executing a piece of Javascript in Chrome is the parts of the source that are used only in Chrome and not in Chromium, you have a very high opinion of your ability to reason about that many lines of non-memory-safe code that I think is not backed up by the evidence.
No, I think I have a low opinion about my abilities - I need a complete picture and all the help I can get to understand anything at all.
But yes, I agree that it's not as simple as my original comment made it out to be - I definitely failed to fully acknowledge that most/some of the critical parts are open source and secured, but I think the incompleteness in any outside understanding (such as my own) is a major factor in the options Google could present about security.
> since when is that a reason to disable a user-originated threat vector?
Since Google is operating at a scale where the majority of users use their browser, so a successful popular malicious extension scales extremely rapidly. This is basically a recapitulation of the decisions Microsoft had to make regarding the market dominance of Windows and the ease of attacking users via VBScript exploits. The developers of the framework have to make a trade-off between capabilities of the framework and likelihood that those capabilities will be used to attack the average user. It's a cat-and-mouse game where there are not obvious technical answers so much has move-countermove.
We even have the analog to Apple Computer during the heydays of VBScript exploits in this story... With its much smaller market share, Mozilla has the luxury of worrying less about these exploit vectors because successfully deploying a malicious extension in that ecosystem only impacts a couple percent of total users of the internet. Much as Apple didn't have to worry much about malicious AppleScript exploits.
As someone pointed out above, Tampermonkey has ~10m downloads compared to 2.5b Chrome users, I seriously doubt any one malicious Tampermonkey script can affect as many users as even a malicious AppleScript can.
This design change to manifest V3 isn't about tampermonkey. It's about the capability space of manifest V2 allowing a malicious actor to make something like tampermonkey, have it grow in popularity, and then flip the script under the hood via the extension fetching an arbitrary script from a third-party source and executing it to turn every installed node into a botnet agent without changing any of the code in the extension itself.
Google is trying to solve a similar problem here to the one they have to solve with App Store apps: the ability to make claims about safety an end-user can trust. They can't make those claims if the extension can modify its behavior without any way for the Web Store administrators to know.
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 hope you're right about Firefox. I think their hand is forced in terms of supporting any API additions that Google makes because of Chrome's dominance among extension developers, but they can choose to maintain support for the manifest v2 features that are getting removed.
I would love to hear more about your personal project ideas that involve remote-browser. My contact info is in my profile, feel free to reach out.
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.
The ability to execute arbitrary JavaScript in content scripts at runtime. Remote-browser works by making it very easy to run code in content and background script contexts from a remote client. Typical browser automation tasks like filling out an input, clicking a button, or extracting the HTML of an element are accomplished by marshaling code and results between the browser and the client.
your point is that the API was stable with V2
My point isn't that the API was stable, it's that Google is moving towards removing key features from the API because they consider them to be too powerful. Blocking webRequest and executeScript are two notable examples.
Read the post more closely. It’s not just an API reshuffle. Chrome is restricting the ability for extensions to run JavaScript code that is dynamically generated or loaded, limiting them (in many cases) to static scripts embedded in the extension itself.
They are only disallowing code execution within content script sandbox. You can still create a <script> tag with custom code. The script will be run in page sandbox. The main difference is that it won't be able to access chrome.* APIs but it could be affected by CSP.
I doubt that tampermonkey executes custom scripts within content script sandbox since a script could take over the extension itself. They should be fine.
Please note that as an extension developer I receive at least once a month a cash offer to inject scripts that track users.
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.
Here is the remote code policy on your own website:
> Your extension should avoid using remote code except where absolutely necessary. Extensions that use remote code will need extra scrutiny, resulting in longer review times. Extensions that call remote code and do not declare and justify it using the field shown above will be rejected.
[End quote]
This has nothing to do with code obfuscation. Remote code in general is heavily discouraged. Your extension can be outright rejected if your 'justification declaration' is insufficient (Google's discretion). And if that isn't enough to deter you, the review time will also suffer (Google's discretion.)
Does this policy not work? Surely it has led to a reduction in remote code exploits. And also given the enforcement team a straightforward path to take down an app in violation.
To your second point, you _don't_ have a way to address a major exploit vector. You've thrown the baby out with the bathwater. You've banned cars and introduced chariots as the solution to hit and run accidents. Now nobody can be run over! We've fixed Google Roads!
I would also like to know what API did exploiters share with ad-blockers? At the time, we were told the ad-blocker APIs had to be removed for performance reasons. Has the argument changed to a purely security one? Was it both?
The MV3 genie has sadly been let out of the bottle. We can't go back. But we can reduce its capability diff with MV2. It will involve sacrificing some of Google's secret objectives, which is why it's important to know them.
Listening to performance arguments one day, then security arguments the next, in carefully worded statements that don't quite add up; is what gives the impression there are secret objectives.
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.
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.
This led me to install Brave after being irritated at the umpteenth mid-article malvertising redirect. Definitely recommend Brave. They even pay you about 75 cents an ad for fairly unobtrusive, plaintext, notification area ads.
This comes up so often on HN that I feel like no-one is going to be converted in either direction at this point but I suppose just for the sake of completeness:
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 Nightly allows you to set whichever set of extensions you desire as the "blessed" extension collection, so you can also create a custom collection and choose that.
But the Firefox rewrite isn’t handling all extensions well.
Container Tabs break hilariously, spawning tenthousands of tabs.
Tampermonkey and similar extensions that spawn popup windows or custom tabs fail, too.
Sidebar extensions like vertical tabs break as well.
Google Play changed their policies to disallow downloading and executing code from sources other than the Play Store. The blessed extensions in Firefox for Android are actually shipped in the APK.
False. When they rolled this out i was trvially able to replace the allowed extensions id's with a root shell and they downloaded and worked just fine. Also, a website is also downloading and execing js, the same as an extension.
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?
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.
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).
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.
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?
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.
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.
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.
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.
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
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.
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
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.
> 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.
ah you have posted in the thread, telling us how the policy forbids creativity & interpreters (as apple does) but promising in some months you have some idea how maybe perhaps everything might not be as shit awful terrible awful as it sounds right now, how perhaps the general user might be given some break, not totally fucked over like it sounds like right now. in some months.
you also call our concern misinformation, but your words in that thread seem to come as a surprise to everyone, to the tampermonkey folks, to myself, & there seem to be no public indicators that there is more to this story than the clampdown this headline & post indicate.
I hope the future is indeed not so frakked as you say it might be. I am very very worried, and have seen few positive signs, hitherto your post, which is an unknown small hope against this grimness.
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.
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?
Get enough attention from the EU, to get them to determine that on balance, Manifest v3 is designed to cripple ad blockers and abuse Google's monopoly on web browsers to benefit their monopoly on search advertising.
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.
Users moved to Chrome and Firefox in part because of extensions. If users start getting notifications that their favorite extensions are no longer available on Chrome and they'll need to move to something else.. they're likely to follow.
No. I started here https://davidwalsh.name/how-to-build-firefox - it mostly "just worked". I'm on Gentoo so I already had all the build-deps (oh, I had to enable some PulseAudio crap tho)
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.
> 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?
> 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.
> 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.
The company I am working at develops a kind of overlay with helps that can be displayed on a given website.
When we are lucky, our clients can add a script tag to their applications (and tweak their CSPs if they have), when we are not we have to rely on a web extension (think a kind of Tampermonkey but more specialized and with our branding and without a new tab every other day to tell it has been updated).
What do we use ?
- Blocking webRequest to change CSP to authorize our overlay script to execute
- executeScript: in most case, the script we execute is just inserting a script tag so it would still work in Manifest v3, but with webapps using Service Worker we have to resolve to download the scripts and execute then directly via executeScript, which will not be possible in v3.
Guess we'll have to bundle the overlay engine in the extension, which is much less flexible than what we had until now, but at least it's a possibility.
Original blog post author here. Some quick personal thoughts (i.e. I'm not speaking on behalf of Chrome here).
> - Blocking webRequest to change CSP to authorize our overlay script to execute
I can't exactly say I'm keen on extensions relaxing CSP rules for a site. The approach I'm interested in exploring here is allowing extension resources to bypass CSP restrictions on a given site. IMO a typical extension shouldn't be able to weaken a site's security, but it should be able to load its own images and scripts on the site.
> - executeScript: in most case, the script we execute is just inserting a script tag so it would still work in Manifest v3, but with webapps using Service Worker we have to resolve to download the scripts and execute then directly via executeScript, which will not be possible in v3.
This is not a viable approach in Manifest V3 as reviewers would consider this remote code injection and therefore a violation of the "Additional Requirements for Manifest V3" section of the policy.
Bundling the overlay engine with the extension sounds like it may do the trick. Just make sure that the engine cannot be used for malicious purposes (e.g. harvesting user data, arbitrary script injection, etc.).
Does the script element injected as a DOM node from an extension or a content script end up having a different CSP than a script element that loaded with the page or was injected by a script on the page?
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.
There used to be a saying, "You can't fix stupid". You can't protect a sufficiently motivated user from destructive action, you can only give them hints that what they are doing is probably unwise.
"Hey, it looks like this extension is doing inappropriate things with your passwords. Would you like to uninstall it?"
Users can reasonably expect an online password manager to exfiltrate their passwords, and if that's what they want they can install one.
The problem with the v2 manifest `chrome.tabs.executeScript` API is that it allows any extension that uses that API to become an undocumented password exfiltrator without any changes to the Chrome extension itself. The new API in manifest v3, in contrast, requires that if, say, my clock extension suddenly became a keylogger, the script that did that would show up in the extension.
The API change is to make it possible for Google to have any hope of vetting extensions in the Chrome Web Store by controlling how their behavior can mutate after Google has signed off on them for inclusion in the store.
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?
... That browser is Chrome. Chrome's massive install base means it is the browser of choice for people who need a coddling browser.
Much as with Windows becoming the dominant operating system resulting in Microsoft having to deal with botnets fabricated from thousands of compromised machines via forced security updates, the dominant system becomes heavily incentivized to protect the least capable users from their own bad decisions.
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...
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://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().
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.
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.
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.
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…
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.
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.
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