4 ms·

> I mean, you cannot declare the rules via the RequestMatcher and know what headers are going to be sent or received in advance, as the API expects full declara

by lima 6y ago

> I mean, you cannot declare the rules via the RequestMatcher and know what headers are going to be sent or received in advance, as the API expects full declaration of all protocol schemes and host suffixes; which is very bad if a website can pretty much do whatever it wants when it executes js code. Yes, but this is a good thing. This kind of intrusive logic with full access to view and modify request data does not belong in a Chrome extension that can be updated by a single account at a moment's notice through the store, with zero peer review (unlike changes to Chrome itself). This is much safer to implement in the browser core. If the declarativeNetRequest API is insufficiently expressive, then it needs to be improved to handle those use cases instead of sticking with the old way.

cookiengineer 6y ago
> If the declarativeNetRequest API is insufficiently expressive, then it needs to be improved to handle those use cases instead of sticking with the old way. You're welcome to prove me wrong by implementing an Ad-Blocker that can override Content-Security-Policy by default; and incrementally allow to execute things. As Google continues the Manifest V3 rollout, their priorities seem to be not on that specific degradation of this featureset; and that was all I'm saying. I've been working on my own Extension for the last week [1], and I had to switch back to Manifest V2 because there was no way to create an Adblocker that's based on a concept that allows the user to select what should be executed; as the Content-Security-Policy header couldn't be set and malicious HTTP headers couldn't be filtered for all domains by default. You claim that the new API is a full replacement of the featureset, so rather than saying that I'd welcome a hint to some examples or other evidence I'm probably missing here. [1] https://github.com/tholian-network/stealthify https://github.com/tholian-network/stealthify

by lima 6y ago

cookiengineer 6y ago

> If the declarativeNetRequest API is insufficiently expressive, then it needs to be improved to handle those use cases instead of sticking with the old way. You're welcome to prove me wrong by implementing an Ad-Blocker that can override Content-Security-Policy by default; and incrementally allow to execute things. As Google continues the Manifest V3 rollout, their priorities seem to be not on that specific degradation of this featureset; and that was all I'm saying. I've been working on my own Extension for the last week [1], and I had to switch back to Manifest V2 because there was no way to create an Adblocker that's based on a concept that allows the user to select what should be executed; as the Content-Security-Policy header couldn't be set and malicious HTTP headers couldn't be filtered for all domains by default. You claim that the new API is a full replacement of the featureset, so rather than saying that I'd welcome a hint to some examples or other evidence I'm probably missing here. [1] https://github.com/tholian-network/stealthify https://github.com/tholian-network/stealthify