3 ms·

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

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
> it makes no sense to have an ad blocker that requires permission from the ad-blocked websites. I don't follow what you mean by this. Under the current V3 specification, as currently proposed, Privacy Badger (assuming they stick it out and keep maintaining a Chrome version) will need to be granted observation permissions on every single website, adblocked or not. The way Privacy Badger works is by determining at runtime based on request observation which domains it should blacklist. This is not going to be a fringe usecase. Are you misunderstanding how the proposed permissions system works by some chance, or am I misunderstanding your argument? It's not the website you request permissions from -- it's the user you request permissions from for domains/domain patterns. Why doesn't it make sense for a user to grant an ad blocker permission to operate on domains where they want it to block ads?