4 ms·

> The Observational capabilities of the WebRequest API aren't being deprecated They are being severely curtailed. https://twitter.com/justinschuh/status/11388

> 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
      You say that they give "no explanation of why it would be a problem," in reference to Justin Schuh's tweet: > 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. The reasoning here should be obvious. Observing web requests can be useful with the cooperation/permission of the host you're observing, but it makes no sense to have an ad blocker that requires permission from the ad-blocked websites. If you grant the core premise is that we don't want extensions to be allowed to observe all web traffic, because this permission will be abused, then the only logical conclusion is to use a rules engine. That's the only way to design an ad blocker that doesn't/can't observe all web traffic.

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
    You say that they give "no explanation of why it would be a problem," in reference to Justin Schuh's tweet: > 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. The reasoning here should be obvious. Observing web requests can be useful with the cooperation/permission of the host you're observing, but it makes no sense to have an ad blocker that requires permission from the ad-blocked websites. If you grant the core premise is that we don't want extensions to be allowed to observe all web traffic, because this permission will be abused, then the only logical conclusion is to use a rules engine. That's the only way to design an ad blocker that doesn't/can't observe all web traffic.