5 ms·

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

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.

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.