It was very bad, Chris. It was very, very, bad.
Conversation
I bet if someone dropped the author an email they'd be happy to correct their piece. If only we knew an executive who had strong opinions about things...
1
1
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.
1
22
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
I vaguely understand privacy/security concerns but I didn't see Chrome team provide any concrete examples so privacy/security motivations are still unverified. Chrome's perf argument seemed disingenuous; the API cannot be bad for perf when uBlock Origin uses it to *improve* perf.
2
8
Malicious extensions are a major issue. If you host a website, use a Content-Security-Policy with report-uri and you'll see the huge amount of reports from your users due to their extensions injecting ads and tracking code into your site. Some of them remove CSP headers though.
I think it's quite clear why an API granting extensions access to all the content (read and write) can be a serious privacy and security issue. A declarative API doesn't give them that kind of access, and it's also a lot more robust and actually usable for important things.
2
2
I do think they need to massively increase the number of rules permitted per extension by at least an order of magnitude, and it should become more powerful than the current bare minimum parity with EasyList / Adblock Plus before the webRequest blocking API is actually removed.