Yeah, no, seriously: drop the article author a note if you think we've screwed up. Snark is one thing, but facts matter the most.
Conversation
I'm also curious what's wrong with the article. The talk of fixing perf. using a Promise-based API is questionable, and the 1-sided speculation about Google's motives is...1-sided speculation. But, overall it seems consistent w/ my understanding of the mailing list thread.
1
4
(FWIW, uBlock Origin w/ Google Chrome is my primary browser and I am biased towards uBlock Origin working well. I think its author is being fair. I think Google has good security-related reasons for changing things but I think more can be done to accommodate uBlock Origin users.)
1
12
OK, I have to admit my mistake: "fair" is not a fair characterization of his non-technical comments.
1
7
Pretty much. The headline is objectively just not true, and the main thread of the article is wild leaps and unsupported opinions. There's no shortage of inaccuracies and technical errors, but I'd normally just let those go were it not for the editorial tone they're attached to.
2
6
12
And yeah, Chrome does let sysadmins manage things beyond user-facing settings (without paying anyone anything!). That's because enterprises have complex needs and admins responsible for assessing security, privacy, and perf tradeoffs that we can't foist on the average user.
1
6
Then there's the uBlock Origin arguments. The big problem with webRequest is unfixable privacy and security holes. They ignored that to solely argue perf, but then ignored the biggest perf cost of every webRequest extension stacking a full renderer process, blocking IPC, etc.
9
6
15
Those are the biggest issues I have with the article, and I don't see a point in digging deeper and fisking the whole thing. Hell, I'm only replying now because my daughter woke up, and after checking on her I couldn't get back to sleep.
1
6
Look, you're all doing a vital job producing a secure and efficient web browser. We all get that. But when things change, it sometimes causes friction.
If there are technical inaccuracies, please tell us and we will fix them.
2
9
One major issue with the article is that the enterprise features aren't something that requires paying, so that part of the premise of the article is flawed. Those are available in the standard Chrome releases and in Chromium. Are you going to fix that? It's not subjective.
1
Maybe you should also link back to articles you've published about malicious Chrome extensions. Extensions being able to have free reign to mess with requests and inject code into sites is certainly being widely abused. A declarative content filtering API like this avoids that.
The declarativeNetRequest API is a lot like the Safari Content Blockers.
developer.chrome.com/extensions/dec
developer.apple.com/documentation/
Sure, it's less powerful and restricted to a set of built-in capabilities. That's the point. They could offer more power than they do right now though.
1
They clearly targeted the EasyList / Adblock Plus functionality as a benchmark, and uBlock Origin goes beyond that so it the needs aren't entirely met by the new API. That's a completely legitimate criticism, and I'd like to see their response to that and plans to add more to it.
1
Show replies