Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google backtracks on Chrome modifications that would have crippled ad blockers

zdnet.com

Post reply on HN
Print view View original

101–110 of 169 posts

Re: Google backtracks on Chrome modifications that would have crippled ad blockers

#101

Post by nbaksalyar »

bufferoverflow wrote: post #67
pgt wrote: post #58

Every year Stallman sounds less crazy. I used to think it didn't matter what tools I chose as a lone developer making consumer tech products and DSP audio applications. But over time, I saw that consumers rely on frontier-makers more than you think, even though they may lag behind by a few years. I reluctantly switched to Firefox because it still has add-ons and since Chrome's web tools are so good. With Mozilla's Ru…

Rust is slower than C++. Firefox got faster because it got optimized, not because of Rust.

> Rust is slower than C++

It may be, but there's also the concurrency aspect which is hard to get right in C++. That's where the performance gains come from, partially, because 'fearless concurrency' is one of the Rust's tenets.

Re: Google backtracks on Chrome modifications that would have crippled ad blockers

#102

Post by kerng »

sokoloff wrote: post #73
pgt wrote: post #58

Every year Stallman sounds less crazy. I used to think it didn't matter what tools I chose as a lone developer making consumer tech products and DSP audio applications. But over time, I saw that consumers rely on frontier-makers more than you think, even though they may lag behind by a few years. I reluctantly switched to Firefox because it still has add-ons and since Chrome's web tools are so good. With Mozilla's Ru…

Footnote in pg's article makes me wonder what the stats are today. I'd guess Windows down, Mac way up, Linux/FreeBSD about flat [maybe slightly up], but I have no idea. [2] Y Combinator is (we hope) visited mostly by hackers. The proportions of OSes are: Windows 66.4%, Macintosh 18.8%, Linux 11.4%, and FreeBSD 1.5%. The Mac number is a big change from what it would have been five years ago.

Wow, that the majority is Windows is a bit unexpected to me. Really shows how powerful and omnipresent Windows actually still is - something that is often forgotten when living in certain tech bubbles.

Linux with 11% is quite high, I like that. What seems lower then expected are the Mac numbers to me.

Thanks for sharing.

Re: Google backtracks on Chrome modifications that would have crippled ad blockers

#103

Post by j16sdiz »

Vogtinator wrote: post #59
pgt wrote: post #58

Every year Stallman sounds less crazy. I used to think it didn't matter what tools I chose as a lone developer making consumer tech products and DSP audio applications. But over time, I saw that consumers rely on frontier-makers more than you think, even though they may lag behind by a few years. I reluctantly switched to Firefox because it still has add-ons and since Chrome's web tools are so good. With Mozilla's Ru…

> With Mozilla's Rust adoption, Firefox got fast. Those are unrelated.

Most of recent Firefox performance come from parelelization in servo.

Mozilla research said rush enabled them doing safe multuthreading.

Re: Google backtracks on Chrome modifications that would have crippled ad blockers

#104

Post by j16sdiz »

bufferoverflow wrote: post #67
pgt wrote: post #58

Every year Stallman sounds less crazy. I used to think it didn't matter what tools I chose as a lone developer making consumer tech products and DSP audio applications. But over time, I saw that consumers rely on frontier-makers more than you think, even though they may lag behind by a few years. I reluctantly switched to Firefox because it still has add-ons and since Chrome's web tools are so good. With Mozilla's Ru…

Rust is slower than C++. Firefox got faster because it got optimized, not because of Rust.

Most come from concurrency. Rust make them easier.

Re: Google backtracks on Chrome modifications that would have crippled ad blockers

#105

Post by kerng »

rajeshmr wrote: post #43
saagarjha wrote: post #34

Earlier quoted context omitted.

> I never understand the intent behind introducing this move I think the reasons provided are valid (namely, faster blocking with less data flowing through extensions), whether or not you think they are good enough to outweigh their disadvantages.

I think you should read this part of the article too : "Their study --which analyzed the network performance of ad blockers such as uBlock Origin, Adblock Plus, Brave, DuckDuckGo and Cliqz'z Ghostery-- found sub-millisecond median decision times per request, showing quite the opposite of what the Chrome team claimed." What are they really optimizing for ? The sub-millisecond times per request is barely noticeable, an…

Yeah, the user experience with current ad blockers is that browsing is way faster then without an adblocker. So anything Google states here is dodgy at best.

Re: Google backtracks on Chrome modifications that would have crippled ad blockers

#106

Post by j16sdiz »

rajeshmr wrote: post #43
saagarjha wrote: post #34

Earlier quoted context omitted.

> I never understand the intent behind introducing this move I think the reasons provided are valid (namely, faster blocking with less data flowing through extensions), whether or not you think they are good enough to outweigh their disadvantages.

I think you should read this part of the article too : "Their study --which analyzed the network performance of ad blockers such as uBlock Origin, Adblock Plus, Brave, DuckDuckGo and Cliqz'z Ghostery-- found sub-millisecond median decision times per request, showing quite the opposite of what the Chrome team claimed." What are they really optimizing for ? The sub-millisecond times per request is barely noticeable, an…

Performance is the reason for blacklist size limit.

The reason for not allowing intercept the connection was security: the current API allow the extension do many kinds of mitm

Re: Google backtracks on Chrome modifications that would have crippled ad blockers

#107

Post by kerng »

XorNot wrote: post #71

Someone pointed out that every Chrome user got that way because a techie got them off Internet Explorer... and those same people can just as easily get them onto Firefox.

Chrome is the new IE. I work at a well known tech company where majority of internal sites don't work with anything but Chrome.

Its so frustrating.

Re: Google backtracks on Chrome modifications that would have crippled ad blockers

#108

Post by amluto »

tyingq wrote: post #95
amluto wrote: post #88

Earlier quoted context omitted.

A better example of how this could be done is iOS keyboards. They’re run in a sandbox (by default), and they have no internet access. An ad blocker could be sandboxed like this. Sure, such a sandbox can be bypassed by intentionally leaking bits through keyboard input or, in the case of an ad blocker, exactly which requests are blocked, but that would be very obvious nefarious behavior.

I like that idea, but it would be hard to pull off. The extension API, for example, allows for messaging between background scripts and content scripts. So you could make a proxy of sorts. And messaging is not the only hole you can poke. They would essentially have to redesign the whole extension API. To the point where no interesting extensions would be possible.

Surely there could be a content blocker script that simply can’t send messages anywhere. It gets access to web requests and to IndexedDB or something similar. It can receive messages from other extension scripts for updates, perhaps.

Re: Google backtracks on Chrome modifications that would have crippled ad blockers

#109

Post by Silhouette »

kgwxd wrote: post #98
pgt wrote: post #58

Every year Stallman sounds less crazy. I used to think it didn't matter what tools I chose as a lone developer making consumer tech products and DSP audio applications. But over time, I saw that consumers rely on frontier-makers more than you think, even though they may lag behind by a few years. I reluctantly switched to Firefox because it still has add-ons and since Chrome's web tools are so good. With Mozilla's Ru…

At this point in time, there's hundres of real world exmples of every single "crazy" warning given by Stallman.

The difficulty is that many of those examples are also doing useful things that the more open/free alternatives aren't.

We are developing an unfortunate dichotomy between commercially supported, closed ecosystems with lock-in and rapid update cycles that provide superior functionality and more community-driven, open ecosystems with standards and future-proofing but inferior functionality.

If the open versions aren't too far behind the closed ones in functionality and performance, that's just another form of competition and perhaps a healthy one. But if we start to get too much lock-in, which is inherently a one-way process favouring the closed systems in this situation, and in particular if important data or external systems become accessible only from the closed systems, then we have a more serious problem, as we're seeing ever more clearly with the worlds of mobile devices, IoT and "evergreen" software.

Re: Google backtracks on Chrome modifications that would have crippled ad blockers

#110

Post by jrochkind1 »

itissid wrote: post #69
pgt wrote: post #58

Every year Stallman sounds less crazy. I used to think it didn't matter what tools I chose as a lone developer making consumer tech products and DSP audio applications. But over time, I saw that consumers rely on frontier-makers more than you think, even though they may lag behind by a few years. I reluctantly switched to Firefox because it still has add-ons and since Chrome's web tools are so good. With Mozilla's Ru…

I think Rust adoption has more to do with developer productivity than speed: - People preferring the compiler to yell at them to fix their Type mistakes before they hit the "run tests" button. - Getting a better IR for better error messages. Amongst others...

Perhaps increased developer productivity provides more developer hours for performance tuning.
Post reply on HN