,
7 tweets,
3 min read
Read on Twitter
This changes nothing of what I said regarding uBlock Origin.
security.googleblog.com/2019/06/improv…
security.googleblog.com/2019/06/improv…
The "whole website" can still be seen by a passive webRequest API -- so why is "some sensitive data" even used as an argument to justify declarativeNetRequest API? Additionally, content scripts can also access sensitive data. 
From uBO's perspective, a better wording is:
"Hey WebExtensions-capable browser, let me see all the network requests so that I can decide whether to cancel them according to my OWN matching algorithm, and report ALL what I see and do (and why I do it) to the user"
"Hey WebExtensions-capable browser, let me see all the network requests so that I can decide whether to cancel them according to my OWN matching algorithm, and report ALL what I see and do (and why I do it) to the user"
I already explained why uBO's (and uMatrix's) custom matching algorithm can't be implemented through declarativeNetRequest API: it's nothing more than Easylist-compatible matching algorithm. There is more to content blocking than Easylist et al.
uBO's custom matching algorithm enables advanced-user features in uBO, which greatly benefit a user's privacy/security:
github.com/gorhill/uBlock…
github.com/gorhill/uBlock…
"to cut substantial overhead in the browser": I already commented that performance of well-crafted content blocker is not an issue.
Where are the benchmarks to make the case? Real benchmarks + detailed methodology with a representative sample of high-traffic websites.
In any case, an idea: extend the webRequest API to allow extensions to batch-process network requests to reduce IPC overhead?
In any case, an idea: extend the webRequest API to allow extensions to batch-process network requests to reduce IPC overhead?
