14 ms·

I know a lot of people think Manifest V3 is here only to break adblockers but it seems like it's trying to solve a real problem. Adblockers currently only work

I know a lot of people think Manifest V3 is here only to break adblockers but it seems like it's trying to solve a real problem. Adblockers currently only work by having full access to every tab, iframe, page, etc. What happens when an adblocker is sold and the new owner secretly installs spyware to steal all of your passwords and cookies? This has happened multiple times already with extensions in the past. It seems to me like Chrome is trying to limit use-cases that require full access to every single site you visit. How will Firefox solve this problem better than Chrome or Safari? It seems inevitable that the status quo for these extensions is going away.

sneak 6y ago
> Adblockers currently only work by having full access to every tab, iframe, page, etc. What happens when an adblocker is sold and the new owner secretly installs spyware to steal all of your passwords and cookies? Perhaps installing something (A) on Monday should not give the developer/publisher the right or ability to arbitrarily exec B on your machine on Tuesday. No-interaction updates are the problem here. They amount to a remote code exec vulnerability, exploited just as you describe.
- jefftk 6y ago
  An ad blocker that did not auto update would quickly go stale. Removing updating support for extensions would be even less popular! (Disclosure: I work for Google, speaking only for myself)
  - sneak 6y ago
    The logic in an ad blocker rarely needs to be updated, only the non-executable filter lists.
    - jefftk 6y ago
      If you have automatically updating data the extension can be an interpreter, which can be asked to do anything.
      - sneak 6y ago
        Well, sure, but it seems like extensions that download remote code are being explicitly banned by Google per TFA. I can't imagine that they intend that to extend to even non-executable tabular data.
- zamadatix 6y ago
  It's an unrealistic expectation that the user is going to do anything other than click "allow" the 273rd time you ask if the extension they installed 5 years ago should be allowed to update.
  - sneak 6y ago
    The only expectation that I expressed is that installing program A on Monday is not automatic consent to automatically downloading and running a different program B on Tuesday, which I think is a wholly realistic one. It seems you believe that I was indicating that the user should be presented with prompts to update, when I said no such thing.
    - yonixw 6y ago
      Please give your alternative to manual update, instead of leaving us hanging...
- userbinator 6y ago
  Precisely. Google essentially introduced this problem themselves with silent updates --- that and perhaps the rest of the software industry that wants to turn everything into a service... The normalisation of silent change is one of the worst things to have happened to software in the last decade.
Confiks 6y ago
It indeed is trying to solve a real problem, but also conveniently breaks effective ad blocking. Doing that is a choice; there are other measures they could've taken to improve privacy to the same level while keeping granular blocking intact. For example, they could have chosen a system where privacy-sensitive information like visited URLs are fed into a part of the extension which is a side-effect free function returning limited information. As they already have capability-based extension permissions, this would not be terribly hard to add if they would set their mind to it. More manual reviewing of valuable extensions would also be a path. They don't need to allow all extensions this permissions, and there doesn't need to be a level playing field for extensions here. It's just that Google doesn't see effective ad blocking as valuable, but rather the opposite.
- fastest963 6y ago
  I'm not sure how easy it would be to implement/ensure that a single function is side-effect-free in an extension given that the rest of the extension needs to be able to use the network and download filter lists. Safari went with an even more restrictive solution for content blockers and it seems like at least Chrome has been working with various developers to iron out the kinks with their solution before it goes live.
  - rndgermandude 6y ago
    It doesn't have to be side effect free, it just has to run in an execution environment that cannot exfiltrate data. Make it into a special kind of "content script", that gets a blank javascript environment that does not have any of of the usual means to communicate with the outside world (no XHR, no access to any DOM, no access to any message passing, and so on). E.g. a browser could have a special kind of "content blocker" script environment that gets fed request objects by the browser. The script can then examine all the data in the request object (the requested URL, the headers, etc) and make a decision to DENY or ALLOW and communicate this decision back to the browser in a single well-define way, and that's the only communication to the outside world it is allowed to do. No way for it to exfiltrate data. Extensions can be allowed to pass data into the environment via some form of uni-directional message passing, e.g. to update filter rules, but the content script cannot respond (and thus cannot exfiltrate data in a response). Browsers already define different execution environments with different APIs available in them for different purposes, e.g. you have the same-origin limited environments for websites that feature Web APIs such as DOM and XHR, and those environments come in different flavors (no access to certain APIs such as the location API if you're not "secure"), Proxy-Auto-Configuration (PAC) scripts have yet another environment, extension scripts get yet another environment, extension content scripts yet another, internal browser pages such as the settings pages of browsers often get environments with access to some privileged APIs etc. To define a few more specialized environments for privacy-sensitive stuff shouldn't be too hard.
magicalist 6y ago
> Manifest V3 is here only to break adblockers but it seems like it's trying to solve a real problem. Adblockers currently only work by having full access to every tab, iframe, page, etc. Indeed, which is exactly why Safari said they moved to this model years ago.
- rasz 6y ago
  Apple moved in this direction because Apple is all about restricting you from running any code Apple didnt sell to you in the first place. They are in a war against general computing.
  - coldtea 6y ago
    >Apple moved in this direction because Apple is all about restricting you from running any code Apple didnt sell to you in the first place. This is about Safari, which is not about preventing you from "running any code Apple didnt sell to you in the first place". It's about security/privacy. >They are in a war against general computing Well, general computing has many shortcomings that don't exist in computer as appliance. For some, the latter is better.
    - akalsz 6y ago
      > This is about Safari, which is not about preventing you from "running any code Apple didnt sell to you in the first place". It's about security/privacy. I might be misunderstanding you, but isn't this "security/privacy" argument basically "end users can't be trusted when it comes to installing extensions that respect their privacy, so let's get rid of potentially malicious extensions with arbitrary content blocking logic and enforce our single way of content blocking instead"? Which certainly sounds like preventing the end user from "running any code Apple didnt sell to you in the first place".
      - coldtea 6y ago
        >but isn't this "security/privacy" argument basically "end users can't be trusted when it comes to installing extensions that respect their privacy, so let's get rid of potentially malicious extensions with arbitrary content blocking logic and enforce our single way of content blocking instead"? Yep. Like "speed limiters" in cars. We could also trust car drivers "when it comes to observing the speed limit", but in many cases we don't, do we? And that's a mechanical limit imposed on top of fines for speeding and so on... "But here they only hurt themselves" is not necessarily true. If you have family private data and they're stolen because you've installed a malicious extension, doesn't it also hurt your family? If your own data are then used to phish your friends, doesn't it also hurts them? >Which certainly sounds like preventing the end user from "running any code Apple didnt sell to you in the first place". Not really since: (a) you can run many kinds of code (JS, etc) still in your web browser, can you not? Just not extensions with extra capabilities for sniffing, etc. So "only thinks Apple sold you" is not really accurate. (b) the core reason is not profit, as the "Apple didn't sell you" part implies.
burtonator 6y ago
Chrome extension developer here and I can absolutely confirm that this is true. The last few years they've gotten more and more strict about which permissions they hand out. The one I need is similar to ad blocking and every time I request ANYTHING new they're very strict about explaining why I need it. Our extension Allows you to convert pages from HTML to EPUB and for this I need the ability to fetch any arbitrary image and read the data and that's not actually possible from Javascript due to CORS. The turnaround time for each approval is also increased and it takes about 72 hours for us to get approval for every change right now. Our extension if you're interested: https://chrome.google.com/webstore/detail/save-to-polar/jkfdkjomocoaljglgddnmhcbolldcafd https://chrome.google.com/webstore/detail/save-to-polar/jkfd...
gnomewascool 6y ago
Yes, I totally agree that Manifest V3 solves some real problems — in the case of many webextensions, I would welcome the ability to manually control which domains the extension can run in. However, the move to Manifest V3 also involves curtailing the power of extensions, including those that I trust as much or more than the browser itself. I want uBlock origin to be able to intercept and filter requests according to the logic that gorhill deems most sensible rather than however Chromium wants it to be done, since I trust gorhill far more than Google (and possibly slightly more than even Mozilla). I don't think that any of the tiny extensions that I've written to scratch my own itch require any of the capabilities removed in Manifest V3, but if they did, I'd also want them to keep having them.
- fastest963 6y ago
  > However, the move to Manifest V3 also involves curtailing the power of extensions, including those that I trust as much or more than the browser itself. I want uBlock origin to be able to intercept and filter requests according to the logic that gorhill deems most sensible rather than however Chromium wants it to be done, since I trust gorhill far more than Google (and possibly slightly more than even Mozilla). So what happens if gorhill's account is hacked or he gets tired of working on the extension and sells it to the highest bidder? These are not theoretical problems, they've happened multiple times in the past. I'm not saying Manifest V3 is the perfect solution but these are very real problems that cause me to not install any extensions that can access all sites.
  - gnomewascool 6y ago
    > So what happens if gorhill's account is hacked or he gets tired of working on the extension and sells it to the highest bidder? Approximately the same as would happen if the developer of a traditional Windows* application were hacked or sold out, except less serious, since they wouldn't have access to the underlying filesystem. It's not a non-existent risk, but it is a trade-off I and many other people want to be able to make. uBlock Origin being FOSS and popular considerably mitigates the risks. (Not to mention that I trust gorhill not to sell out...) * or Linux (except that in Linux most software is distributed via repositories, which lessens the risks, somewhat; OTOH uBlock origin is also available via the repositories, for instance on Debian[0] and Ubuntu[1]). I'm not sure about sandboxing on MacOS. [0] https://packages.debian.org/stretch/webext-ublock-origin https://packages.debian.org/stretch/webext-ublock-origin [1] https://packages.ubuntu.com/search?keywords=webext-ublock-origin https://packages.ubuntu.com/search?keywords=webext-ublock-or...
rektide 6y ago
> What happens when an adblocker is sold and the new owner secretly installs spyware to steal all of your passwords and cookies? This has happened multiple times already with extensions in the past. This idea that we need to keep locking down markets because one day things go bad is really really not good. We should not deny ourselves software because there are bad usages of it. These fear-inducing scenarios are all bad because they are low information marketplaces. The consumer has no idea what extensions really do, they don't see when major changes happen to the software they use, they don't see ownership changes, they don't see what data is gathered, they don't see where data goes. And yes, we can't expect consumers to watch & attend all of these things. Which is why it's important consumers be able to rely on each other, to have some way to signal danger & emergencies to one another. Instead of trying to create a marketplace where information & understanding can flow, instead of allowing genuine competition based on markets, we continue building markets assuming every buyers is & forever will be a totally blind idiot with no help, no friends, no other voices to help them make their decisions. I'm so fired of Fear Uncertainty and Doubt. The security apparatchik of the web today terrifies me. Deny deny deny. Close down close down close down. Severe connections, pull up the draw bridges, flood the moats, send out the alligators. I tire of these defensive wars, I tire of giving up ground, because the web has some pretense of being a perfectly secure place. I would much rather us be intertwingled, allow bold exploration of systems, mingling together, & while doing that figure out ways forward that permit some risk. Extensions are the most vital & powerful capability on the web. They are what make it better than everything else. Keeping the user sovereign, giving them amazing mind blowingly powerful extensions, is how the web keeps from becoming just another app. Those great powers can be abused. But we need to find ways to permit these powers to exist anyways.
- Santosh83 6y ago
  The Web started mirroring the real world when money got involved. It could have been the way you said, had it only been a place to share information, but it is now primarily a marketplace, and no govt or pvt entity has EVER not regulated or attempted to seize control over marketplaces. In fact, even the pure information sharing part is being increasingly censored under the pretext of "security" and children and so on...
gorhill 6y ago
> Chrome is trying to limit use-cases that require full access to every single site you visit That argument is always made and every single time there needs to be a reminder that: The webRequest API -- used to observe all network requests -- will still be available, it just won't be able to be used to block or redirect network requests, but still can be used to observe all outgoing network requests and all incoming response headers. Additionally, content blockers require the injection of content scripts on all pages and all frames embedded in those pages in order to properly implement additional blocking mechanisms which can't be done through network filtering. So essentially content blockers such as the current crop of top content blockers will still need to see all the sites visited by users in order to meet what users expect from their blocker.
- fastest963 6y ago
  Previously the webRequest API was the only way to do content blocking but now that there's an alternate way to do it they can block extensions still using the old way or gate it behind a special scary warning. > Additionally, content blockers require the injection of content scripts on all pages and all frames embedded in those pages in order to properly implement additional blocking mechanisms which can't be done through network filtering. My OP was talking about a very real problem where extensions are being sold and nefariously used to sniff credentials because they have full control over the tab execution environment. How do you propose to solve that problem while still allowing adblocking?
  - rasz 6y ago
    There is no alternative way. You need to manipulate headers to modify CSP. No control over CSP means no way to block js from running altogether (Content-Security-Policy: script-src http: https:), to block web fonts (Content-Security-Policy: font-src *), to block twitch ads (overriding origin and referrer).
  - gorhill 6y ago
    Where did you get the idea that "blocking webRequest API" and "extensions being sold" are part of the same problem requiring to be solved by the removal of the blocking ability of the webRequest API? There are good examples out there of extensions exfiltrating browsing information and which didn't required a blocking webRequest to gather such information, and they were not content blockers. I am not the only person having an issue with the deprecation of the blocking ability in MV3, see this EFF article: https://www.eff.org/de/deeplinks/2019/07/googles-plans-chrome-extensions-wont-really-help-security https://www.eff.org/de/deeplinks/2019/07/googles-plans-chrom...
AaronFriel 6y ago
If I were a product manager at Google working on solving that real problem, I'd ask, "What are the APIs and permissions an ad-blocker needs to be able to function performantly?" And that would typically then involve going to stakeholders, i.e.: people who actually write adblockers, and asking them what they need. That is very, very obviously not what happened. And any attempt to spin this as "solving a real problem" ignores that Google employs tens of thousands of professionals who are trained to follow the approach above in response to solving problems. This is a business decision and the stakeholders aren't ad-blockers, they're ad networks.
- deleted 6y ago
  [deleted]
danShumway 6y ago
> it seems like it's trying to solve a real problem People aren't mad that the Chromium team is trying to solve a real problem, they're mad that the Chromium team is utterly failing to solve that problem, and introducing new problems in the process. Under Manifest V3, requests can still be monitored, they just can't be modified. So this isn't really helping with spying. And even if the change did help with spying, adblockers help with spying. Firefox will solve this problem better than Chrome or Safari by hopefully balancing the relative privacy risks from extensions and from ads and not by making clumsy fixes that introduce additional problems. We all recognize that extension security is an issue. The question is how to make things more secure without introducing additional privacy risks by weakening adblockers. If adblockers legitimately need full access to the page in order to work effectively, we can't just stick our fingers in our ears and pretend that they don't need that access. We can't just pretend that declarative blocking is good enough just because it would be more convenient for us if it was good enough. I would welcome a security model that made adblockers safer without making them less effective. Does anyone have one to propose? Because I don't want a half-baked solution implemented in my browser just because "we have to do something" -- and that's what I think Manifest V3 is.
- neolog 6y ago
  Confiks comment above proposes > For example, they could have chosen a system where privacy-sensitive information like visited URLs are fed into a part of the extension which is a side-effect free function returning limited information. As they already have capability-based extension permissions, this would not be terribly hard to add if they would set their mind to it.
  - danShumway 6y ago
    On one hand, no, I don't think this would work, because part of what advanced adblockers like Ublock Origin allow is script insertion into pages and source rewrites when you request HTML pages. There's not a good, simple way I'm aware of to prevent data exfiltration in that kind of environment. Once I have the ability to change a page's source code before the browser loads it, I suspect I can kind of do anything. On the other hand, that proposal would make it at least marginally harder for malicious scripts to go undetected, and it's at least as much (if not more) of an improvement to privacy than the system Manifest V3 is going with, given that V3 doesn't prevent request monitoring, network requests from extensions, or script injection into the page. And there are probably ways to implement what you're talking about without breaking a huge number of extensions. So I don't think that's a solution, but it's significantly better than what Manifest V3 is trying to do.
wvenable 6y ago
> What happens when an adblocker is sold and the new owner secretly installs spyware to steal all of your passwords and cookies? Is there not a whole chrome extension review process?
inshadows 6y ago
Are you and ad?
the8472 6y ago
> What happens when an adblocker is sold and the new owner secretly installs spyware to steal all of your passwords and cookies? That's not a reasonable argument because it could be used to justify the removal of any and all extension APIs. The solution to that particular problem is to prevent ownership transfer without review, not to cripple powerful addons.

sneak 6y ago

> Adblockers currently only work by having full access to every tab, iframe, page, etc. What happens when an adblocker is sold and the new owner secretly installs spyware to steal all of your passwords and cookies? Perhaps installing something (A) on Monday should not give the developer/publisher the right or ability to arbitrarily exec B on your machine on Tuesday. No-interaction updates are the problem here. They amount to a remote code exec vulnerability, exploited just as you describe.

jefftk 6y ago
An ad blocker that did not auto update would quickly go stale. Removing updating support for extensions would be even less popular! (Disclosure: I work for Google, speaking only for myself)
- sneak 6y ago
  The logic in an ad blocker rarely needs to be updated, only the non-executable filter lists.
  - jefftk 6y ago
    If you have automatically updating data the extension can be an interpreter, which can be asked to do anything.
    - sneak 6y ago
      Well, sure, but it seems like extensions that download remote code are being explicitly banned by Google per TFA. I can't imagine that they intend that to extend to even non-executable tabular data.
zamadatix 6y ago
It's an unrealistic expectation that the user is going to do anything other than click "allow" the 273rd time you ask if the extension they installed 5 years ago should be allowed to update.
- sneak 6y ago
  The only expectation that I expressed is that installing program A on Monday is not automatic consent to automatically downloading and running a different program B on Tuesday, which I think is a wholly realistic one. It seems you believe that I was indicating that the user should be presented with prompts to update, when I said no such thing.
  - yonixw 6y ago
    Please give your alternative to manual update, instead of leaving us hanging...
userbinator 6y ago
Precisely. Google essentially introduced this problem themselves with silent updates --- that and perhaps the rest of the software industry that wants to turn everything into a service... The normalisation of silent change is one of the worst things to have happened to software in the last decade.

Confiks 6y ago

It indeed is trying to solve a real problem, but also conveniently breaks effective ad blocking. Doing that is a choice; there are other measures they could've taken to improve privacy to the same level while keeping granular blocking intact. For example, they could have chosen a system where privacy-sensitive information like visited URLs are fed into a part of the extension which is a side-effect free function returning limited information. As they already have capability-based extension permissions, this would not be terribly hard to add if they would set their mind to it. More manual reviewing of valuable extensions would also be a path. They don't need to allow all extensions this permissions, and there doesn't need to be a level playing field for extensions here. It's just that Google doesn't see effective ad blocking as valuable, but rather the opposite.

fastest963 6y ago
I'm not sure how easy it would be to implement/ensure that a single function is side-effect-free in an extension given that the rest of the extension needs to be able to use the network and download filter lists. Safari went with an even more restrictive solution for content blockers and it seems like at least Chrome has been working with various developers to iron out the kinks with their solution before it goes live.
- rndgermandude 6y ago
  It doesn't have to be side effect free, it just has to run in an execution environment that cannot exfiltrate data. Make it into a special kind of "content script", that gets a blank javascript environment that does not have any of of the usual means to communicate with the outside world (no XHR, no access to any DOM, no access to any message passing, and so on). E.g. a browser could have a special kind of "content blocker" script environment that gets fed request objects by the browser. The script can then examine all the data in the request object (the requested URL, the headers, etc) and make a decision to DENY or ALLOW and communicate this decision back to the browser in a single well-define way, and that's the only communication to the outside world it is allowed to do. No way for it to exfiltrate data. Extensions can be allowed to pass data into the environment via some form of uni-directional message passing, e.g. to update filter rules, but the content script cannot respond (and thus cannot exfiltrate data in a response). Browsers already define different execution environments with different APIs available in them for different purposes, e.g. you have the same-origin limited environments for websites that feature Web APIs such as DOM and XHR, and those environments come in different flavors (no access to certain APIs such as the location API if you're not "secure"), Proxy-Auto-Configuration (PAC) scripts have yet another environment, extension scripts get yet another environment, extension content scripts yet another, internal browser pages such as the settings pages of browsers often get environments with access to some privileged APIs etc. To define a few more specialized environments for privacy-sensitive stuff shouldn't be too hard.

magicalist 6y ago

> Manifest V3 is here only to break adblockers but it seems like it's trying to solve a real problem. Adblockers currently only work by having full access to every tab, iframe, page, etc. Indeed, which is exactly why Safari said they moved to this model years ago.

rasz 6y ago
Apple moved in this direction because Apple is all about restricting you from running any code Apple didnt sell to you in the first place. They are in a war against general computing.
- coldtea 6y ago
  >Apple moved in this direction because Apple is all about restricting you from running any code Apple didnt sell to you in the first place. This is about Safari, which is not about preventing you from "running any code Apple didnt sell to you in the first place". It's about security/privacy. >They are in a war against general computing Well, general computing has many shortcomings that don't exist in computer as appliance. For some, the latter is better.
  - akalsz 6y ago
    > This is about Safari, which is not about preventing you from "running any code Apple didnt sell to you in the first place". It's about security/privacy. I might be misunderstanding you, but isn't this "security/privacy" argument basically "end users can't be trusted when it comes to installing extensions that respect their privacy, so let's get rid of potentially malicious extensions with arbitrary content blocking logic and enforce our single way of content blocking instead"? Which certainly sounds like preventing the end user from "running any code Apple didnt sell to you in the first place".
    - coldtea 6y ago
      >but isn't this "security/privacy" argument basically "end users can't be trusted when it comes to installing extensions that respect their privacy, so let's get rid of potentially malicious extensions with arbitrary content blocking logic and enforce our single way of content blocking instead"? Yep. Like "speed limiters" in cars. We could also trust car drivers "when it comes to observing the speed limit", but in many cases we don't, do we? And that's a mechanical limit imposed on top of fines for speeding and so on... "But here they only hurt themselves" is not necessarily true. If you have family private data and they're stolen because you've installed a malicious extension, doesn't it also hurt your family? If your own data are then used to phish your friends, doesn't it also hurts them? >Which certainly sounds like preventing the end user from "running any code Apple didnt sell to you in the first place". Not really since: (a) you can run many kinds of code (JS, etc) still in your web browser, can you not? Just not extensions with extra capabilities for sniffing, etc. So "only thinks Apple sold you" is not really accurate. (b) the core reason is not profit, as the "Apple didn't sell you" part implies.

burtonator 6y ago

Chrome extension developer here and I can absolutely confirm that this is true. The last few years they've gotten more and more strict about which permissions they hand out. The one I need is similar to ad blocking and every time I request ANYTHING new they're very strict about explaining why I need it. Our extension Allows you to convert pages from HTML to EPUB and for this I need the ability to fetch any arbitrary image and read the data and that's not actually possible from Javascript due to CORS. The turnaround time for each approval is also increased and it takes about 72 hours for us to get approval for every change right now. Our extension if you're interested: https://chrome.google.com/webstore/detail/save-to-polar/jkfdkjomocoaljglgddnmhcbolldcafd https://chrome.google.com/webstore/detail/save-to-polar/jkfd...

gnomewascool 6y ago

Yes, I totally agree that Manifest V3 solves some real problems — in the case of many webextensions, I would welcome the ability to manually control which domains the extension can run in. However, the move to Manifest V3 also involves curtailing the power of extensions, including those that I trust as much or more than the browser itself. I want uBlock origin to be able to intercept and filter requests according to the logic that gorhill deems most sensible rather than however Chromium wants it to be done, since I trust gorhill far more than Google (and possibly slightly more than even Mozilla). I don't think that any of the tiny extensions that I've written to scratch my own itch require any of the capabilities removed in Manifest V3, but if they did, I'd also want them to keep having them.

fastest963 6y ago
> However, the move to Manifest V3 also involves curtailing the power of extensions, including those that I trust as much or more than the browser itself. I want uBlock origin to be able to intercept and filter requests according to the logic that gorhill deems most sensible rather than however Chromium wants it to be done, since I trust gorhill far more than Google (and possibly slightly more than even Mozilla). So what happens if gorhill's account is hacked or he gets tired of working on the extension and sells it to the highest bidder? These are not theoretical problems, they've happened multiple times in the past. I'm not saying Manifest V3 is the perfect solution but these are very real problems that cause me to not install any extensions that can access all sites.
- gnomewascool 6y ago
  > So what happens if gorhill's account is hacked or he gets tired of working on the extension and sells it to the highest bidder? Approximately the same as would happen if the developer of a traditional Windows* application were hacked or sold out, except less serious, since they wouldn't have access to the underlying filesystem. It's not a non-existent risk, but it is a trade-off I and many other people want to be able to make. uBlock Origin being FOSS and popular considerably mitigates the risks. (Not to mention that I trust gorhill not to sell out...) * or Linux (except that in Linux most software is distributed via repositories, which lessens the risks, somewhat; OTOH uBlock origin is also available via the repositories, for instance on Debian[0] and Ubuntu[1]). I'm not sure about sandboxing on MacOS. [0] https://packages.debian.org/stretch/webext-ublock-origin https://packages.debian.org/stretch/webext-ublock-origin [1] https://packages.ubuntu.com/search?keywords=webext-ublock-origin https://packages.ubuntu.com/search?keywords=webext-ublock-or...

rektide 6y ago

> What happens when an adblocker is sold and the new owner secretly installs spyware to steal all of your passwords and cookies? This has happened multiple times already with extensions in the past. This idea that we need to keep locking down markets because one day things go bad is really really not good. We should not deny ourselves software because there are bad usages of it. These fear-inducing scenarios are all bad because they are low information marketplaces. The consumer has no idea what extensions really do, they don't see when major changes happen to the software they use, they don't see ownership changes, they don't see what data is gathered, they don't see where data goes. And yes, we can't expect consumers to watch & attend all of these things. Which is why it's important consumers be able to rely on each other, to have some way to signal danger & emergencies to one another. Instead of trying to create a marketplace where information & understanding can flow, instead of allowing genuine competition based on markets, we continue building markets assuming every buyers is & forever will be a totally blind idiot with no help, no friends, no other voices to help them make their decisions. I'm so fired of Fear Uncertainty and Doubt. The security apparatchik of the web today terrifies me. Deny deny deny. Close down close down close down. Severe connections, pull up the draw bridges, flood the moats, send out the alligators. I tire of these defensive wars, I tire of giving up ground, because the web has some pretense of being a perfectly secure place. I would much rather us be intertwingled, allow bold exploration of systems, mingling together, & while doing that figure out ways forward that permit some risk. Extensions are the most vital & powerful capability on the web. They are what make it better than everything else. Keeping the user sovereign, giving them amazing mind blowingly powerful extensions, is how the web keeps from becoming just another app. Those great powers can be abused. But we need to find ways to permit these powers to exist anyways.

Santosh83 6y ago
The Web started mirroring the real world when money got involved. It could have been the way you said, had it only been a place to share information, but it is now primarily a marketplace, and no govt or pvt entity has EVER not regulated or attempted to seize control over marketplaces. In fact, even the pure information sharing part is being increasingly censored under the pretext of "security" and children and so on...

gorhill 6y ago

> Chrome is trying to limit use-cases that require full access to every single site you visit That argument is always made and every single time there needs to be a reminder that: The webRequest API -- used to observe all network requests -- will still be available, it just won't be able to be used to block or redirect network requests, but still can be used to observe all outgoing network requests and all incoming response headers. Additionally, content blockers require the injection of content scripts on all pages and all frames embedded in those pages in order to properly implement additional blocking mechanisms which can't be done through network filtering. So essentially content blockers such as the current crop of top content blockers will still need to see all the sites visited by users in order to meet what users expect from their blocker.

fastest963 6y ago
Previously the webRequest API was the only way to do content blocking but now that there's an alternate way to do it they can block extensions still using the old way or gate it behind a special scary warning. > Additionally, content blockers require the injection of content scripts on all pages and all frames embedded in those pages in order to properly implement additional blocking mechanisms which can't be done through network filtering. My OP was talking about a very real problem where extensions are being sold and nefariously used to sniff credentials because they have full control over the tab execution environment. How do you propose to solve that problem while still allowing adblocking?
- rasz 6y ago
  There is no alternative way. You need to manipulate headers to modify CSP. No control over CSP means no way to block js from running altogether (Content-Security-Policy: script-src http: https:), to block web fonts (Content-Security-Policy: font-src *), to block twitch ads (overriding origin and referrer).
- gorhill 6y ago
  Where did you get the idea that "blocking webRequest API" and "extensions being sold" are part of the same problem requiring to be solved by the removal of the blocking ability of the webRequest API? There are good examples out there of extensions exfiltrating browsing information and which didn't required a blocking webRequest to gather such information, and they were not content blockers. I am not the only person having an issue with the deprecation of the blocking ability in MV3, see this EFF article: https://www.eff.org/de/deeplinks/2019/07/googles-plans-chrome-extensions-wont-really-help-security https://www.eff.org/de/deeplinks/2019/07/googles-plans-chrom...

AaronFriel 6y ago

If I were a product manager at Google working on solving that real problem, I'd ask, "What are the APIs and permissions an ad-blocker needs to be able to function performantly?" And that would typically then involve going to stakeholders, i.e.: people who actually write adblockers, and asking them what they need. That is very, very obviously not what happened. And any attempt to spin this as "solving a real problem" ignores that Google employs tens of thousands of professionals who are trained to follow the approach above in response to solving problems. This is a business decision and the stakeholders aren't ad-blockers, they're ad networks.

deleted 6y ago
[deleted]

danShumway 6y ago

> it seems like it's trying to solve a real problem People aren't mad that the Chromium team is trying to solve a real problem, they're mad that the Chromium team is utterly failing to solve that problem, and introducing new problems in the process. Under Manifest V3, requests can still be monitored, they just can't be modified. So this isn't really helping with spying. And even if the change did help with spying, adblockers help with spying. Firefox will solve this problem better than Chrome or Safari by hopefully balancing the relative privacy risks from extensions and from ads and not by making clumsy fixes that introduce additional problems. We all recognize that extension security is an issue. The question is how to make things more secure without introducing additional privacy risks by weakening adblockers. If adblockers legitimately need full access to the page in order to work effectively, we can't just stick our fingers in our ears and pretend that they don't need that access. We can't just pretend that declarative blocking is good enough just because it would be more convenient for us if it was good enough. I would welcome a security model that made adblockers safer without making them less effective. Does anyone have one to propose? Because I don't want a half-baked solution implemented in my browser just because "we have to do something" -- and that's what I think Manifest V3 is.

neolog 6y ago
Confiks comment above proposes > For example, they could have chosen a system where privacy-sensitive information like visited URLs are fed into a part of the extension which is a side-effect free function returning limited information. As they already have capability-based extension permissions, this would not be terribly hard to add if they would set their mind to it.
- danShumway 6y ago
  On one hand, no, I don't think this would work, because part of what advanced adblockers like Ublock Origin allow is script insertion into pages and source rewrites when you request HTML pages. There's not a good, simple way I'm aware of to prevent data exfiltration in that kind of environment. Once I have the ability to change a page's source code before the browser loads it, I suspect I can kind of do anything. On the other hand, that proposal would make it at least marginally harder for malicious scripts to go undetected, and it's at least as much (if not more) of an improvement to privacy than the system Manifest V3 is going with, given that V3 doesn't prevent request monitoring, network requests from extensions, or script injection into the page. And there are probably ways to implement what you're talking about without breaking a huge number of extensions. So I don't think that's a solution, but it's significantly better than what Manifest V3 is trying to do.

wvenable 6y ago

> What happens when an adblocker is sold and the new owner secretly installs spyware to steal all of your passwords and cookies? Is there not a whole chrome extension review process?

inshadows 6y ago

Are you and ad?

the8472 6y ago

> What happens when an adblocker is sold and the new owner secretly installs spyware to steal all of your passwords and cookies? That's not a reasonable argument because it could be used to justify the removal of any and all extension APIs. The solution to that particular problem is to prevent ownership transfer without review, not to cripple powerful addons.