3 ms·

> There’s been a lot of confusion and misconception around both the motivations and implications of this change Oh, heck off. This is Google's fallback wheneve

> There’s been a lot of confusion and misconception around both the motivations and implications of this change Oh, heck off. This is Google's fallback whenever people call them out on anything -- "you just don't understand the entire picture." It's just their way of gaslighting critics. People understand the change perfectly. a) The privacy arguments are untrue because the Observational capabilities of the WebRequest API aren't being deprecated. There are no privacy benefits unless an extension voluntarily ignores that part of the API -- which no one will do because, as Google says: > when extension developers are given the choice between capability and security, the vast majority of developers choose capability. Google makes the argument that 42% of malicious extensions use this API. Well, guess what they'll still be able to do under Manifest V3? b) The vast majority of data suggests that ad blocker performance is not a serious issue on the web right now. Ad blockers pretty much universally help more than they hurt, so it's not clear why performance is such a big concern. c) The declarative model is a less powerful alternative, which is the exact reason why Google is deprecating the blocking capabilities in the first place -- if they didn't force it, no one would switch (again, see their "why not both?" argument). So what don't consumers and developers understand about this? It's an objectively less powerful API that does very little to improve privacy for the sake of performance improvements that aren't necessary.

dfabulich 7y ago
> The Observational capabilities of the WebRequest API aren't being deprecated They are being severely curtailed. https://twitter.com/justinschuh/status/1138889508512866304 https://twitter.com/justinschuh/status/1138889508512866304 > Yes, but network requests won't be observable without permission on the relevant hosts. And host permissions are changing significantly in Mv3 (e.g. they can't be granted as blanket install time permissions). > The underlying issue with blocking Web Request is that it is effectively a UXSS, which could not be bound by origin-based host permissions like the rest of the API can. Google's privacy argument is correct.
- danShumway 7y ago
  I strongly disagree. There is pretty much no chance that every ad blocker and every other extension isn't going to widely request that new permission, because without it you can't get the data you need to maintain adblock lists or do more advanced detection (ie Privacy Badger). On the current discussion thread, Chrome devs say: > The webRequest API's ability to observe requests is foundational for extensions that modify their behavior based on the patterns they observe at runtime. And in this article, they say: > when extension developers are given the choice between capability and security, the vast majority of developers choose capability. So the argument that hiding observation requests behind a permission means that they are "severely curtailed" is just plain wrong. Most extensions (including ad blockers) will still request these permissions as wildcards across all hosts, and most users will still grant them as wildcards across all hosts. Per-domain permissions for the blocking WebRequest API would be great (that's a change I would broadly support), and if Chrome devs honestly believed that per-domain permissions were an adequate user protection against malware, they'd look for ways to implement per-domain permissions with the blocking API, rather than deprecating the entire thing. The Twitter post you link claims that's impossible, I don't see why. That would be a good thing for someone from Chrome to explain in either the massive developer thread that's been going on for months, or maybe in the article that complains about how much "confusion" users and developers have, instead of asking devs to blindly take their word.
  - dfabulich 7y ago
    You can't just request "that new permission" for all web sites ("hosts"), but only for certain specific hosts, and only with the permission of each host. > The Twitter post you link claims that's impossible, I don't see why. Your original post claimed that people understand this issue "perfectly." It turns out there was more to it than you thought.
    - danShumway 7y ago
      Check the spec[0] -- Google isn't getting rid of the ability for users to grant full URL access for extensions, because of course they're not. That permission is absolutely necessary for a wide variety of extensions, including ad blockers. They're just implementing changes to how that permission is going to be granted. With respect, a lot of us have been following these changes for a long time. We know about the permission stuff already. And to be clear, the permission changes are good -- they're just not going to significantly change normal user behavior in most cases. > It turns out there was more to it than you thought. It turns out that a Google advocate on Twitter posted, "we can't do it the other way" with no explanation of why it would be a problem. Again, this exactly is how Google gaslights. They refuse to engage with the wider developer community, ignore proposals and objections, and then when the wider community finally gets mad enough to start complaining in mainstream channels, they start posting on Twitter and blogs that "actually, it's complicated." If developers don't have the full picture, give it to them. The Chrome team can't complain that developers aren't informed about the technical limitations they're facing when they're posting arcane updates to Twitter instead of the official threads that everyone is following. [0]: https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3NzzhHzc-qnk4w4PX-0XMw8/edit#heading=h.oenw1ekaaubz https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3Nzz...

dfabulich 7y ago

> The Observational capabilities of the WebRequest API aren't being deprecated They are being severely curtailed. https://twitter.com/justinschuh/status/1138889508512866304 https://twitter.com/justinschuh/status/1138889508512866304 > Yes, but network requests won't be observable without permission on the relevant hosts. And host permissions are changing significantly in Mv3 (e.g. they can't be granted as blanket install time permissions). > The underlying issue with blocking Web Request is that it is effectively a UXSS, which could not be bound by origin-based host permissions like the rest of the API can. Google's privacy argument is correct.

danShumway 7y ago
I strongly disagree. There is pretty much no chance that every ad blocker and every other extension isn't going to widely request that new permission, because without it you can't get the data you need to maintain adblock lists or do more advanced detection (ie Privacy Badger). On the current discussion thread, Chrome devs say: > The webRequest API's ability to observe requests is foundational for extensions that modify their behavior based on the patterns they observe at runtime. And in this article, they say: > when extension developers are given the choice between capability and security, the vast majority of developers choose capability. So the argument that hiding observation requests behind a permission means that they are "severely curtailed" is just plain wrong. Most extensions (including ad blockers) will still request these permissions as wildcards across all hosts, and most users will still grant them as wildcards across all hosts. Per-domain permissions for the blocking WebRequest API would be great (that's a change I would broadly support), and if Chrome devs honestly believed that per-domain permissions were an adequate user protection against malware, they'd look for ways to implement per-domain permissions with the blocking API, rather than deprecating the entire thing. The Twitter post you link claims that's impossible, I don't see why. That would be a good thing for someone from Chrome to explain in either the massive developer thread that's been going on for months, or maybe in the article that complains about how much "confusion" users and developers have, instead of asking devs to blindly take their word.
- dfabulich 7y ago
  You can't just request "that new permission" for all web sites ("hosts"), but only for certain specific hosts, and only with the permission of each host. > The Twitter post you link claims that's impossible, I don't see why. Your original post claimed that people understand this issue "perfectly." It turns out there was more to it than you thought.
  - danShumway 7y ago
    Check the spec[0] -- Google isn't getting rid of the ability for users to grant full URL access for extensions, because of course they're not. That permission is absolutely necessary for a wide variety of extensions, including ad blockers. They're just implementing changes to how that permission is going to be granted. With respect, a lot of us have been following these changes for a long time. We know about the permission stuff already. And to be clear, the permission changes are good -- they're just not going to significantly change normal user behavior in most cases. > It turns out there was more to it than you thought. It turns out that a Google advocate on Twitter posted, "we can't do it the other way" with no explanation of why it would be a problem. Again, this exactly is how Google gaslights. They refuse to engage with the wider developer community, ignore proposals and objections, and then when the wider community finally gets mad enough to start complaining in mainstream channels, they start posting on Twitter and blogs that "actually, it's complicated." If developers don't have the full picture, give it to them. The Chrome team can't complain that developers aren't informed about the technical limitations they're facing when they're posting arcane updates to Twitter instead of the official threads that everyone is following. [0]: https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3NzzhHzc-qnk4w4PX-0XMw8/edit#heading=h.oenw1ekaaubz https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3Nzz...