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

Google proposes changes to Chromium which would disable uBlock Origin

bugs.chromium.org

Post reply on HN
Print view View original

551–560 of 779 posts

Re: Google proposes changes to Chromium which would disable uBlock Origin

#551

Post by dzhiurgis »

edwintorok wrote: post #317
metalliqaz wrote: post #183

Earlier quoted context omitted.

But the design document only mentions retaining the old API for features that aren't possible with the new API, such as onAuthRequired. So it would still cripple uBlock

What if someone would create a pull request to implement unlock origin natively inside chromium, instead of an extension. If such a PR met all technical criteria, would Chromium project accept it?

I'd love Chromium feature that uses system password manager (macOS / iCloud).

On the flip side Chrome's profiles are nice and I wish macOS supported more of it.

Re: Google proposes changes to Chromium which would disable uBlock Origin

#552

Post by tlavoie »

DanielRibeiro wrote: post #366
metalliqaz wrote: post #183

Earlier quoted context omitted.

But the design document only mentions retaining the old API for features that aren't possible with the new API, such as onAuthRequired. So it would still cripple uBlock

I really like the point the uBlock maintainer's make: "Extensions act on behalf of users, they add capabilities to a user agent , and deprecating the blocking ability of the webRequest API will essentially decrease the level of user agency in Chromium, to the benefit of web sites which obviously would be happy to have the last word in what resources their pages can fetch/execute/render."

Is it perhaps time to return to using external tools such as Privoxy, Pi-Hole and the like? Privoxy appears to still be around, and (I think) was originally at the forefront of user-managed web controls.

Once the browser reaches its natural Borg-self, transparent user-level tools will be all that provide a semblance of control. Well that, and Firefox.

Re: Google proposes changes to Chromium which would disable uBlock Origin

#553

Post by klardotsh »

antoineMoPa wrote: post #144
QML wrote: post #112

Earlier quoted context omitted.

Firefox just doesn’t have enough advantages yet that would convince someone comfortable with Chrome to switch over. While privacy is an ever growing concern, it isn’t a strong enough feature for most people.

Well now Firefox will have ad blocking plugins that works and Chrome will not.

We'll see how long it lasts.

Firefox has mostly strived, in the Quantum era, to stay mostly-ish compatible with Google's interpretation of WebExtensions, from what I can tell.

Re: Google proposes changes to Chromium which would disable uBlock Origin

#554

Post by jlarocco »

givinguflac wrote: post #399
jlarocco wrote: post #298

Earlier quoted context omitted.

Network level ad-blocking doesn't work very well. Privoxy (and Proxomitron before it) were doing it 20 years ago, but never caught on because they're a PITA to setup and can't handle inline adverts. Pi-hole is new, but it's even more work to setup, and suffers the same limitations. And as ad-blocking has become more popular the problems only gotten worse. It's unusual that I see any ads any more, but when I do it's a…

I can’t speak for pi-hole, but Diversion on Asuswrt-Merlin works fantastic for me. No ads ever except for YouTube ads lately due to google’s changes to how they serve ads from the same servers they provide services on.

> No ads ever except for YouTube ads lately due to google’s changes to how they serve ads from the same servers they provide services on.

Thats what I meant by network level blocking doesn't work very well. Using uBlock Origin, I don't see YouTube ads.

Re: Google proposes changes to Chromium which would disable uBlock Origin

#555

Post by addicted »

jbigelow76 wrote: post #445
berbec wrote: post #382

Earlier quoted context omitted.

Next to no one uses Chromium. The integrations usually start in Chrome, leaving Chromium pure, allowing Opera etc to forge their own path. This is a disturbing trend to change the course of the project, likely due to Edge being based on Chromium.

I bet a decent chunk of the MS engineers lobbied to adopt Gecko instead of Chromium when they decided to move away from EdgeHtml. I wonder what the reasoning was for not going that route, it seems like a huge miss and a total acceptance of a browser monoculture.

nodeJS uses Chromium and not Gecko. I suspect MS’s requirements basically necessitated the use of Chromium.

However, this does provide an opening for MS edge, if MS forks Chromium for Edge and excludes user hostile “features” such as this.

Re: Google proposes changes to Chromium which would disable uBlock Origin

#556

Post by pfranz »

raptorfactor wrote: post #351
pfranz wrote: post #286

Earlier quoted context omitted.

I was doing some work with very large data sets in Google Sheets last week. I started hitting row and cell limits. Personally, I think a database is more appropriate for what I was doing, but spreadsheets are more grokable by non-techies. In Firefox, macOS was showing 4+GB of memory usage and formulas would take hours to run. I switched to Safari where memory usage was closer to 1-2GB, but it had this habit of refres…

Do you have examples which aren't Google sites?

Is that really relevant? I'd be happy if you could point me to a more capable tool. Zoho and Excel Online have never really made it onto my radar, but if they perform better in this situation I'd check them out. A lot of people are tied to the constraints they have.

Using both for years, Chrome has just been faster and more reliable. I don't do web dev professionally, but I use multiple browsers in tandem and often try to use one full time every once in awhile. On my old laptop, I'm pretty sure Chrome was the only one to support webGL for whatever reason. At work we're stuck with Firefox 38.3.0 ESR (Cent6/7) and Prometheus Alert Manager (and I also believe Prometheus graphing interface) has broken widgets, but Chrome works. Chrome has always seemed to better support the very few websites that require crazy performance. This was even the case when we would have an ancient version of Chrome and a new version of Firefox. It sucked when Firefox switched plugin architecture and Google Hangouts never added support. Now Google Meet does not support Safari.

I'm not saying any of these comparisons are "fair" but its what I deal with day-to-day.

Re: Google proposes changes to Chromium which would disable uBlock Origin

#557

Post by qbaqbaqba »

sgentle wrote: post #494
DanielRibeiro wrote: post #366

Earlier quoted context omitted.

I really like the point the uBlock maintainer's make: "Extensions act on behalf of users, they add capabilities to a user agent , and deprecating the blocking ability of the webRequest API will essentially decrease the level of user agency in Chromium, to the benefit of web sites which obviously would be happy to have the last word in what resources their pages can fetch/execute/render."

I think this is the core difference motivating this change: do extensions necessarily act on behalf of users? If that were true, there'd be no such thing as extension malware.

Google's business model is exactly the same.

Re: Google proposes changes to Chromium which would disable uBlock Origin

#558

Post by michaelt »

tlavoie wrote: post #552
DanielRibeiro wrote: post #366

Earlier quoted context omitted.

I really like the point the uBlock maintainer's make: "Extensions act on behalf of users, they add capabilities to a user agent , and deprecating the blocking ability of the webRequest API will essentially decrease the level of user agency in Chromium, to the benefit of web sites which obviously would be happy to have the last word in what resources their pages can fetch/execute/render."

Is it perhaps time to return to using external tools such as Privoxy, Pi-Hole and the like? Privoxy appears to still be around, and (I think) was originally at the forefront of user-managed web controls. Once the browser reaches its natural Borg-self, transparent user-level tools will be all that provide a semblance of control. Well that, and Firefox.

If a website shows a popover ad, it might be a first-party script putting up a modal, then a third-party iframe with the ad inside that modal.

Blocking at the network layer will leave the iframe blank, but the modal will still be present. It's not such a good user experience, especially for less savvy users who might be confused by a mysterious blank modal.

Re: Google proposes changes to Chromium which would disable uBlock Origin

#559

Post by michaelt »

happybuy wrote: post #244

To defend Google a bit, it looks like the change is being put in place so that users would have more privacy – by stopping extensions accessing all active URLs. In essence they are copying what Apple did with Safari and their content blocking APIs. In this model, content blockers provide the browser with a set of blocking rules and the browser executes them against pages during render & load. Ad blocking can occur an…

How do you explain the fact ad blockers on iOS Safari so much less effective than uBlock Origin?

Re: Google proposes changes to Chromium which would disable uBlock Origin

#560

Post by feanaro »

Why would Google be given any benefit of a doubt in the case of ad/resource blocking?

They are a behemoth ad-based corporation that is becoming a monopoly in many areas of computing. In yet more areas, they are becoming an effective monopoly through size: they may not be the only company offering a type of service, but they are the only one able to offer it at scale and/or with a certain level of sophistication, given their resources are orders of magnitude larger than almost any other company's.

All this taken into account, it's obvious how much is at stake for them. Why wouldn't they try crippling blockers? Their revenue depends on it and the only counter-incentive is that there may be a massive exodus of users to Firefox, while it still exists. Do it slowly enough, though...

Post reply on HN