3 ms·
To interject with a potentially inconvenient fact, I think the premise that ad blocking (request blocking) is now obstructed, is incorrect. Therefore this respo
by deepstream 8y ago
To interject with a potentially inconvenient fact, I think the premise that ad blocking (request blocking) is now obstructed, is incorrect. Therefore this response seems exaggerated to me.
This is because Chrome extensions can use the 'debugger' API to send remote debugging protocol commands to a page, to intercept and filter / block all requests.
There is no need to use the provided Chrome extension APIs for blocking. Google can remove all of them, I think, without effect.
This is because there are multiple ways to do the same thing. Authors/engineers complaining that now they are impeded, are in fact mistaken.
Disclosure: I know this because I have actually re-implemented the blocking from AdBlock Fast using CRDP Network domain.
- tyingq 8y agoI'm interested in this. What's the CRDB equivalent of onBeforeRequest()?
- deepstream 8y agoI don't know, you should have a look yourself. I know that you can intercept requests, and block, provide other payloads etc. I'm interested in that even tho this is factually correct, it's ignored / downvoted because it goes against the prevailing narrative. Discourse here can be pretty 1 dimensional, it's more like a confirmation bias machine / echo chamber, than a discussion. Just like the rest of the net, no matter how 'smart' the people here are. The same behavior pattern occurs here as everywhere else. It would be interesting if this can be solved in discussion forums of the future.
- tyingq 8y agoAn alternative explanation is just that people assume if ad blockers move there, Google will deprecate that API for the same stated reasons. I did find it, it's called setRequestInterception(). It's marked as experimental, and has a note that it disables caching, but there's some debate as to whether it actually does.
- deleted 8y ago[deleted]