(Edit: Re original title: "Only enterprise Chrome installs will have full ad-blocking")
Seems to be referring to this part of the text:
> Observation
> Chrome is deprecating the blocking capabilities of the webRequest API in Manifest V3, not the entire webRequest API (though blocking will still be available to enterprise deployments). Extensions with appropriate permissions can still observe network requests using the webRequest API. The webRequest API's ability to observe requests is foundational for extensions that modify their behavior based on the patterns they observe at runtime.
No idea if that's the API that adblockers use (or just a part of it)...
I was under the impression that the ability to observe all requests was the whole problem that made the webrequest api dangerous. Now they're keeping that but eliminating the blocking features only? What?
The stated reason for removing blocking from WebRequest is to improve performance, not privacy. If an extension can block a request, Chrome needs to wait for the extension before performing the request. See the WebRequest section in the design document:
In fairness to Google, it's not absurd in principle. Mozilla has dealt with this problem for years: when an extension slows the browser down, the user is more likely to blame the browser than the extension. But in this specific case of ad-blocking extensions, I have a hard time taking Google's justification seriously. Ad blockers speed up the browsing experience far more than whatever negligible processing time the filter process takes.
That's exactly what it is- taking the choice away from the user. There were other options they could have taken- such as warning a user when installing an extension that uses these APIs, or building out a new asynchronous API (like Firefox did).
Instead they choose to go with the option that screws over users but might make them more money.
Yes. That's what the google employees said, but I recall ghostery or some other group publishing actual numbers showcasing it took microseconds to do the check
This showcased the google employees declaration it was performance to be smoke.
So far as the original message seemed to be saying, it isn't about the uBlock Origins of the world, well behaved, highly performant code. They don't hurt end users. It's the badly written add-ons that they're trying to eliminate.
Given what they're breaking by their chosen mechanism, I would have thought educating end users would be the better approach. The running Chrome instance would be able to tell that an add-on is a large source of blocking, and could easily pop up a warning to indicate such, complete with a one-click option to disable the add-on.
> If this (quite limited) declarativeNetRequest API ends up being the only way content blockers can accomplish their duty, this essentially means that two content blockers I have maintained for years, uBlock Origin ("uBO") and uMatrix, can no longer exist.
Why guess? We know brave’s business model is equally bad. There’s a company which its main objective is user privacy and safety, and that’s Mozilla. Current versions are exceptionally polished and speedy and you know what you’re getting.
It's painful to think how they are about to single handedly destroy the best web browser that's ever existed (IMO). All that hard work over the last decade basically gone to waste.
Does someone have a source we can use that spells this out? It does not follow from the quoted text that “Only enterprise Chrome installs will have full ad-blocking”.
One reason for the title policy on Hacker News is that original titles have actual articles attached to them. Editorialized claims do not pass muster for quality of information here (this isn't a “what can you say in 80-characters” website). If the original title is misleading or clickbait, then we still have a chance of using representative language directly from the source. We could also do that here if someone can suggest it.
Sure, I agree; if the original title isn't true, then this isn't much of a story... which is why I posted my comment in the first place; the closest relevant answer is quoted by sister comment by Koffiepoeder.
Lot's of people using chromium or enterprise chrome.
As long as ublock origin (then incompatible with mainline chrome) is not pulled from the webstore, and as long as there is a simple #ifdef that most linux distros can toggle, I am not really affected by the change. I assume that the same holds for most developers, crucially including the people behing ublock.
There was a time i couldn't imagine moving away from chromium... all the FF people shout about features, I care not, I want a browser that is good at the fundamentals, has a non intrusive UI and allows me to block ads, that wasn't FF, i should know I've submitted my fair pile of FF bugs, and stumbled across a decent amount of decade old ones.
However these days I find myself using FF more and more for those very reasons, where chromium/chrome is failing more and more. The other side of this is of course that FF has been improving massively in recent years.
There is no best, browsers are ridiculously complicated and hard, but i suppose there are phases, if chromium team loose sight of how non-obscure the requirement to block ads easily is to all users today, this may be the start of a different phase.
>if chromium team loose sight of how non-obscure the requirement to block ads easily is to all users today, this may be the start of a different phase.
I don't think you realize how many tech illiterate people don't block ads.
You could be right, but i'd be more convinced by some stats. On the occasions that i use a browser without an ad blocked, it's so intrusive and unplesant these days that I imagine plenty "non-technical" users seeking out a solution purely from the perspective of basic usability.
Personally, I find it amusing because "smoothness" is something that I consider completely unimportant. (I do understand that I am not representative of the average user.)
Speaking for myself, what brought me to Chrome from Firefox was a regression bug with my Logitech Revolution mouse: zoom out didn't work. It works in Chrome and in every other app.
No one seems to care, basically a soft "won't fix". I even thought about fixing it myself but after seeing that the solution wasn't obvious, I gave up.
I wanted to give Chrome a try anyways, so I did. And not only mouse zoom worked but pages also loaded faster. Time to completion was about the same but it took less time to actually see something. For the rest, I had no trouble finding extensions to match what I could do with Firefox. Clear win for Chrome.
Now, I am using Firefox at work and Chrome at home so I can follow. What I noticed was:
- Firefox performance more or less caught up with Chrome (or is it the other way around?)
- Chrome seems a bit more stable
- Generally, switching is super-easy, besides syncing (Firefox doesn't sync with Google and Chrome doesn't sync with Firefox sync, and I am not a fan of third party solutions)
- I've yet to re-test mouse zoom, but according to the bug report, it still isn't fixed.
Note that mouse zoom may seem trivial but it is not. Chrome and Firefox are practically the same, at least on the desktop, so small details like that are what make people switch.
And to be honest, I am pretty pissed off with Firefox. They have really good core devs. Servo is awesome, and even though I dislike the community (seen from the outside), I also find Rust to be just as awesome for its application. Direction however is seriously lacking.
The latest goof was the extension signing fiasco. Again, small thing, but enough to turn off some people. The most ironic part is that they fixed that using a telemetry-related backdoor. I don't really have a problem with that (otherwise I wouldn't use Chrome) but for a browser that advertise itself as privacy oriented, it is not good publicity.
You might recoup more in productivity from less surfing of sites like hn than the minutiae of gains from chromium to Firefox. Hard to believe chrome in 2019 can give discernible amounts of productivity gain over Firefox, unless it were a very very specific extension exclusive to chrome.
I don't know why you're being downvoted. I use Firefox as my main browser and suffer through extremely slow performing Jira. It makes it seem like Atlassian only tests in Chrome. Gmail and Google Calendar are bad too, but tolerable given how infrequently I need to navigate between views.
I actually have the same problem with gmail. I once, as in the last 6 months, waited a good 3+ minutes (as recorded in firefox dev tools) for gmail to fully load. Switching to chrome was a dramatically better experience. I didn't mention it here thinking Google was sabotaging Firefox.
I use jira and ff sucks with jira -- it slowly ramps up to tons of ram and cpu during the day. The symptom is I'm in a meeting / on battery and all of a sudden most of the battery is gone.
Blocking ads goes against Googles main revenue stream, but giving people the option to block ads follows directly with Mozilla's mission. I don't think there's any danger they follow Chrome in this.
I don't think there is anything about that in moz://a's manifesto, but maybe my interpretation is wrong. On the other hand, Google being their main source of revenue they are indirectly funded by ad money too.
Commercial involvement in the development of the Internet brings many benefits; a balance between commercial profit and public benefit is critical.
Principle 5 "Individuals must have the ability to shape the Internet and their own experiences on the Internet." can be read as "the user can modify how the client displays the page".
More importantly: with the current status quo where both site operators and ad networks reject responsibility for security implications of their ads and ad networks show little regards for privacy, the only way I see to respect Principle 4 "Individuals’ security and privacy on the Internet are fundamental and must not be treated as optional." is to block offending ad networks.
Regardin principle 4 I don't quite agree, if that was the interpretation we would had something like ublock in core FF years ago. It is very clearly not a technical problem.
As for principle 5 I do not hold my breath but hope you are right.
I imagine that Firefox becoming Brave by blocking all ads would lose Mozilla their biggest source of revenue: Google paying them to have Google search as the default on FF.
> [Google] could force Mozilla to disable ad-blocking.
So you claim. I claim that this is wrong.
> Mozilla has already being force from external pressure in the past, see DRM.
Very different as the pressure was from not losing even more user who suddenly would be unable to use Amazon Prime Video, Netflix, etc. They fought the proposal but once it was established they had no real way of not including DRM blobs and stay a mainstream browser.
Over 90% of Mozilla's funding comes from having Google search as the default[0]. If FF users weren't seeing ads, then Google would have no reason to pay for that service. So Mozilla loses its funding.
You can always quit Firefox process and reopen it again, unlike Chrome, Firefox doesn't auto load all tabs again, so this will kill any scripts running or monitoring in rest of the tabs. This almost always solves my issues.
Firefox has recently decided that it is totally fine to refuse to work after an update until you restart it.
I don't mind automatic updates. I don't mind being bugged to restart. However I really dislike that my browser can just break in the middle of a browsing session because of some remote decision.
It feels like the people at Mozilla are forgetting that the browser and browser extensions are tools that people use to do important things.
There's also AdGuard, which acts as a VPN and blocks traffic on that IP, DNS, and (optionally, if you enable their certificate) HTTP/S domains. Because it works on the VPN level it blocks ads for all apps, not just the browser.
Google won't allow the full version in the Google Play Store (probably for the same reason they're breaking adblockers on the desktop), but you can download the full APK here-
Also trivially accomplished with PiHole or adblock on OpenWRT, and with a bit more work, Privoxy, SquidGuard, and related tools. Running your own DNS server (DNSMasq, Knot Resover (kresd), Bind) pretty much gives you carte blanche to do anything you want.
True. Though also for all other devices on that LAN.
There are device-based adblock systems that can be applied. On a rooted Android, you can run DNSMasq locally. For iOS there are adblocking apps AFAIU. Or you could (and perhaps should) run all traffic through a VPN, with adblock, when remote.
> We don’t need to worry about web monoculture. Chrome is open source after all.
Chromium doesn't really have many of the benefits of other open source projects, it's a behemoth (have you ever tried a shallow clone and build from scratch?). Forking chrome is pointless unless you have an army behind you to maintain it. In that sense, chrome is chrome, and nothing more, it's proprietary by sheer volume.
Anything based on it is usually little more than a chrome skin, or at best an out of date tracking branch that's been pulled apart and put back together again, e.g QtWebEngine which takes 6 months between releases just to pull apart the code to strip all offensive code and put back together again.
Excerpt: "What we see are the public statements, for public consumption, they are designed to "sell" the changes to the wider public. What we do not see is what is being said in private meetings by officers who get to decide how to optimize the business."
Thank you gorhill for what you did to the web community.
The title of this post was edited. The original title—and the interesting part of the linked article—is "Only enterprise Chrome installs will have full ad-blocking."
I think it's rather telling that Simeon Vincent has buried this news in an off-handed one line comment buried in the middle of a rather long post, and I think it's unfortunate that HN's title policy has also buried the lede.
It is remarkable that the title on HN could be changed to something that borders on strategically dull. I don't think you could create a less communicative title if you tried. This is an important story which affects a large portion of the HN audience, yet I doubt even 1% of the affected users would know what "Manifest V3" refers to.
"A response to feedback on the proposed changes in Manifest V3" is so outrageously devoid of information that it is difficult to come up with an innocent explanation for it.
It's not being intentionally buried, but the rapid drop in interest is a testament to the utter dullness of "A response to feedback on the proposed changes in Manifest V3"
"Manifest V3" is jargon, which is a big problem in HN. See Show HNs that don't really explain what is the thing being introduced.
The Response -> feedback -> proposed changes chain is verbose. The three concepts are almost a single concept (changes) wrought as present -> past -> future.
"A response to feedback on the proposed changes in Manifest V3" is a characteristically Google-internal-y [0] way to say "Update on coming changes to Chrome extension APIs".
[0]: My unscientific feeling is that a lot of engineers at Google write about projects as if the audience is other Google engineers. It's not out of malice, but it's convenient when you don't have to explain the full rationale for a change.
Just in relation to your first paragraph, if you want to see how such titles change over time here on HN, they're tracked at https://hackernewstitles.netlify.com/
That's been SOP for Google for at least the past year or so, if not more. Consider the titles used to announce shutdown and massive schedule and feature curtailments of Google+:
Don't worry, if the issue is as described it's going to spawn a lot of headlines of Hacker News, not just this one.
Though in changing the title to something that could only be described as strategically dull, at least we now know where the loyalty of HN moderators lie.
That's not a viable explanation, as "A response to feedback on the proposed changes in Manifest V3" is not the page title. At best it's a modified version of the first sentence.
Furthermore it's a rule which is rarely followed. Look at most of the title edits: more edits are deviating the submission titles away from the original page title.
Thanks. I actually got this from the reg article but followed HN rules and posted the original google groups link. The register article is much clearer.
Do you collect any stats for overall ads blocked?, I wonder how much $$ damage you did to Google finances since you launched your extensions on Chrome and Firefox.
In all seriousness though, this line of thinking is, at best, going to feel like constant victimisation if one engages in it far too often. Don't be surprised if people don't go out of their way to give you money they don't have to give you in order to get what they want in the way they want it. Lost revenue refers to revenue you could've captured if you had done things differently, so do them differently. If there's any damage done, it's damage you did to yourself.
More folks should read the 10-K [0], as it is pretty interesting. Among other things, it does say that content-blocking tools pose a threat to Google's advertising business, and that Chrome is important to Google's product lineup.
The author spends a lot of time saying the changes aren't immutable, then goes on to say "Chrome is deprecating the blocking capabilities of the webRequest API in Manifest V3".
That seems both very final, and as if they have entirely failed to read any of the feedback the community has given them.
If they remove the API, can they be sued for non-competitive behavior?
Obviously, Chrome has a monopoly in web browsing, especially on desktop. And this can be seen as a leverage for a different business they have, namely ads.
In what world does Chrome have a monopoly on web browsing? They have ~66% market share, and there are at least two high quality, free, alternatives on Mac and Windows that are only a click away
So how many billions should the EU fine them this time to make them take notice? Using their dominant position in the browser market to bolster their dominant ad business, hmmm, maybe a fine isn't enough.
They shouldn't be fined anything. If you don't like it, get another browser.
There is nothing that entitles you or the EU to coerce other people or organizations to practice certain behavior or make changes to their property (source code).
In environments where use of Chrome is forced on us (e.g., a workplace), with this change will we still at least be able to use NoScript to protect from drive-by malware downloads?
If uBlock Origin is going to go away from Chrome, my first choice would be Firefox but if I can't use that then I think I'd rather use Chrome with NoScript (if possible) and images turned off.
I think it would be telling if eyeo GmbH is also in favor of these changes.
The way ABP works will probably be 'good enough' for the average user, for at least as long as it takes to sway or marginalize competing browsers and to come up with an ad content delivery strategy that requires (by then) long unsupported extension features to counter.
They're building the pot with which they'll slow boil the content blocking crab.
Did anyone else notice the double meaning of the term "blocking"? This bit tipped me off to the confusion:
> And he argues that if the blocking nature of the webRequest API really represents a performance concern, Google could just adopt Firefox's approach which uses a technique called Promises to return a non-blocking/asynchronous response.
They do explicitly say "content blocking" in a few places, but in most instances they say "blocking webRequest API" which might actually refer to blocking-as-opposed-to-non-blocking and not ad-blocking.
146 comments
[ 2.6 ms ] story [ 194 ms ] threadSeems to be referring to this part of the text:
> Observation
> Chrome is deprecating the blocking capabilities of the webRequest API in Manifest V3, not the entire webRequest API (though blocking will still be available to enterprise deployments). Extensions with appropriate permissions can still observe network requests using the webRequest API. The webRequest API's ability to observe requests is foundational for extensions that modify their behavior based on the patterns they observe at runtime.
No idea if that's the API that adblockers use (or just a part of it)...
https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3Nzz...
Instead they choose to go with the option that screws over users but might make them more money.
This showcased the google employees declaration it was performance to be smoke.
Given what they're breaking by their chosen mechanism, I would have thought educating end users would be the better approach. The running Chrome instance would be able to tell that an add-on is a large source of blocking, and could easily pop up a warning to indicate such, complete with a one-click option to disable the add-on.
It is; https://bugs.chromium.org/p/chromium/issues/detail?id=896897....
You can rest assured that if I can't have adblocking in chrome, then I'll stop using chrome.
https://addons.mozilla.org/en-CA/firefox/addon/ublock-origin...
https://addons.mozilla.org/en-CA/firefox/addon/umatrix/?src=...
One reason for the title policy on Hacker News is that original titles have actual articles attached to them. Editorialized claims do not pass muster for quality of information here (this isn't a “what can you say in 80-characters” website). If the original title is misleading or clickbait, then we still have a chance of using representative language directly from the source. We could also do that here if someone can suggest it.
(bar the addons hickup which meant it was off for a day, but that was no issue)
As long as ublock origin (then incompatible with mainline chrome) is not pulled from the webstore, and as long as there is a simple #ifdef that most linux distros can toggle, I am not really affected by the change. I assume that the same holds for most developers, crucially including the people behing ublock.
However these days I find myself using FF more and more for those very reasons, where chromium/chrome is failing more and more. The other side of this is of course that FF has been improving massively in recent years.
There is no best, browsers are ridiculously complicated and hard, but i suppose there are phases, if chromium team loose sight of how non-obscure the requirement to block ads easily is to all users today, this may be the start of a different phase.
I don't think you realize how many tech illiterate people don't block ads.
I keep hoping for the day I can switch and not lose productivity.
Here is the bug report https://bugzilla.mozilla.org/show_bug.cgi?id=791429
No one seems to care, basically a soft "won't fix". I even thought about fixing it myself but after seeing that the solution wasn't obvious, I gave up.
I wanted to give Chrome a try anyways, so I did. And not only mouse zoom worked but pages also loaded faster. Time to completion was about the same but it took less time to actually see something. For the rest, I had no trouble finding extensions to match what I could do with Firefox. Clear win for Chrome.
Now, I am using Firefox at work and Chrome at home so I can follow. What I noticed was:
- Firefox performance more or less caught up with Chrome (or is it the other way around?)
- Chrome seems a bit more stable
- Generally, switching is super-easy, besides syncing (Firefox doesn't sync with Google and Chrome doesn't sync with Firefox sync, and I am not a fan of third party solutions)
- I've yet to re-test mouse zoom, but according to the bug report, it still isn't fixed.
Note that mouse zoom may seem trivial but it is not. Chrome and Firefox are practically the same, at least on the desktop, so small details like that are what make people switch.
And to be honest, I am pretty pissed off with Firefox. They have really good core devs. Servo is awesome, and even though I dislike the community (seen from the outside), I also find Rust to be just as awesome for its application. Direction however is seriously lacking.
The latest goof was the extension signing fiasco. Again, small thing, but enough to turn off some people. The most ironic part is that they fixed that using a telemetry-related backdoor. I don't really have a problem with that (otherwise I wouldn't use Chrome) but for a browser that advertise itself as privacy oriented, it is not good publicity.
* no battery nuking while jira is open
Like listen, I really want to like firefox. But I use jira all day.
Best of both worlds.
Commercial involvement in the development of the Internet brings many benefits; a balance between commercial profit and public benefit is critical.
https://www.mozilla.org/en-US/about/manifesto/details/
More importantly: with the current status quo where both site operators and ad networks reject responsibility for security implications of their ads and ad networks show little regards for privacy, the only way I see to respect Principle 4 "Individuals’ security and privacy on the Internet are fundamental and must not be treated as optional." is to block offending ad networks.
As for principle 5 I do not hold my breath but hope you are right.
Mozilla has already being force from external pressure in the past, see DRM.
So you claim. I claim that this is wrong.
> Mozilla has already being force from external pressure in the past, see DRM.
Very different as the pressure was from not losing even more user who suddenly would be unable to use Amazon Prime Video, Netflix, etc. They fought the proposal but once it was established they had no real way of not including DRM blobs and stay a mainstream browser.
Nevertheless, it could be due to personal opinions, but catering to your main commercial partner's business model is imo more plausible.
As much as I am in favour of ad blocking, anything which modifies the content of a requested resource should be opt-in.
Over 90% of Mozilla's funding comes from having Google search as the default[0]. If FF users weren't seeing ads, then Google would have no reason to pay for that service. So Mozilla loses its funding.
[0]https://en.wikipedia.org/wiki/Mozilla_Foundation#Financing
I can feel my laptop loudly spinning fan, after a long running firefox session. It stops doing this, if I close / restart firefox.
If more people switch to Firefox, this might be an additional effect: a rise in the usage of desktop mail clients.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909818
(I've seen variants of this problem on Ubuntu 18.04 LTS.)
Opening up Chrome feels very dated.
Every time I open it up I feel like I’m stepping back in time to 2009. All those rounded bezels!
I'd imagine Google saw a slight increase of revenue during that period.
No wonder why they don't allow extensions on their Android browser. From everyone I know, only I am using Firefox on a Chrome device.
I don't mind automatic updates. I don't mind being bugged to restart. However I really dislike that my browser can just break in the middle of a browsing session because of some remote decision.
It feels like the people at Mozilla are forgetting that the browser and browser extensions are tools that people use to do important things.
https://www.xda-developers.com/kiwi-browser-google-chrome-ex...
[1] https://play.google.com/store/apps/details?id=com.brave.brow...
https://adguard.com/
Google won't allow the full version in the Google Play Store (probably for the same reason they're breaking adblockers on the desktop), but you can download the full APK here-
https://adguard.com/apk
https://pi-hole.net/
https://openwrt.org/packages/pkgdata/adblock (see: https://github.com/openwrt/packages/blob/master/net/adblock/...)
https://www.privoxy.org
http://www.squidguard.org
http://www.thekelleys.org.uk/dnsmasq/doc.html
https://knot-resolver.readthedocs.io/en/stable/daemon.html
https://www.isc.org/downloads/bind/
There are device-based adblock systems that can be applied. On a rooted Android, you can run DNSMasq locally. For iOS there are adblocking apps AFAIU. Or you could (and perhaps should) run all traffic through a VPN, with adblock, when remote.
Obviously sarcasm on my part, but I see this terrible (and false) argument every time someone complains about the Chrome market share near-monopoly.
You’d think people would know better by now.
Edit: sarcasm made clearer.
Chromium doesn't really have many of the benefits of other open source projects, it's a behemoth (have you ever tried a shallow clone and build from scratch?). Forking chrome is pointless unless you have an army behind you to maintain it. In that sense, chrome is chrome, and nothing more, it's proprietary by sheer volume.
Anything based on it is usually little more than a chrome skin, or at best an out of date tracking branch that's been pulled apart and put back together again, e.g QtWebEngine which takes 6 months between releases just to pull apart the code to strip all offensive code and put back together again.
Currently I mostly use FF for the web and Chrome for Dev and testing but if I have a tab open I'll use it.
If I can't use ublock origin I'll lock down Chrome so that I can only visit a whitelist of things I need to Dev/test and switch entirely to Firefox.
Excerpt: "What we see are the public statements, for public consumption, they are designed to "sell" the changes to the wider public. What we do not see is what is being said in private meetings by officers who get to decide how to optimize the business."
Thank you gorhill for what you did to the web community.
I think it's rather telling that Simeon Vincent has buried this news in an off-handed one line comment buried in the middle of a rather long post, and I think it's unfortunate that HN's title policy has also buried the lede.
"A response to feedback on the proposed changes in Manifest V3" is so outrageously devoid of information that it is difficult to come up with an innocent explanation for it.
I don't get what the aim is here. Why bury a story that everyone is going to know about soon enough?
Edit: to the numerous people who are voting my comments down, could you please provide actual feedback?
"Manifest V3" is jargon, which is a big problem in HN. See Show HNs that don't really explain what is the thing being introduced.
The Response -> feedback -> proposed changes chain is verbose. The three concepts are almost a single concept (changes) wrought as present -> past -> future.
"A response to feedback on the proposed changes in Manifest V3" is a characteristically Google-internal-y [0] way to say "Update on coming changes to Chrome extension APIs".
[0]: My unscientific feeling is that a lot of engineers at Google write about projects as if the audience is other Google engineers. It's not out of malice, but it's convenient when you don't have to explain the full rationale for a change.
"Project Strobe: Protecting your data, improving our third-party APIs, and sunsetting consumer Google+" https://blog.google/technology/safety-security/project-strob...
"Expediting changes to Google+" https://www.blog.google/technology/safety-security/expeditin...
"An update on Google+ and Blogger" https://blogger.googleblog.com/2019/01/an-update-on-google-a...
"Important changes to Google+ for G Suite due to the consumer shutdown" https://support.google.com/a/answer/9229693
From the company which defined SEO, this can only be deliberate.
Though in changing the title to something that could only be described as strategically dull, at least we now know where the loyalty of HN moderators lie.
Loyal to consistently implementing the rule of "HN submission title should match the original page title"?
Furthermore it's a rule which is rarely followed. Look at most of the title edits: more edits are deviating the submission titles away from the original page title.
https://hackernewstitles.netlify.com/
Of course it's a moot point now. This article's new title has caused it to drop off the home page and it's now effectively dead.
The most concise summary I can come up with is in the article:
> Google's primary business is incompatible with unimpeded content blocking.
* * *
[1] https://www.theregister.co.uk/2019/05/29/google_webrequest_a...
I wonder how much $$ damage google does to us by loading unwanted and unnecessary adds on our (metered or limited) internet lines.
Never give up the fight.
[0] https://www.sec.gov/Archives/edgar/data/1288776/000165204416...
https://seekingalpha.com/filing/4328532
That seems both very final, and as if they have entirely failed to read any of the feedback the community has given them.
Obviously, Chrome has a monopoly in web browsing, especially on desktop. And this can be seen as a leverage for a different business they have, namely ads.
There is nothing that entitles you or the EU to coerce other people or organizations to practice certain behavior or make changes to their property (source code).
I have to say, though, I am shocked that enterprises actually pay for Chrome. What the heck!
If uBlock Origin is going to go away from Chrome, my first choice would be Firefox but if I can't use that then I think I'd rather use Chrome with NoScript (if possible) and images turned off.
The way ABP works will probably be 'good enough' for the average user, for at least as long as it takes to sway or marginalize competing browsers and to come up with an ad content delivery strategy that requires (by then) long unsupported extension features to counter.
They're building the pot with which they'll slow boil the content blocking crab.
> And he argues that if the blocking nature of the webRequest API really represents a performance concern, Google could just adopt Firefox's approach which uses a technique called Promises to return a non-blocking/asynchronous response.
They do explicitly say "content blocking" in a few places, but in most instances they say "blocking webRequest API" which might actually refer to blocking-as-opposed-to-non-blocking and not ad-blocking.