4 ms·

Dear EFF, I love you. I love you lots. Which is why this post rather bothers me for its dishonest arguments. This bit stood out: > That’s because a central pa

by Kalium 7y ago

Dear EFF, I love you. I love you lots. Which is why this post rather bothers me for its dishonest arguments. This bit stood out: > That’s because a central part of Manifest V3 is the removal of a set of powerful capabilities that uMatrix, NoScript, and other extensions rely on to protect users (for developers, we’re talking about request modification using chrome.webRequest). Whatever tools are available to a friendly extension are also available to an unfriendly one. With this in mind, it should be relatively easy to figure out that this sort of modification might, just might, be subject to some amount of possible abuse. Please, EFF. I do love so much of the work you do. Is it too much to ask for some intellectual honesty?

iam180 7y ago
The EFF is right in expressing the concern that the Alphabet agenda might be (and seems to be) reflected in the code. Google is choosing to keep away freedom from the users in the name of "security", without bothering to completely fix the issue. The consequence of this approach is that users were not protected and will not, scammy extensions will continue to thrive.
ghostwords 7y ago
Hi, coauthor here. Our argument is not that extensions can't abuse chrome.webRequest. What exactly is dishonest here?
- Kalium 7y ago
  Request modification using chrome.webRequest is pretty clearly something potentially abusable. Yet it's never mentioned in the rather long section about changes that may affect security concerns. It's only mentioned as something ad blockers find useful. This is, at the very least, a significant editorial oversight.
  - ghostwords 7y ago
    Just because something is abusable doesn't mean it should be removed. The argument we are making is that the trafeoff proposed by Manifest V3 is bad. There are clear actions Google could have taken a long time ago to protect Chrome users. Banning remote code is one of them. Responding to abuse reports is another. These would directly mitigate abuse in Chrome Web Store. Banning chrome.webRequest is not one of these clear actions.
    - Kalium 7y ago
      I do not disagree on any of your points in any way, shape, or form. If something is abusable but on balance worth keeping, then it should be publicly positioned as such and the balancing factors dicussed. Ignoring the abusability of something and focusing solely on the upsides is one of the classic moves from Ye Olde Bag Of Dirty PR Tricks.
      - danShumway 7y ago
        I don't necessarily disagree with you on principle, but in this specific case it's important to note that the security benefits of blocking extension modification via a dedicated API are very minor -- especially since extensions will still be able to inject JS into the page and read client information. Is it really important for me as an attacker to be able to modify your request when I can just edit the page directly, insert custom data, or steal your login credentials instead? With respect, I would suggest that the cost-benefit analysis here is more one-sided than you think it is -- one-sided enough that an exploration of the security benefits would need to come with a lot of caveats, and would be a net decrease in the readability of the article. It's not clear to me that deprecating a dedicated request modification API improves security in any meaningful, practical way for most users, and I think there's some benefit to occasionally skipping details that are irrelevant to the main story, so that ordinary people will find it easier to wade through. I would compare this to the way that Google bundles wifi access and location access on Android. People complain about it, but it's a sensible decision -- there's no point in restricting just one of them. Similarly, I don't see any point to restricting request modification without also restricting access to request content/headers/cookies and removing the ability to inject arbitrary JS into the page. I think Google is engaging in security theater here.
    - UncleMeat 7y ago
      Sure. But if the claim is that removing this will degrade security and privacy posture, then it is surely relevant to discuss the security and privacy benefits you'd get from removing this feature so you can argue that the benefits do not outweigh the costs.
- tyingq 7y ago
  What does manifest V3 add to privacy or security? The dishonesty I'm referring to is Google's, here: https://security.googleblog.com/2019/06/improving-security-and-privacy-for.html https://security.googleblog.com/2019/06/improving-security-a...
  - taqcp 7y ago
    >What does manifest V3 add to privacy or security? By definition, restricting the APIs extensions can use limits their power. Less powerful extensions can do fewer things, good or bad. Fewer bad things adds to privacy and security. At least that's what I understand. Yes, I know ad blocking makes your browsing more private and secure, but that's another discussion.
    - tyingq 7y ago
      As far as I know, the popular ad blockers aren't reducing their permissions. They are retaining the ability, for example, to inject JS for things like "right click to block". Manifest V3 is solely about reducing harm to Google's ad business. Full stop. Their stated reasons are very disingenuous. They knew full well how this would play out.
tyingq 7y ago
Google could bundle a real ad blocker that used internal only apis. That's the real dishonesty. Disabling the public API, claiming "because privacy", and ignoring the most popular use case for those apis. Fwiw, Google isn't disabling any ability to use the apis to record, store, and forward, everything you do on the web. The only thing being disabled is canceling a request, based on live heuristics, before it happens. What privacy hole does that close?
- SpicyLemonZest 7y ago
  They're not ignoring the use case. As the article notes, the new API will work fine with blockers like Adblock Plus.
  - tyingq 7y ago
    It reduces the effectiveness of adblockers, see commentary from them. Without helping privacy or security. The privacy and security issues of web extensions remain.
  - propogandist 7y ago
    vendors like Adblock Plus are paid by Google (and others) to allow their ads to not be blocked. It is the same company that bought the uBlock clone, including the domain name, so they can mislead people and give them the illusion of adblocking.
    - flingo 7y ago
      That wasn't a clone. That was the original project. Hill wanted to stop working on it, handed it off, and then it got bought by evil Germans. Then, he released and maintained an unfucked/original version: µblock origin
nine_k 7y ago
This is a copy of most reasoning against strong crypto. If good guys have unbreakable encryption, bad guys inevitably should also have access to it, and imagine the nefarious things they will do with it! Let's limit everyone to 40-bit RSA. We've had this in 1990s. There is no way to make technology ethical; technologies are oblivious of human concerns. Ethics should be applied at a different level.

by Kalium 7y ago

iam180 7y ago

The EFF is right in expressing the concern that the Alphabet agenda might be (and seems to be) reflected in the code. Google is choosing to keep away freedom from the users in the name of "security", without bothering to completely fix the issue. The consequence of this approach is that users were not protected and will not, scammy extensions will continue to thrive.

ghostwords 7y ago

Hi, coauthor here. Our argument is not that extensions can't abuse chrome.webRequest. What exactly is dishonest here?

Kalium 7y ago
Request modification using chrome.webRequest is pretty clearly something potentially abusable. Yet it's never mentioned in the rather long section about changes that may affect security concerns. It's only mentioned as something ad blockers find useful. This is, at the very least, a significant editorial oversight.
- ghostwords 7y ago
  Just because something is abusable doesn't mean it should be removed. The argument we are making is that the trafeoff proposed by Manifest V3 is bad. There are clear actions Google could have taken a long time ago to protect Chrome users. Banning remote code is one of them. Responding to abuse reports is another. These would directly mitigate abuse in Chrome Web Store. Banning chrome.webRequest is not one of these clear actions.
  - Kalium 7y ago
    I do not disagree on any of your points in any way, shape, or form. If something is abusable but on balance worth keeping, then it should be publicly positioned as such and the balancing factors dicussed. Ignoring the abusability of something and focusing solely on the upsides is one of the classic moves from Ye Olde Bag Of Dirty PR Tricks.
    - danShumway 7y ago
      I don't necessarily disagree with you on principle, but in this specific case it's important to note that the security benefits of blocking extension modification via a dedicated API are very minor -- especially since extensions will still be able to inject JS into the page and read client information. Is it really important for me as an attacker to be able to modify your request when I can just edit the page directly, insert custom data, or steal your login credentials instead? With respect, I would suggest that the cost-benefit analysis here is more one-sided than you think it is -- one-sided enough that an exploration of the security benefits would need to come with a lot of caveats, and would be a net decrease in the readability of the article. It's not clear to me that deprecating a dedicated request modification API improves security in any meaningful, practical way for most users, and I think there's some benefit to occasionally skipping details that are irrelevant to the main story, so that ordinary people will find it easier to wade through. I would compare this to the way that Google bundles wifi access and location access on Android. People complain about it, but it's a sensible decision -- there's no point in restricting just one of them. Similarly, I don't see any point to restricting request modification without also restricting access to request content/headers/cookies and removing the ability to inject arbitrary JS into the page. I think Google is engaging in security theater here.
  - UncleMeat 7y ago
    Sure. But if the claim is that removing this will degrade security and privacy posture, then it is surely relevant to discuss the security and privacy benefits you'd get from removing this feature so you can argue that the benefits do not outweigh the costs.
tyingq 7y ago
What does manifest V3 add to privacy or security? The dishonesty I'm referring to is Google's, here: https://security.googleblog.com/2019/06/improving-security-and-privacy-for.html https://security.googleblog.com/2019/06/improving-security-a...
- taqcp 7y ago
  >What does manifest V3 add to privacy or security? By definition, restricting the APIs extensions can use limits their power. Less powerful extensions can do fewer things, good or bad. Fewer bad things adds to privacy and security. At least that's what I understand. Yes, I know ad blocking makes your browsing more private and secure, but that's another discussion.
  - tyingq 7y ago
    As far as I know, the popular ad blockers aren't reducing their permissions. They are retaining the ability, for example, to inject JS for things like "right click to block". Manifest V3 is solely about reducing harm to Google's ad business. Full stop. Their stated reasons are very disingenuous. They knew full well how this would play out.

tyingq 7y ago

Google could bundle a real ad blocker that used internal only apis. That's the real dishonesty. Disabling the public API, claiming "because privacy", and ignoring the most popular use case for those apis. Fwiw, Google isn't disabling any ability to use the apis to record, store, and forward, everything you do on the web. The only thing being disabled is canceling a request, based on live heuristics, before it happens. What privacy hole does that close?

SpicyLemonZest 7y ago
They're not ignoring the use case. As the article notes, the new API will work fine with blockers like Adblock Plus.
- tyingq 7y ago
  It reduces the effectiveness of adblockers, see commentary from them. Without helping privacy or security. The privacy and security issues of web extensions remain.
- propogandist 7y ago
  vendors like Adblock Plus are paid by Google (and others) to allow their ads to not be blocked. It is the same company that bought the uBlock clone, including the domain name, so they can mislead people and give them the illusion of adblocking.
  - flingo 7y ago
    That wasn't a clone. That was the original project. Hill wanted to stop working on it, handed it off, and then it got bought by evil Germans. Then, he released and maintained an unfucked/original version: µblock origin

nine_k 7y ago

This is a copy of most reasoning against strong crypto. If good guys have unbreakable encryption, bad guys inevitably should also have access to it, and imagine the nefarious things they will do with it! Let's limit everyone to 40-bit RSA. We've had this in 1990s. There is no way to make technology ethical; technologies are oblivious of human concerns. Ethics should be applied at a different level.