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

61–70 of 169 posts

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

#61

Post by jackewiehose »

happybuy wrote: post #32

Sounds like Google will still move towards what they were planning but will likely just take a bit more time and more versions to get there (as the outrage subsides). From my perspective, the biggest improvement in their proposal would have been the increased privacy and security users would receive with adblockers that use the proposed scheme. Under the current scheme, any Chrome adblocker can see all of the pages t…

> Under the current scheme, any Chrome adblocker can see all of the pages that users browse; a potentially huge privacy hole.

I hate that argument if it's used to cripple the users ability to have full control of their own devices. It is NOT a privacy hole when you install software that has access to your data. If you don't want that, don't install that software. If you don't trust that software, don't install it.

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

#62

Post by ModFightsCron »

dang wrote: post #18
waffleguy wrote: post #13

Earlier quoted context omitted.

I’m guessing you’re the type of person who raised their hand and reminded the teacher about assigning or collecting homework

Can you please stop posting unsubstantive comments to Hacker News?

can mods stop flagging and shadow deleting stuff just to make themselves feel better about their shitty lives, while defending obvious spam? by the way, having fun fighting a script in a cronjob? the script is having fun.

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

#63

Post by saagarjha »

zuzun wrote: post #56
saagarjha wrote: post #46

Earlier quoted context omitted.

I read the article the quote was pulled from, as well as participated in the discussion and responded to the author when it was posted here. Just FYI, Safari (which already has this feature in the form of content blockers) is able to block ads just fine, and anecdotally the performance is slightly, but noticeably better.

JavaScript code will take a millisecond to decide whether to block a request or not and some hard-coded browser function will do it slightly faster, but not by much, because most of the work will be done by the same regular expression, so we are talking about fractions of a millisecond here and you claim to notice that?

Safari pre-compiles the blocking list into some internal representation that is faster than a raw regular expression, and the matching operation is performed many times per page. So I do think it's possible to notice a small performance benefit?

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

#64

Post by saagarjha »

feanaro wrote: post #53
saagarjha wrote: post #46

Earlier quoted context omitted.

I read the article the quote was pulled from, as well as participated in the discussion and responded to the author when it was posted here. Just FYI, Safari (which already has this feature in the form of content blockers) is able to block ads just fine, and anecdotally the performance is slightly, but noticeably better.

The question still remains: what are they optimizing for if we already have sub-millisecond response times? The only evidence you offer is anecdotal. I'm having a hard time imagining perceptible differences in sub-millisecond response times so either you or the study are in error. And just to reiterate other comments: yes, Safari is probably able to block ads just fine now , because they modeled the engine according…

To be honest, I'm much more in favor of this API because of its privacy features than performance. I think it's a little bit faster, but it has a much bigger benefit on the trust side because extensions no longer run arbitrary JavaScript in every page I visit.

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

#65

Post by _0w8t »

sametmax wrote: post #37
happybuy wrote: post #32

Sounds like Google will still move towards what they were planning but will likely just take a bit more time and more versions to get there (as the outrage subsides). From my perspective, the biggest improvement in their proposal would have been the increased privacy and security users would receive with adblockers that use the proposed scheme. Under the current scheme, any Chrome adblocker can see all of the pages t…

At some point, new ads the system can't block will surface. The adblocker will become less and less useful, and Google will have no incentive to improve it. There is already a big difference between even existing adblockers. E.G: some show youtube ads. And I'm much more worry about the privacy concern from many random ads poping unexpectedly, than from one extension that the entire community get to vet.

At some point adblockers will run a browser in a headless mode and use ML algorithms to show ad-filteret result to the user.

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

#66

Post by plg »

rat9988 wrote: post #60
Vogtinator wrote: post #59

Earlier quoted context omitted.

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

I wonder why people make such bold wrong claims.

I think in this case it’s probably because the person in question is simply mistaken. The other possibility is that they are some kind of Rust evangelist and they are actively trying to deceive people. I doubt it. Could we please approach each other with the benefit of the doubt? Could we please gently, constructively correct errors? I see no need to be so aggressive, especially in our current social/political climate.

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

#67

Post by bufferoverflow »

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.

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

#68

Post by kome »

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…

Stallman was right all along.

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

#69

Post by itissid »

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...

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

#70

Post by chr1 »

ocdtrekkie wrote: post #31
chr1 wrote: post #29

Earlier quoted context omitted.

Playing devils advocate here, why a different engine is needed? Chrome clone can add webrequest feature too, and it would be much easier to maintain.

The problem with forks is having to chase upstream. The dominant browser can keep making changes with reckless abandon. And the fork has to keep up with those, even if it breaks their own features, lest they become incompatible with the "standard" version.

chasing upstream is a lot easier than chasing web standards and chromes performance, especially if you are only interested in providing more powerful extension api and better ui
Post reply on HN