4 ms·
> the same Justin Schuh who went on this ridiculous tirade on twitter can you link to the ridiculous tirade? Cause here's the text I see in full > The sole mo
by magicalist 7y ago
> the same Justin Schuh who went on this ridiculous tirade on twitter
can you link to the ridiculous tirade? Cause here's the text I see in full
> The sole motivation here is correcting major privacy and security deficiencies in the current system. I know, because I set that focus, and the team reports up through me. And here's a bit more context on the uBlock assertions. [link to other tweet]
> Honestly, all of the negative coverage here is because the team is doing all of this development in the open and engaging with the community. They're taking feedback and making significant changes in response. So the framing here is just not accurate.
- ngold 7y agoDo the merits of his claims hold true? Then I don't care if it's written by a guppy fish with I'll intention. Truth is the standard. Not the writer.
- dannyw 7y agoNo. Ublock does not have a performance problem.
- giovannibajo1 7y agoDepends on your point of view. Chrome is going to use the same architecture that Safari has had for a few years (on iOS and Mac): data-driven content blocking, where rules are declared by the extensions, and then read and implemented by the browser core with no JavaScript involved on each request. Javascript-based content blocking is technically slower because you need to invoke V8 on all requests, and then it’s up to the extension to make sure that the JavaScript code is fast enough. It surely is more flexible (as you can do whatever you want in that javascript code) but it’s hard to beat a simpler, data-driven content blocking engine written in native code and integrated in the core. Whether this difference in resources does have a concrete impact or not, remains to be seen. The fact that Apple Safari did it first makes me believe that there is some truth in the technical merit argument; surely Apple didn’t want to make sure their content blockers were ineffective, but was actually using the same approach as always: providing a possibly “weaker” but far more efficient implementation (compared to “de facto standards” on other platforms) to protect iOS resources usage.
- shawnz 7y agoHere are some measurements from the Ghostery team which show that the impact of the non-declarative API can be extremely minimal, and maybe even negative if you consider the increased performance from the reduced ad load. https://whotracks.me/blog/adblockers_performance_study.html https://whotracks.me/blog/adblockers_performance_study.html
- EdwardDiego 7y agoAt the risk of being that guy who mistakes his anecdote for a datum, I've found the bigger ad-blocking extensions to have a larger performance impact - simply because they're evaluating large regex based block lists on each request. That said - that's my choice, I don't have to use those extensions, but the gain is, to my mind, worth the pain. I really don't like the patronising "we know what's best for you" attitude of the Chrome developers - especially because what they came up with as being "best for us" is also best for Google.
- daveevad 7y ago> I know, because I set that focus That's a dead give away to me that this person is not effective as it's a naked appeal to his own authority.
- inimino 7y agoWhat? It's an appeal to authority to justify his assertion about the motivation of team that he manages. And you don't think his role is relevant? What are you smoking? > The sole motivation here is [...] I know, because I set that focus, and the team reports up through me