3 ms·
> Chrome is a shitty browser. Google is a shitty company. Stop defending shit. > You are the one spreading FUD here by claiming that the new API is so much bet
by lima 6y ago
> Chrome is a shitty browser. Google is a shitty company. Stop defending shit.
> You are the one spreading FUD here by claiming that the new API is so much better than the old one.
This kind of language is not welcome here. Please have a look at the guidelines: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
I read the design documents and I'm convinced that the new API is a big improvement, and that the design decision was made in good faith and for technical, not political reasons.
The uBlock Origin developer is very trustworthy, but there's so many things that can go wrong - like a workstation, repository, signing key or account compromise.
It's a massive single point of failure. Anyone who can sneak malicious code into the extension has instant and unlimited access to millions of browsers and sensitive personal and company data.
A project like Chrome has extensive processes and safeguards to prevent this kind of compromise, including strict code review. As far as I can tell, uBlock has no code review process[1]. We need to move away from such points of failure no matter how well-intentioned they are.
[1]: https://github.com/gorhill/uBlock/commits/master https://github.com/gorhill/uBlock/commits/master
The webRequest API also forces a lot of IPC overhead and serialization in the runtime, no matter how fast the extension itself is. uBlock is very, very fast - but it's still a lot slower than native code in the core.
I'm not against adblocking or in favor of stripping away adblocker features, but why not implement it right in the core of the browser, where it belongs? Chrome is open source, if Google doesn't want to do it, another vendor or open source project most certainly could.