[HN Gopher] AdGuard publishes the first ad blocker built on Mani...
___________________________________________________________________
AdGuard publishes the first ad blocker built on Manifest V3
Author : kapsteur
Score : 297 points
Date : 2022-08-30 08:55 UTC (14 hours ago)
(HTM) web link (adguard.com)
(TXT) w3m dump (adguard.com)
| conschy wrote:
| Correction:
|
| Analytics & Ad Blocker by Globemallow.io https://globemallow.io/
| was the first Manifest v3 Ad Block extension.
|
| I first published on 06/22/2022.
|
| Last night actually I asked if AdGuard would want to license the
| software, and sent them a link to my extension. They are aware
| they weren't the first, and made this post after knowing it.
| phunehehe0 wrote:
| This is interesting if true. How can people verify that your
| extension is compatible with Manifest V3? I can see on the
| Chrome Web Store that the latest version of your extension was
| published before the latest version of AdGuard (August 23, 2022
| vs August 30, 2022) so there's that.
| conschy wrote:
| You can add a Chrome Source Code Viewer. I like this one.
| https://chrome.google.com/webstore/detail/chrome-
| extension-s...
|
| Then look in the Manifest.json for manifest_version.
|
| Here's the Twitter showing the timeline:
| https://twitter.com/GlobeMallow_io
|
| The best part is AdGuard is still running manifest v2.
| ghoward wrote:
| I think @cycomaniac [1] is right. We, as developers, did this. We
| gave Google too much power.
|
| I've just switched to Firefox. I hope they don't go off the rails
| here, but I fear they will with bribes from Google.
|
| [1]: https://news.ycombinator.com/item?id=32650136
| t6jvcereio wrote:
| So wait. What's wrong with ublock origin?
| jeroenhd wrote:
| Nothing, except for that it may stop working in Chrom[e|ium]
| next year when Google kills the current standard for web
| extensions.
|
| There's been some work done on fixing this issue
| (https://github.com/uBlockOrigin/uBlock-issues/issues/338) but
| the architecture of content blocking extensions will need to
| change to facilitate Google's new requirements.
| ajvs wrote:
| They don't have to. I think gorhill recognises it's simply
| unfeasible to produce an effective content blocker on MV3,
| and I hope he puts his foot down and doesn't take on the
| maintenance burden of an additional nerfed browser extension.
|
| If web devs want to make web experiences worse in Firefox by
| issuing warnings everywhere, then Firefox can even the score
| by having a useable ad-free experience.
| zwaps wrote:
| Nothing, but it won't work anymore on Chrome in a short while.
| titaniczero wrote:
| Does anyone know what is Edge's take on MV3? Will they just leave
| it untouched and obey or do they have alternative paths planned
| for adblockling like Brave (In addition to the native blocker,
| Brendan Eich also said that they will "put back the lost
| functionality for uBO, uMatrix and other legit extensions" [1]).
|
| I have a feeling that Edge will become mainstream in the near
| future because it is the default browser on Windows (getting IE
| monopolistic vibes again!) and people is using and even loving
| it. I think both Edge and Chrome will decide the future for the
| web. Firefox and Brave, unfortunately, are not mainstream enough
| to make their decisions count.
|
| [1] https://twitter.com/brendaneich/status/1134141335881912320
| ameshkov wrote:
| As I understand, Edge will also migrate to MV3 completely.
|
| Also, I am not entirely sure other Chromium-based browsers will
| be able to maintain MV2 compatibility in the long run.
| whitewingjek wrote:
| Edge will indeed migrate over to v3:
|
| https://docs.microsoft.com/en-us/microsoft-edge/extensions-c...
| CameronNemo wrote:
| Funny how the only browsers that matter are the ones shipped by
| default by OS vendors... almost like the whole Windows/IE
| antitrust action was for show. Or I guess the OS vendors
| realized being an oligopoly is a good workaround for dated
| antitrust policy.
| akira2501 wrote:
| > antitrust action was for show.
|
| People often forget the US underwent an administrative change
| between the judgement and enforcement. Microsoft spent a lot
| of "think tank" money on influencing the new regimes
| enforcement mentality, not only on their own issue, but on
| monopolies in general.
|
| It was, from my recollection, definitely not for show.
| lapcat wrote:
| One reason people forget is that the Department of Justice
| announced the settlement (wrist slap) with Microsoft
| literally a few days before the 9/11 attacks, and so the
| case was wiped from the news along with everything else
| except 9/11. (I'm not suggesting a conspiracy, just that
| the public never had a chance to be angry about the
| settlement.)
| webmobdev wrote:
| I don't know if it is cartelisation (both Apple and Google have
| an ad division and it is in their interest to work together on
| some aspects of this business) or Google bribed Apple (through
| its ios search engine deal), but Safari webkit also has
| limitations in ad blocking through the content blocking API which
| Apple created for Safari. (See _Explanation of the state of
| uBlock Origin (and other blockers) for Safari #158_ -
| https://github.com/el1t/uBlock-Safari/issues/158?ysclid=l7g3...
| ).
| Terretta wrote:
| Saying they both "have an ad division" is a remarkably
| unbalanced comparison.
|
| Google ads revenue 2021: 209 billion out of 256 billion, 80%
|
| Apple ads revenue 2021: $3.7 billion of 365 billion, 1%
|
| We further need to understand the difference between operating
| an ad exchange:
|
| https://www.eff.org/deeplinks/2020/03/google-says-it-doesnt-...
|
| And allowing first party and purchased ads for products within
| a marketplace the user is already visiting:
|
| https://searchads.apple.com/help/get-started/0001-compare-ap...
|
| They can only be validly compared once this is true of both ad
| services:
|
| > _[Ad service] doesn't buy or share users' personal
| information with other companies. We don't track people by
| linking user or device data collected from [first party] apps
| with user or device data collected from third parties for
| advertising targeting or measurement. And we don't share user
| or device data with data brokers._
|
| https://searchads.apple.com/privacy
|
| Not saying they're "all good", just "least worst".
|
| Scroll down in the second link to see what Apple do gather and
| use for targeting. Unhappily, the user consent more about
| personalization than about aggregation in the first place. Note
| also the missing word "sell" in "doesn't buy or share", perhaps
| they think sell is implied by share, but also perhaps not.
| TrickyRick wrote:
| Ad Guard works great in Safari, I have yet to see ads it
| doesn't block
| ameshkov wrote:
| We did our best with Safari, but believe me, it actually
| works worse than AdGuard in Chrome and Firefox. Safari with
| all its limitations is no better than Chrome with MV3.
| lotsofpulp wrote:
| Is it possible that Apple's implementation uses less power and
| hence conserve battery life? Also, is it possible Apple's
| implementation requires less trust in extension and is more
| private because no browsing information can exit?
|
| It is also possible for the above, and collusion to all
| simultaneously happen, and or Apple advancing their own ad
| business.
| kevingadd wrote:
| Think about it from a mathematical perspective: How much CPU
| time is actually spent evaluating ad blocker rules? It's
| going to be proportional to the number of HTTP requests you
| issue. On a good website the number of requests is in the
| dozens or a hundred tops per page load, on a bad website
| maybe it's in the low thousands. But that's it. Let's say you
| have 300000 rules (I think the actual number tends to be much
| lower than this), worst case even if you brute forced that,
| you're evaluating 300000 regexes maybe a thousand times.
| That'll take some time, but not that much time, because
| modern CPUs are really fast. It's simply implausible that an
| ad blocker could have a significant negative impact on
| battery life unless you wrote it in some sort of forth
| interpreter that was checking strings one byte at a time -
| compared to the rule evaluations happening once per request,
| you're rasterizing frames ~60 times a second and handling
| input events and timers and all of that stuff constantly.
|
| If you optimize the rules engine - which you can definitely
| do - you can skip evaluating most of those regexes, you can
| evaluate them in parallel, etc. You could start preparing the
| request and only gate the actual tcp packets on approval from
| the ad blocker. You could cache the approve/deny state for
| each URL so that the ad blocker overhead is only paid on
| first visit to a site. There are lots of ways to make this
| stuff super fast without breaking it, but Google and Apple
| don't want to do the work.
|
| People like the uBlock Origin author have already
| demonstrated in the past that their ad blockers are fast
| despite the severe limitations of current browser extension
| APIs. If browser vendors actually supported extension
| developers ad blockers could probably become _faster_.
| Instead they 're attacking them and forcing people to move
| over to intentionally sabotaged APIs with limited feature
| sets and arguing that now things will be "faster" even though
| you're going to be wasting resources downloading a bunch of
| ads.
| webmobdev wrote:
| Sure. The content blocking API is more secure as it doesn't
| allow any code by the extension to run and modify a web page.
| And so logically sounds like it should use less cpu / power.
| It is also true that it is a much, much _inferior_ ad-
| blocking solution. If a feature is popular, it doesn 't make
| sense to remove it. Instead, you can choose to make it opt-
| in. That both Apple and Chrome haven't opted for that speaks
| for itself - it is clear that they are prioritising crippling
| adblockers than letting users control what code run on their
| browser.
| Shank wrote:
| > Is it possible that Apple's implementation uses less power
| and hence conserve battery life?
|
| On WebKit, you can still use WebRequest to intercept and log
| all traffic, you just can't block it. I don't think that
| intercepting/recording all traffic and selectively blocking
| it would have a meaningful difference compared to just
| intercepting it all and letting it through.
| the_gipsy wrote:
| It won't be lower battery if ads slip through (they do).
|
| It won't be more private if ads slip through, or if the whole
| web experience is degraded and users prefer native apps.
| dmos62 wrote:
| Using an ad-company's browser has always been so fishy.
| kurupt213 wrote:
| It seems like Google has been at least as anticompetitive as MS
| and IE
| Havoc wrote:
| Firefox seems pretty much on par with chrome these days and FF
| seems to win out on detection rates anyway so not sure why I'd
| want this combo?
|
| https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...
|
| Does anyone has stats of adguard vs ublock by chance?
| jacooper wrote:
| Firefox on android is horrible. Full of bugs and slow downs.
| cypress66 wrote:
| Also it has a non native scroll behavior that is awful and a
| deal breaker to me.
| LarryDarrell wrote:
| I use it with uBlock on a $250 "budget" Android phone and
| it's as fast as Chrome. The last time I remember Firefox
| being slow on Android was when I was running it on a ZTE
| phone running FirefoxOS.
|
| The only bugs I find belong to websites, which I don't count
| against Firefox. I used to have to support IE8... if the site
| broke it was my responsibility, not the browser.
| webstrand wrote:
| I use it exclusively, I'm quite happy with it personally. I
| do wish they allowed more than just a few specific extensions
| to work, though.
| yibers wrote:
| I use Firefox on Android with uBlock origin for blocking ads
| and kagi for search. This Google (albeit Android is Google)
| free browsing works extremely well for me.
| Melatonic wrote:
| How recently have you used it? It works great for me
| daveidol wrote:
| uBlock origin is far better, especially compared to this
| Manifest v3 version of AdGuard.
|
| AdGuard are just doing this to capture the upcoming hole in the
| market as uBlock Origin stops working in Chrome.
|
| Everyone should switch to Firefox.
| vehemenz wrote:
| This is pure anecdote and not apples and oranges, but I've
| found the ad-blocking experience with Safari/Adguard
| comparable to Firefox/uBO.
| vbezhenar wrote:
| Are we going to lose ublock origin on chrome when v2 will be
| disabled?
| drexlspivey wrote:
| World's biggest ad company getting rid of ad-blockers, who
| could see that coming?
|
| > Chromium got its webRequest API at a time it was trying to
| gain market share against Firefox (Sep 2011), where Adblock
| Plus, Ghostery, Disconnect, NoScript, and other such extensions
| were the most or among the most popular extensions on Firefox.
|
| So the only reason they even implemented this browser standard
| was to gain market share and now that they are in the dominant
| position they yank it, getting rid of ad blockers. Straight out
| of the Microsoft playbook.
| Ygg2 wrote:
| Ah, the extinguish phase, of EEE.
| pessimizer wrote:
| Firefox did them a favor by trashing the extension
| ecosystem that had put the pressure on Google in the first
| place.
| notriddle wrote:
| https://cdn.fosstodon.org/media_attachments/files/108/556
| /56...
| Ygg2 wrote:
| Firefox did it because of security/performance concerns.
| Being able to customize UI doesn't lend itself to easy
| refactoring.
|
| In order to compete with Chrome most of XUL extensions
| had to go.
|
| Hyrum's law in practice.
| encryptluks2 wrote:
| > Firefox did it because of security/performance concerns
|
| Isn't that the same concerns used in pushing Mv3?
| Ygg2 wrote:
| XUL was a legacy system and it was blocking many
| optimization/refactors.
|
| Does Mv2 really hold Chrome back?
| hoffs wrote:
| Have you not read the article before posting the comment? Ad
| blocking is nowhere near being killed
| bogomipz wrote:
| Interesting, so the WebRequest API has its origins at
| Mozilla? I remember discovering all those wonderful plugins
| at the time via Firefox but I didn't understand that was the
| enabler.
| akaike wrote:
| Unless they port it to v3, yes, it won't work anymore.
| slimypi wrote:
| Jeeezuuuss! that will hurt, a lot.
| jnsaff2 wrote:
| Firefox is not that bad. Honestly the multi-account
| containers alone merits the switch.
| MaKey wrote:
| I agree, this is a really useful feature.
| bambax wrote:
| It's excellent! I've been using it for three years now
| with zero problem.
| EbNar wrote:
| XorNot wrote:
| I don't get where "not that bad" is coming from with
| Firefox these days. Firefox is just plain good, and has
| been for a while.
| taspeotis wrote:
| I think Firefox is an important alternative to
| WebKit/Blink-based browsers.
|
| But as a web developer I semi-regularly butt up against
| bugs in it that have languished in Bugzilla since like,
| 2014, with absolutely no progress on them.
|
| I have dealt with two (maybe three?) bugs in Chrome ever
| and one of them was a pretty clear fuckup they rolled
| back within days.
| emn13 wrote:
| I've dealt with many nasty rendering bugs in chromium
| that were never addressed, from weirdness that just made
| rendering a bit ugly, to spec-incompliant layout (that
| also differed from other engines), to iframe-related
| stuff that left half of the frame completely white, to
| animation/transition related gotchas, to outright
| renderer crashes, including some that brought down the
| chromium wrapper process (which may have been security
| risks, but figuring that out isn't easy). And ditto for
| firefox. This is years ago by now, but my impression
| isn't that chromium doesn't have bugs nor that it fixes
| bugs promptly, but rather that all websites and web-
| toolkits necessarily are designed with chromium
| limitations in mind. That's certainly what I did - no
| point in releasing anything that doesn't work on
| chromium; that'll just get you laughed at and ignored.
|
| The chromium bugtracker too is full of ancient unresolved
| bugs, just like gecko's bugzilla:
| https://bugs.chromium.org/p/chromium/issues/list?sort=id,
| and I'm sure that if you wanted to you could find a ton
| of decade old bugs that leave you wondering how those
| weren't fixed by now.
|
| This just seems to be a fact of life with various browser
| engines. There are surely all kinds of more or less
| reasonable motivations to ignore those old bugs, but
| whatever the cause it's certainly the status quo.
| koenvdb wrote:
| From my experience, almost every website doesn't feel as
| nice in Firefox as it does in Chrome. Ofcourse some of
| those sites are maintained by Google (YouTube).
| wccrawford wrote:
| And some things don't even work. For instance, my dentist
| had a sign "rate us here on google" with a QR code. That
| code didn't work on my phone. I eventually figured out
| that it works fine in _Chrome_ , but doesn't work in
| Firefox. In fact, there's no way to rate businesses on
| Google.com from Firefox on my phone. The links just
| aren't there, and going directly gives a 404.
|
| Everything works fine on Chrome.
|
| That's obviously done maliciously by Google, of course.
| tomxor wrote:
| Chrome/chromium based, is worse than IE in this regard -
| because of Google specifically, we've moved from "viewed
| best in" to "only works in".
| Karunamon wrote:
| I don't trust Mozilla. They continually make changes
| against the interests of the computer literate, they
| continually screw with the UI, they continually take
| control away from the user, they are literally in
| Google's pocket, and their own attempts at fundraising
| put the lie to their claims about privacy.
| cycomanic wrote:
| I don't understand this reasoning. On one hand everyone
| complained that Firefox was to slow to bloated could be
| brought down by extensions etc. and moved to chrome
| because it was faster. Then Firefox implemented changes
| to make it faster, isolate extensions etc. and everyone
| complains that they killed them off and doesn't think of
| the users. Now we have the situation that people say they
| can trust Mozilla, because of these changes, while at the
| same time they stay on chrome.
|
| I have two issues with this, 1. Chrome is so much worse
| in respecting its users, it is completely hypocritical to
| say not to trust Firefox but use chrome. 2. All these
| posts are actually painting the impression that there is
| no valid alternative, in fact that chrome is the less bad
| (freer) choice compared to chrome. This creates exactly
| the narrative that Google wants, that their choices are
| really just minor inconveniences and there is no valid
| alternative to chrome. I mean just in this thread we have
| seen many posts that state that Mozilla is essentially
| doing the same just slower and cant be trusted, despite
| statements and actions to the contrary.
| Karunamon wrote:
| Chrome is not to be trusted; this I agree with. Chromium
| forks on the other hand, like brave or vivaldi, have none
| of these problems. The former has already committed to
| not implementing this garbage restriction on blockers.
| Chromium's engine is solid from a technical standpoint
| and doesn't have any inherent privacy issues aside from
| being owned by Google engineers.
|
| If it sounds like I'm holding Firefox to a higher
| standard, I am. Their own positioning in their own
| marketing is based on a moral stance on privacy and
| "empowering the user". They have demonstrated that this
| stance is held out of marketing convenience rather than
| sincerity.
|
| Chrome is the devil you know, you know it is made by an
| ad company, is filled with tracking, and will always act
| to support that. Firefox is... Not who they make
| themselves out to be. That's almost worse in a way.
| tristan957 wrote:
| You think a crypto company and a closed-source browser
| have your best interests at heart?
|
| You do you.
| aaaaaaaaata wrote:
| https://madaidans-insecurities.github.io/firefox-
| chromium.ht...
| lapinot wrote:
| I use firefox so i don't know much about chrome vs chromium
| politics, but if the chromium people have one thing to do
| now, it would be to maintain manifest v2 in their fork..
| foxhill wrote:
| chromium people are chrome people. google provide
| chromium either as a literal requirement for compliance
| with some other open source licence, or as a vestige from
| the "don't be evil" days.
| tomxor wrote:
| Unless something recently changed, Chromium is considered
| upstream for Google Chrome, not a fork... so you will see
| most engine level changes originate in Chromium, by
| google engineers.
|
| Maybe you are confusing it with de-googled-chromium et
| al?
| lapinot wrote:
| Ah right, now i remember. Yes that would be de-googled-
| chromium then.
| vegai_ wrote:
| Meh, just use Firefox for general browsing and Chrome/ium
| for the one or two things that only work on that.
| cube00 wrote:
| It's shocking that in 2022 there are still sites that (or
| have been forced) to only work in Chrome.
|
| Looking at you Google search results [1] (but I
| understand their motivation), however I do have one local
| company site that refuses to move beyond their loading
| splash in Firefox.
|
| I guess I should be thankful it's no where near as bad as
| the IE6 days where HTML standards were completely
| disrespected in the quest for more market share.
|
| [1]: https://addons.mozilla.org/en-
| US/android/addon/google-search...
| kurupt213 wrote:
| My experience is it's more often proprietary web fronts
| for corporate microservices than WWW pages
|
| If Firefox won't work, edge almost always will. I'm
| really trying not to download chrome again. I forgot
| chromium is an option. Is that not maintained by Google?
| KronisLV wrote:
| User agent spoofing seems like what should be done on the
| user's end in those cases, if it's not possible to avoid
| using such sites for whatever reason.
|
| Problems would begin once we'll eventually get Chrome-
| specific functionality or something that Mozilla won't
| implement due to a variety of concerns, thus simply
| breaking sites: https://mozilla.github.io/standards-
| positions/
|
| Then we'll basically be back in the days of IE, except
| that this time Google will be the ones with the browser
| monopoly, if we're not already there somewhat - the
| majority of folks haven't even heard of Firefox.
| wccrawford wrote:
| Didn't Google say it was going to make Chrome have the
| same generic user agent forever in the future? Seems like
| using that one will be the way to go once that happens.
| dmos62 wrote:
| > Chrome/ium for the one or two things that only work on
| that
|
| Firefox has been my daily driver for close to a decade,
| and I've not run into something that didn't work on it,
| but worked on Chrome.
| vegai_ wrote:
| It's mostly some specialized features, like conferencing
| in Microsoft Teams. Clearly some pieces of web software
| are optimized only against webkit/chrome. But yeah, not
| many things outright refuse to work on Firefox these
| days.
| nerdponx wrote:
| Embrace, extend, extinguish.
| cube00 wrote:
| It's not looking hopeful
| https://github.com/uBlockOrigin/uBlock-issues/issues/338
| bambax wrote:
| One can always block Chrome updates. It would be funny if
| this so-called "security" move resulted in a much worse
| security situation.
| sbarre wrote:
| Until Google's services refuse to work until you upgrade..
|
| So this might work for some (and in that case why not just
| change browsers?) but I wouldn't assume that Google will
| allow this to be a valid and widespread tactic.
| Cthulhu_ wrote:
| Probably, or it'll be nerfed to fuck. I'm sure someone will
| make a fork off Chromium and leave it enabled.
|
| Browser builders, this is your cue: if advertising is not your
| business, offer an ad blocker. Firefox became popular (in my
| personal experience) because it came with a popup blocker by
| default.
| mekster wrote:
| Haven't used adblocker extension for a while. I just have
| AdGuard Home on a VPS to be used with every device on the
| network and do DNS level blocking and all is clean including
| stopping trackers from non browser apps.
| ameshkov wrote:
| DNS-based solutions can't block everything since they're
| limited to blocking domains. But wait until we bring a
| content filtering proxy to AdGuard Home, this will be the day
| when you'll finally get clean pages and you won't need any
| extension at all for that.
| vbezhenar wrote:
| I'm very curious about method to block YouTube ads with dns.
| I didn't find a way when I tried.
| lapcat wrote:
| Manifest v3 is going to be a slaughter. Extension developers have
| known the slaughter was coming, but Chrome users are going to be
| taken by surprise. Many free Chrome extensions aren't going to
| get updated at all for v3, because it's too much work. Many
| aren't going to work right anymore because of the new
| restrictions. And ad blocking aside, v3 seems like a nightmare in
| general, and still quite buggy. The service workers vs.
| background script issue discussed by AdGuard will affect many or
| most extensions.
|
| I've been postponing the migration of my extensions to v3 for as
| long as possible. One extension should be fine, but the other
| one... I'm afraid of what that's going to be like.
| dspillett wrote:
| _> but Chrome users are going to be taken by surprise. Many
| free Chrome extensions aren 't going to get updated at all for
| v3, because it's too much work_
|
| On one of the occasions I flipped from mostly Firefox to mostly
| Chrome/Chromium1 was due to significant changes to add-ons -
| and an add-on that was one of my significant points for
| friction stopping me move over more was one that didn't get
| updated immediately2.
|
| But I think many people will blame the add-ons, and just stick
| around & complain instead of moving away from the source of the
| problem. The many dozens of us who will move, not matter how
| loudly we do so, simply won't be important enough in the grand
| scheme of things for Google to care.
|
| ----
|
| [1] this happens every few years2 as one or the other irritates
| me in various ways
|
| [2] I'm currently long overdue a move towards Firefox, maybe V3
| will be the final push this time around
|
| [3] in fact, for some time IIRC, by the time a new version
| appeared I no longer needed it
| shadowgovt wrote:
| NGL, I did find MV3 harder to implement against. Not because of
| the declarative model alone, but because the declarative
| model's rules are under-documented.
|
| Can you replace an image URL fetched remotely with an image
| stored in the extension itself (via rewriting the URL from a
| remote fetch to a file fetch)? Maybe? No, because redirection
| from remote URLs to file URLs trips the resource fetch security
| model independent of anything else, except a developer has no
| reason to believe that security model applies also to
| extensions?
|
| Testing against the declarative model feels very wild west and
| since it isn't just JavaScript, I can't just slap the debugger
| on it and introspect all the data going back and forth.
| ameshkov wrote:
| > The service workers vs. background script issue discussed by
| AdGuard will affect many or most extensions.
|
| This is so true. It is often overlooked, but the root problem
| of Manifest V3 is not declarativeNetRequest, but this service
| worker move.
|
| Firefox and Safari implemented an alternative to them so
| there's a chance.
|
| Google proposed a different solution (called "Offscreen
| documents") which is also not too bad, but I doubt they'll
| implement it by the January deadline.
| Broge wrote:
| What do service workers restrict as compared to the previous
| model?
| ameshkov wrote:
| The main issue is that their lifetime is limited and
| they're getting constantly killed. This happens all the
| time even when the service worker is being actively used.
| shadowgovt wrote:
| This is by design. The downside to background pages is
| they consumed an entire page's worth of runtime resources
| (and depending on how they're set up, they may do that
| per foreground tab).
|
| It's a headache early-era iOS developers are familiar
| with, but this move is basically Chrome team saying
| "We've watched the community try to implement responsible
| resource handling, and they suck at it, so we're taking
| some of their choices away so that the browser can manage
| resources for the user." Because battery matters.
| ameshkov wrote:
| This question was discussed so many times in W3C group.
|
| Mostly this boils down to one thing: there needs to be an
| alternative to service workers and there are tons of
| legitimate use cases for long-living background pages or
| workers. I think by this point everyone agrees on that,
| the question is when this alternative will be made
| available to developers. It's only 3 months until the
| deadline after all.
| skizm wrote:
| These extension changes aren't coming to Firefox, right? So uBO
| on Firefox is still the best desktop browser adblocker at the
| moment, right?
| daveidol wrote:
| Correct. Firefox is going to support Manifest V3 but with the
| old content blocking APIs from V2 still intact.
| bambax wrote:
| > _By releasing an extension built with Manifest V3 today --
| first among developers of ad blockers - we can say that we 've
| met the challenge that Google posed to us._
|
| They shouldn't do this IMHO.
|
| Manifest V3 is a horrible attempt to kill adblocking (under the
| banner of "security", as always). But, the web is completely
| unusable without adblocking.
|
| If there are no more (effective) adblockers for Chrome, users
| will frantically begin to search for an alternative; there are
| many: Firefox and Brave to mention just two.
|
| Giving a boost to alternative browsers can only be a good thing;
| and it may also, eventually, make Google rethink this policy.
| thrdbndndn wrote:
| > Manifest V3 is a horrible attempt to kill adblocking
|
| I really don't understand the push of MV3.
|
| I don't believe they're just for security as Google claimed but
| at the same time I feel thinking it's "just" to ruin ad
| blocking is equally baffling. Could someone who is more
| involved elaborate the nuance of (intent of) MV3?
| JoshTriplett wrote:
| I've talked to a number of real engineers within Google. The
| folks building the browser have no desire to kill adblocking;
| they're never going to include _first-party_ adblocking (not
| least of which because antitrust), but they 're not out to
| break third-party adblockers.
|
| It really is the case that the _same_ mechanisms that enable
| adblockers ( "this extension may affect your traffic on every
| website") are also the mechanisms that enable malware in
| extensions, which are not at all rare.
| 8note wrote:
| Do the engineers actually control that decision?
| RunSet wrote:
| > I've talked to a number of real engineers within Google.
| The folks building the browser have no desire to kill
| adblocking
|
| Have you also consulted the actual decision-makers at the
| world's largest advertising corporation who sign those real
| engineers' paychecks?
| encryptluks2 wrote:
| Have you combed the bug tracker or submitted reasonable
| PRs and have proof that the decision makers are
| gatekeeping an open source project from implementing
| something that is clearly a better alternative?
| ocdtrekkie wrote:
| The solution here though is simple: As the sole publishing
| source of extensions users can install on Chrome, Google
| just needs to stop distributing malware from their
| extension store!
|
| But of course, that would require Google actually take some
| responsibility and do some legwork and neither of those
| things are in their core competency.
|
| If Google actually had any goals of improving security,
| they'd literally just delete the Chrome Web Store and start
| over and manually reviewing and approving extensions one by
| one.
| michaelt wrote:
| They manually review and approve Android apps one-by-one.
|
| The results have not garnered much acclaim.
|
| I suppose you could argue they simply haven't budgeted
| enough $$$$ to get skilled reviewers taking enough time
| on each review.
| ocdtrekkie wrote:
| People reviewing the security of browser extensions
| should have the title of "engineer" at minimum.
|
| Bear in mind browser extensions completely defeat all the
| benefits of HTTPS. If we aren't putting them through
| significant scrutiny there really is no reason for anyone
| at Google to claim to work on security at all. Extensions
| need to be treated as incredibly privileged code and
| vetted accordingly.
| JoshTriplett wrote:
| If Google did that, there'd be widespread cries of
| "gatekeeping!". Mozilla was blasted for doing exactly the
| same thing.
| ocdtrekkie wrote:
| Here's the problem with that apologism: They already are
| gatekeeping. They made that call as soon as they removed
| sideloading extensions. The problem is Google is just a
| _shoddy gatekeeper_.
| blibble wrote:
| have you heard of "plausible deniability"?
|
| I very much doubt the upper management is stupid enough to
| tell the grunts that they're doing this to kill off
| adblockers
|
| they know there will be intense regulatory scrutiny on this
| at some point in the future
|
| the true factors that went into this decision will have
| been discussed verbally and in-person only
| gostsamo wrote:
| Google sells ads. They totally want to kill adblocking with
| all means necessary. The moment they can no longer show
| increasing revenue, the stock will fall down to the levels
| expected from utilities from the levels that tech companies
| are valued at.
| somehnacct3757 wrote:
| MV2 extensions have a lot of API power and it was a common
| malware vector in the browser since the APIs let you sidestep
| a ton of regular web security. If you run a popular extension
| you will get offers to buy the extension which is a nice
| payday. The buyers would then stuff it full of malware to
| infect the existing users.
|
| Google makes no money off the Chrome Web Store and their
| initial attempts to restrict MV2 failed. The goal was for
| automated approval to suffice. Still, there was certain APIs
| that required human review.
|
| Google could have continued restricting MV2 until they didn't
| need human review but they must have got the idea for MV3 at
| that point. They could also hamstring ad blockers and get
| some promo packet material.
| kevin_b_er wrote:
| I recall they also claimed performance benefits at one point.
| staticassertion wrote:
| Isn't it very clearly _not_ killing adblocking given that...
| this adblocker just released a version using it.
| e2le wrote:
| Yet reduced in it's ability to perform it's intended
| function.
| tssva wrote:
| Yet not reduced enough that the maker of the extension
| thinks users will notice any difference in the ability to
| block ads.
| therealmarv wrote:
| Switch to Brave, you will still maintain 99% of the bell and
| whistles of Chrome (because it's a Chrome fork) and you will
| have an Adblock engine directly in the browser core written in
| Rust. How cool is that...
|
| Especially on mobile Brave is a game changer.
|
| https://github.com/brave/adblock-rust
| sascha_sl wrote:
| But also, a whole lot of other things I didn't ask for that
| are hard to entirely opt out of.
| Karunamon wrote:
| Other things such as?
| ryannevius wrote:
| Does Brave have the memory / slowdown issues attributed to
| Chrome on Apple silicone MacBooks?
| therealmarv wrote:
| It's not reengineered for most parts. Core is Chromium with
| all its upsides and downsides.
| BrendanEich wrote:
| Works great on my 14" 2021 MBP. Anyone else? Pointer to
| details of slowdown welcome. Thanks.
| jefftk wrote:
| I would be surprised if they differed here, since it's the
| same core browser.
| unicornporn wrote:
| Does Chrome have bells and whistles? I thought they removed
| all of them. Firefox, on the other hand, have a few left...
| alexb_ wrote:
| I despise anything that has touched cryptocurrency, which is
| why I don't like Brave.
| dreen wrote:
| I've been using Brave for years and still have no idea what
| their crypto angle is, because I didn't want or have to
| find out.
| schleck8 wrote:
| Have you not updated? Brave's crypto nonsense is super
| aggressive nowadays with a wallet builtin, decentralized
| domain resolving, ads for crypto exchanges on the start
| page, paid crypto background images and their own
| currency BAT.
|
| The browser is getting more bloated by the year, they've
| added some Brave News service now and integrated their
| paid VPN with their browser instead of making it a
| separate product like Mozilla VPN
|
| And obviously they started using affiliate marketing,
| parasite behaviour.
| therealmarv wrote:
| It's all opt-in. Brave is self sustainable for opt-in
| privacy respecting ads and crypto is a way for making users
| opt-in and getting paid. Compare that with Firefox which
| does not have a real sustainable business model and relying
| on Google or other sponsors.
| sfvegandude wrote:
| schleck8 wrote:
| Everything but their crypto is opt out
|
| - Wallet = has to be removed from the toolbar manually
|
| - Crypto background ads = has to be deactivated
|
| - Crypto Exchange ads = has to be deactivated
|
| - Decentralized domain resolving = has to be deactivated
|
| - BAT = Not enabled by default but has to be removed from
| the toolbar manually
| BrendanEich wrote:
| Having to turn off "opt-in" UX widgets is not "out-out".
| "Opt-out" would mean you had to turn off the feature that
| was on by default, not remove the button or other
| affordance to turn it on when it is off by default.
|
| I get your complaint, you want nothing visible to do with
| our opt-in, off by default crypto stuff. But calling that
| stuff "out-out" is misusing the phrase. It's off by
| default.
|
| The New Tab Page sponsored images are non-tracking and
| not crypto related unless you opt into rewards, so I
| wouldn't lump them in here. Turn off in slider-widget
| control at bottom of NTP.
| yjftsjthsd-h wrote:
| I already have to go through and rip out all the ads that
| Firefox has and the pocket integration on the toolbar, so
| this doesn't look all that different to me.
| tssva wrote:
| I have no idea what they have been up to lately but when
| originally rolled out Brave's business model seemed very
| much like a protection racket. I haven't touched it since
| and never will.
| BrendanEich wrote:
| We don't take fees to unblock ads, so you must mean the
| "acceptable ads" extensions and not Brave.
| Dalewyn wrote:
| >there are many: Firefox and Brave to mention just two.
|
| So just Firefox and then all the Chromes?
|
| There really aren't "many" alternatives, there isn't even /an/
| alternative because Firefox suffers from Mozilla
| Misguidance(tm).
|
| Presumably the same people who bitched about the IE6 monopoly
| brought on and fully embraced the Chrome monopoly. We now all
| get to sleep in the Chrome bed.
| ThunderSizzle wrote:
| I was all for Firefox until Mozilla decided cancel culture
| was the way to go back when they canceled their CEO. It
| became even worse since - calling for the de-platforming of
| half the country.
|
| I know Google hates the same user group, but Google also
| likes their money (or their money-value).
|
| Go woke, go broke. If your trying to compete uphill, shooting
| yourself in the foot isn't going to make it any easier.
| brightball wrote:
| It's got me thinking about selling my Google stock. A move like
| this feels a little bit desperate.
| freediver wrote:
| > If there are no more (effective) adblockers for Chrome, users
| will frantically begin to search for an alternative
|
| More likelier scenario: Most Chrome users do not even know what
| an ad-blocker is, let alone difference between Manifest v3 and
| v2. The franatical run, if one was ever a thing, already
| happened when Google announced V3, long time ago. The few
| people (relatively speaking) that cared about it already
| switched browsers.
| Longhanks wrote:
| I think you overestimate the role adblockers play for regular
| users. Most people not affiliated with IT in any way I've met
| actually don't use an adblocker or have forgotten that they in
| fact do and would not notice the change to Manifest v3.
|
| Also, most people care much more about "it simply works", and
| that is Chrome. Firefox is neither preinstalled nor as
| compatible as Chrome (nor as fast or user friendly). There's
| already a lot of popups like "this site works best in Chrome".
| doliveira wrote:
| Yeah, I went to use my Mom's phone and I was appalled with
| all the ads and notifications. We can disable notifications,
| block intrusive ads or at least figure out which app is
| sending them to uninstall it, but for regular users the whole
| thing is an awful experience. I don't refrain from calling it
| "evil" anymore, because that's what it is. No wonder we're
| collectively going insane.
| unethical_ban wrote:
| I helped my mom try out a smartphone for the first time this
| weekend, and she won't really use the web much on it except
| maybe weather. So I go to weather.com or something to show
| her how she can get to it.
|
| I got a full screen cookie consent popup, a location
| permission popup, and ads were everywhere on the screen. Must
| have been 50% of screen space for the top part of the page.
| It's absurd!
| kurupt213 wrote:
| Firefox is faster than chrome and only doesn't work on badly
| built pages and webapps (like intelex)
| soraminazuki wrote:
| > Firefox is neither preinstalled nor as compatible as Chrome
| (nor as fast or user friendly)
|
| Compatible against what? The web standards or Google Chrome?
| edflsafoiewq wrote:
| Compatibility against real world websites is the thing that
| actually matters. Firefox does fine for me though.
| hgsgm wrote:
| prmoustache wrote:
| and regardless of their respective performance
| differences, a firefox with an ad blocker is faster than
| a chrome without one.
| nottorp wrote:
| I tend to skip sites that don't work in Firefox + Ublock
| Origin.
|
| Unless someone pays me to open them (read: I need them to
| do work), then I do keep an instance of Chrome around.
| But only if there is no other choice.
| thejosh wrote:
| It's actually ridiculous to surf the web without an
| adblocker.
|
| Let's say you have a brand new computer, and want to download
| nVidia drivers. Fire up your brand new computer, search for
| "nvidia drivers" using Bing.... and the first results are all
| ads for extremely scummy adware. (It's also hilarious when
| you search for "chrome download" when Edge begs you not to,
| and including when you click through, but that's a story for
| another time :)).
| teh_klev wrote:
| > It's actually ridiculous to surf the web without an
| adblocker.
|
| Obviously for this audience. But two of my buddies didn't
| even know such things existed and were truly grateful when
| I introduced uBO/Privacy Badger to them.
| Multicomp wrote:
| > nor as compatible as Chrome (nor as fast or user friendly).
| There's already a lot of popups like "this site works best in
| Chrome".
|
| User-agent sniffing[1] and it is a webdev smell. I
| acknowledge that this is true, but I admit being bummed that
| we didn't win the war to use web standards.
|
| [1] https://en.wikipedia.org/wiki/Browser_sniffing
| Multicomp wrote:
| Firefox is building MV3 and while they are coy with deprecating
| MV2, we all know, c'mon, they won't keep MV2 even a day after
| their minimum year promised.
|
| Their track record speaks against them.
|
| XPCOM extensions? Killed, but don't worry, we will re-implement
| all the needed APIs as WebExtensions (didn't happen).
|
| Fennec to Fenix mobile extensions? Killed, you get these 10
| blessed ones, don't worry, we will eventually re-enable all of
| the webextensions on mobile, any day now, (didn't happen, you
| have to do hacky hacks involving nightly version to do un-
| blessed extensions).
|
| This will likely be their third strike.
|
| UPDATE: Or it's not nearly as bad as I expected. Per [1], while
| Firefox will be eventually deprecating MV2, the Firefox MV3 is
| much less 'evil' than the Chrome MV3, in that Firefox will
| continue to enable the WebRequest API without all the lock-down
| restrictions.
|
| This makes a competitive advantage for Firefox in terms of
| adblocking power, if anything.
|
| [1] https://news.ycombinator.com/item?id=32648925
| soulofmischief wrote:
| Now that uMatrix development is inactive, this third strike
| could be their last for me.
| Dwedit wrote:
| UMatrix is not only out of development, it is also broken
| on current Firefox. Sometimes you randomly lose session
| cookies, which is not acceptable.
| syrgian wrote:
| Thanks for the summary. I had perceived the betrayal but I
| had never organized the thoughts nor verified the claims.
|
| What do you think is the future (+2 years) for people with
| hatred for ads? For now I am using Firefox on computer + Kiwi
| in Android, but I also expect those two to go awry in the mid
| term.
|
| * I see that after the edit, it doesn't look as bleak for
| Firefox PC. But what about Android?
| CorrectHorseBat wrote:
| Which add-ons are you missing from Firefox for Android?
| prmoustache wrote:
| The one I am missing the most is the multicontainer addon
| Multicomp wrote:
| SingleFile
|
| Old Reddit Redirect
|
| User Agent Switcher
|
| Click to find out what HN says (heh)
|
| Fakespot
|
| Absolute Enable Force Right Click and copy
|
| Page Screenshot
|
| SponsorBlock
| cycomanic wrote:
| Don't these run on Firefox nightly on android? You need
| to change some advanced settings, but according to [1]
| they should work.
|
| [1] https://blog.mozilla.org/addons/2020/09/29/expanded-
| extensio...
| JeremyNT wrote:
| Parent asked about Firefox for Android. This
| functionality you mention is only available in Firefox
| Nightly, and even then it requires setting up a curated
| list on Mozilla's service to use it.
| cycomanic wrote:
| What's wrong with running Firefox nightly on android?
| I've been running it as my main browser for quite a while
| and have hardly experienced any breakage (maybe 2 or 3
| times in the last 3 years).
| Snuupy wrote:
| https://news.ycombinator.com/item?id=32649895
| Multicomp wrote:
| For Android, I don't have a great answer for you. In theory
| you can install Fennec on F-Droid, version 57, the last
| version the last version of Firefox built by F-Droid that
| was based on the Fennec browser engine, but that has
| security vuln potential, increasingly so since its been a
| few years since Fennec -> Fenix switch.
|
| For now, because I don't want to be hit by security vulns
| in the browser itself, I'm holding my nose and doing plain
| old Firefox mobile, leaving some of the tracking stuff
| blocked on my Pi-Hole, then letting my wireguard VPN ensure
| that even when I'm off Wi-Fi, my signal gets routed to my
| home connection so the Pi-Hole can stop some of the
| telemetry (but not all! some gets through no doubt).
|
| Why am I holding my nose there? Because my planned next
| browser, Iceraven [1], is not yet out of alpha and
| published to F-Droid. I check every 3 months or so, once it
| is, that's where I'm going, because it's as close as I can
| get to Firefox Desktop, but runs on Android.
|
| [1] https://github.com/fork-maintainers/iceraven-browser
| marcolussetti wrote:
| Firefox Nightly for Android supports most desktop
| extensions. It is clunky to enable them (you have to
| create a collection and then subscribe to it) and being a
| nightly build it does have some instability, but it works
| out pretty well.
|
| Only caveat I've really found is that it gets stuck on
| the Guardian's website (after a few clicks).
| niij wrote:
| The latest Firefox for Android (104.1.0) has a limited
| set of add-ons available. One of those is uBlock Origin.
| Works out of the box.
| prmoustache wrote:
| fennec is up to date on f-droid, currently version
| 104.something
| groovybits wrote:
| > What do you think is the future (+2 years) for people
| with hatred for ads?
|
| DNS-based blocking
| aqfamnzc wrote:
| Until DoH becomes standard/required?
| resoluteteeth wrote:
| > DNS-based blocking
|
| Google cracks down on VPN based adblockers
| https://news.ycombinator.com/item?id=32636412
| pdappollonio wrote:
| DNS based ad blocking is slightly different than VPN
| based blocking. VPN is there for people running
| environments where DoH is not yet supported.
|
| Newer versions of iOS, Android and Windows support it
| already.
| Multicomp wrote:
| I don't know. I'm using it now in the form of pihole, but
| DoT/DoH with ESNI are coming, and we don't have a good
| way to ID and block them by their very nature, which is
| the bad edge of the double-edged sword that they enable.
|
| The good edge is keeping ISPs etc. from messing with your
| DNS requests, but that sword cuts both ways as it also
| can lock your own home network out.
| chrisweekly wrote:
| I think a hosted browser might be key to solving this.
| Something like Mighty (https://mightyapp.com) if it were
| self-hosted or somehow run by an org you could trust (or
| be run in some verifiably zero-trust way).
| AshamedCaptain wrote:
| I don't understand what is it with DNS-based blocking
| people that they seem to be some of the most annoying
| proselytizers. Anyone remembers the "HOSTS file guy" from
| Slashdot ?
|
| DNS-based blocking is as much a "future-proof" technology
| as "just don't look at the adverts". DNS-based blocking
| is old, easily workaroundable by anyone (just use the
| same domain name for everything, or interchangeable
| domain names, or just don't rely on system DNS), and
| significantly less featureful than even the simplest
| DOM/JS-based blocking (e.g. good luck collapsing ad
| elements from the view, getting Youtube not to play ads,
| etc.).
| [deleted]
| rb666 wrote:
| Firefox will not go awry, read the actual facts in this
| thread.
| staticassertion wrote:
| Just install any adblocker that supports v3.
| Snuupy wrote:
| Hi, try Iceraven on android with a custom extension repo.
| They'll all install but are not guaranteed to work. I have
| most of those extensions working on Iceraven myself.
| bentcorner wrote:
| You can install more extensions if you use Firefox Nightly:
|
| https://blog.mozilla.org/addons/2020/09/29/expanded-
| extensio...
|
| It's not a clean experience and I wouldn't recommend it to
| anyone non-technical but I use this approach and it works
| fine, at least for the extensions I care about. There's
| also the caveat that you're running Firefox Nightly which
| usually is fine but has had big functionality bugs. I'd
| keep another browser installed as backup.
| CameronNemo wrote:
| If Firefox even deprecates WebRequest, LibreWolf will
| probably announce their intention to patch it back in and
| people will switch en masse.
| webmobdev wrote:
| The only thing keeping Firefox alive and relevant is uBlock
| Origin and its ad-blocking features. If Mozilla cripples it
| in any manner, Firefox will die. But I don't have high hopes
| and lost all trust in them when they built a backdoor in
| their browser to run any code through it on their users
| browser, as they please, and have even used it to violate
| their users privacy and trust - _Mozilla ships Cliqz
| experiment in Germany for ~1% of new installs, collects surf
| data, including URLs_ - https://old.reddit.com/r/firefox/comm
| ents/74n0b2/mozilla_shi... ...
|
| Unless Firefox is released from the clutches of Mozilla,
| Firefox will never be a serious competitor in the browser
| wars.
| gnomewascool wrote:
| I also was and still am disappointed about both changes, but
| I don't think you're being at all fair to Mozilla.
|
| In both transitions, Mozilla made sure to support the needs
| of both uBlock origin and NoScript, extending the
| webextension API (such that uBlock origin on Firefox is more
| capable than on current Chromium) and working with uBlock to
| make its interface more mobile-friendly.
|
| They also extended the webextension API to allow for
| extensions such as Treestyle tabs and Panorama-
| reimplementations (so not remotely all XUL use-cases, but
| still most of the popular ones).
|
| Hence, they've proven that they will go considerably beyond
| what Google/Chromium are doing, and that they won't harm
| "content-blockers", which is what we care about in this case.
| chrismorgan wrote:
| I'd say fairness also requires mentioning how the browser
| has been able to improve because of killing off XUL
| extensions; technologically, they _were_ holding things
| back. Firefox is considerably faster than would have been
| possible without breaking a great many XUL extensions
| anyway. And more secure, if you care about that kind of
| thing, which normal people probably do or should, but
| frankly it's the performance I care more about. So this is
| a "yeah, it's a pity, but there _were_ good reasons and you
| _have_ benefited from it, even as you suffered" kind of
| thing.
|
| Also how much more reliable long-term extension/browser
| compatibility has improved: I've used Firefox Nightly as my
| daily driver for about ten of the last twelve years, and
| until 2017 I'd spot at least one or two breakages each
| year, mostly fairly minor, but the occasional major (a
| couple of which accounted for maybe six months of going
| back to stable--and the lead-up to the killing of XUL
| extensions was another few months on stable because not all
| that I wanted was ready on WebExtensions yet). The
| extensions were typically patched before the change hit
| stable Firefox, so normal users wouldn't notice most. But
| since WebExtensions, I don't recall a single breakage. I
| acknowledge that the _biggest_ breakages were in
| functionality that cannot be replicated any more, like
| Pentadactyl (and I ended up not even trying to replace it),
| but still, the minor and subtle breakages are just gone.
| cycomanic wrote:
| Regarding pentadactyl, I'm using tridactyl on Firefox and
| essentially for all my use cases it behaves the same as
| pentadactyl. I realise that some of the advanced
| functionality of pentadactyl is not available (IIRC
| pentadactyl allowed you to essentially reprogram the
| browser), but I have to say I'm not really missing much.
| Fnoord wrote:
| There's also Vimium for Firefox called vimium-ff. I don't
| know which one's better, I just use vimium-ff.
| bovine3dom wrote:
| For what it's worth, manifest V3 could effect Tridactyl
| as it could block code that is evaluated at runtime from
| accessing the browser APIs.
|
| It will make it less programmable by the end user.
| babypuncher wrote:
| I think people forget how slow and buggy Firefox used to
| be. There is a reason that Chrome took off like a rocket
| in the early '10s.
| chrismorgan wrote:
| In most areas (though certainly not all), the difference
| was generally ironed out well before the advent of
| WebExtensions--what's come since then has been as often
| _surpassing_ as catching up.
|
| Chrome was definitely a wake-up call, and the Firefox 4
| cycle in 2010 achieved a _lot_. I recall doing audio
| stuff with the new Audio Data API (sadly since
| discontinued in favour of the much-more-complex-
| generally-for-no-good-reason Web Audio API) with a sine
| waves stress test (adding random sine waves together
| until underrun occurs) in Nightly, and watching the
| number it could cope with increase, week after week, due
| to JIT engine improvements. It went from handling a dozen
| to handling a couple of hundred over the course of two or
| three months.
| Multicomp wrote:
| > I don't think you're being at all fair to Mozilla
|
| > In both transitions, Mozilla made sure [to keep top
| popular addons mostly happy and ensure adblockers are
| happy]
|
| Those are all fair points, and yes, I was probably too
| harsh with my language overall, that post written before I
| was corrected that Mozilla was not developing MV3 the same
| as Google was.
|
| I stand by my strikes that Mozilla did kill XPCOM, and
| failed to deliver their promise to release all addons to
| Fenix on shipping stable versions. They don't even enable
| about:config on stable Fenix to enable power users to
| workaround that limitation.
|
| In short, I believe I was 60% fair in my opinion.
| tialaramex wrote:
| "Mozilla did kill XPCOM" isn't a deviation from their
| stated intent. XPCOM was a magnet for Hyrum's Law
| problems, because obviously XPCOM plugins are going to
| depend on the inner workings of the browser, that's just
| how XPCOM is designed - so now if you touch these
| internals it breaks third party stuff. There were
| operating systems which took the approach XPCOM has to
| extensibility, they're not doing so great: Classic Mac
| OS, the Amiga Workbench, MS DOS... That's just not a
| sustainable situation, Mozilla _had_ to kill XPCOM.
|
| So to the extent Mozilla failed to deliver here it's on
| the replacement APIs. But how much is enough?
|
| I would like lots of things to have APIs that don't. For
| example I'd like a way to do some basic queries on the
| built-in Public Suffix List for Firefox instead of
| needing to either bake the PSL into each plugin (and keep
| it up to date) or call out to a web API (ugh) or just
| guess that TLDs are "enough" and make everybody who needs
| other suffixes mad.
|
| But in that particular case there are two reasons we
| don't have such APIs. #1 Nobody did the work. I didn't do
| the work, you didn't do the work, the work didn't get
| done. #2 In many cases (I think not mine but it's always
| arguable) the PSL is the Wrong Thing(tm) and so
| encouraging more use of the PSL makes things worse.
| gnomewascool wrote:
| > There were operating systems which took the approach
| XPCOM has to extensibility, they're not doing so great
|
| The Emacs OS is still doing well! :)
|
| > "Mozilla did kill XPCOM" isn't a deviation from their
| stated intent.
|
| The issue is that their stated intent changed over time,
| and their communication about their precise intentions
| was often pretty poor.
|
| It didn't help that the Webextension transition came on
| the heels of the e10s transition (5 firefox versions
| separated deprecating non-e10s add-ons and disabling e10s
| add-ons), but with relatively little warning, which meant
| that:
|
| 1. Many people implicitly believed that once they adapted
| their addons for e10s, they'd be safe.
|
| 2. Many people put in a huge amount of work to adapt for
| e10s and then had to redo a large part of it to convert
| their add-on into a webextension.
|
| 3. Some people put in a huge amount of work to adapt for
| e10s and found out that their work was pointless because
| their add-ons couldn't be converted into webextensions.
|
| From a technical point of view, much of Firefox's
| XPCOM/internals were actually sufficiently stable post-
| webextension (57) that old e10s extensions _could_ have
| continued to work with little changes. (e.g. VimFx
| continued to work with minimal changes for ~30 Firefox
| versions, on Nightly, with very slight hacking. AFAICT it
| still continues to work, with slight changes, but now
| with major hacking to get it to actually install.)
| thrdbndndn wrote:
| >how much is enough
|
| They used to have an official goal like "supporting top X
| addons' transitions", so it's not so random about which
| API they needed to add.
| thrdbndndn wrote:
| When the transition from XPCOM to WebExt started, Mozilla
| made some big promises about the functionality parity about
| the two but failed to deliver most of them (and silently
| removed such promises from their official pages, and left
| relevant Bugzilla tickets rot (e.g.
| https://bugzilla.mozilla.org/show_bug.cgi?id=1427928 )).
|
| IMHO, practically speaking, the final result of WebExt
| isn't that bad, especially taking into consideration of the
| added APIs you mentioned.
|
| It is the shear difference bwtween promise and reality that
| really hurts lots of power users and addon developers to
| this day.
|
| Also you mentioned Treestyle as "most of the popular ones",
| but left out the elephant in the room, Tab Mix Plus, which
| even has its own Bugzilla ticket:
| https://bugzilla.mozilla.org/show_bug.cgi?id=1226546
| Gesture extensions nowadays are also pretty limited
| compared to its heyday due to the nature of WebExt.
|
| In hindsight, these promises were just too good to be true,
| but people were believing.
|
| And the story of extension support on Firefox on Android is
| way too similar to the last time in the Fennec to Fenix
| transition. At least this time, users just didn't have much
| faith in it to begin with.
| wasmitnetzen wrote:
| > Fennec to Fenix mobile extensions? Killed, you get these 10
| blessed ones, don't worry, we will eventually re-enable all
| of the webextensions on mobile, any day now
|
| I harbor the (conspiracy?) theory is that Google told Mozilla
| based on their "No arbitrary code"-rule that they are not
| allowed to run arbitrary extensions anymore. And made Mozilla
| promise to never tell anyone.
| svnpenn wrote:
| > Fennec to Fenix mobile extensions? Killed, you get these 10
| blessed ones, don't worry, we will eventually re-enable all
| of the webextensions on mobile, any day now, (didn't happen,
| you have to do hacky hacks involving nightly version to do
| un-blessed extensions).
|
| Yep:
|
| https://github.com/mozilla-mobile/fenix/issues/20647
| lapcat wrote:
| > They shouldn't do this IMHO.
|
| AdGuard is a business, and Chrome is the world's most popular
| web browser. They don't have much of a choice. uBlock Origin
| can pass because it's not a business.
| tgv wrote:
| Of course they can do this. They don't _want_ to do it. How
| else would they push ads through their ad blocker?
| hgsgm wrote:
| Terretta wrote:
| Unlike some ad blockers, AdGuard's business model, while
| for profit, doesn't include taking money to let ads
| through, contrary to, say, AdBlock Plus or Ghostery.
|
| AdGuard does have an option for users to allow inline
| search results ads and sites' "self promotion" ads. More
| here:
|
| https://kb.adguard.com/en/general/search-ads-and-self-
| promot...
| babypuncher wrote:
| Are there any reliable stats on what percentage of internet
| users use an ad blocker? I've always felt that we are mostly a
| vocal minority, and as such I don't see this move making a huge
| dent in Chrome's market share.
| [deleted]
| monkeynotes wrote:
| Being that Brave and numerous other browsers are built on
| Chrome, does that mean they will also have this limitation?
| judge2020 wrote:
| Brave has their own built-in adblocker so I don't see them
| putting any effort into keeping Mv3 around after it's
| actually removed from Chromium.
| BrendanEich wrote:
| You mean MV2. I've said we'll keep support uBO and uMatrix
| uses of it, at least. This means we'd have support from the
| maintainers for their builds to produce extensions we can
| add to our component updater as optional for our users. We
| are discussing this now with uBO/uM maintainers.
| spiffytech wrote:
| Brave's CEO has said they'll add back any functionality that
| ad blocker extensions need to keep working under Manifest v3.
|
| https://twitter.com/joshmanders/status/1134139586836344832
| unethical_ban wrote:
| I have no clue what Manifest V3 is, and more importantly, why
| Mozilla or anyone except Chrome and Chrome extension developers
| _need_ to care.
|
| It sounds like it is the extension API and process manager for
| Chrome. In what ways would an end user or website owner notice or
| care about this change, other than their extensions not working?
| How does it change default behavior?
| gorhill wrote:
| One of the stated goal of MV3 by Google[1] was to avoid
| extensions with broad permissions:
|
| > our new declarativeNetRequest API is designed to be a privacy-
| preserving method for extensions to block network requests
| without needing access to sensitive data
|
| This MV3-based AdGuard extension still requires a broad
| permission to "read or modify host data" on all sites[2]:
| "host_permissions": [ "<all_urls>" ],
|
| So what you have now is the same required permission to "read or
| modify host data" as with MV2, but with a network filtering
| engine capabilities gated by Google (an advertising company).
|
| We can't innovate anymore the filtering capabilities of our
| content blocker engines as we have been constantly doing over the
| years.
|
| For a recent example, there has been discussions lately with
| filter list maintainers of whether uBO should support AdGuard's
| proposed capability of being able to support pattern-matching for
| `domain=` filtering option[3] (uBO supports AdGuard lists).
|
| That sort of proposition is not possible to entertain with MV3
| since only Google get to decide how the filtering engine will
| evolve, if at all. All content blocking issues will have to be
| resolved with the Google-controlled filtering engine, and left
| unaddressed if the solution can't be shoehorned in the
| declarativeNetRequest API.
|
| * * *
|
| [1] https://blog.chromium.org/2020/12/manifest-v3-now-
| available-...
|
| [2] https://developer.mozilla.org/en-US/docs/Mozilla/Add-
| ons/Web...
|
| [3] https://github.com/AdguardTeam/CoreLibs/issues/1550
|
| * * *
|
| Edit: removed stray `[` character.
| ComodoHacker wrote:
| To be fair, general ad blocker will always require broad
| permissions, no matter what API it uses. There's no sense in ad
| blocker that works only on N sites.
| freediver wrote:
| If you care about running uBlock Origin on macOS, happy to
| report that Orion browser by Kagi (WebKit based) supports it
| and will keep supporting Manifest v2.
| baggachipz wrote:
| Orion also has a damn good ad-blocker already running by
| default.
| minitech wrote:
| (In case anyone else didn't realize or found it ambiguous,
| Kagi is their company.)
| staticassertion wrote:
| Presumably that permission does not mean the same thing in v3.
| That is, the site can still read/modify data but, of course,
| only through the specific declarative APIs that delegate the
| work _to the browser_.
| somehnacct3757 wrote:
| MV3 splits permissions into host permissions and classical
| permissions (tabs, storage, etc). Putting <all_urls> in your
| host permission list means that whatever the extension does,
| it can do it on all possible urls you may visit in the
| browser. In this sense, it's no different than in MV2.
|
| What's different is the classical permissions. Previously you
| could use the webRequest permission to execute custom JS
| functions in response to network activity. In MV3 you must
| now write a declarative rule instead using the
| declarativeNetRequest permission. By moving from an
| imperitive model to a declarative one, Google now has
| exacting control over what ad blockers can and can't do.
|
| Gorhill's argument is that the stated reasons for MV3 do not
| align with the implementation. The example he gives is that
| Google claims the new API is more private. However you still
| need <all_urls> so the extension is as un-private as its MV2
| equivalent. The only difference is that now Google controls
| what blocking you're allowed to declare and how much of it
| you're allowed to do.
|
| There's a similar community discovery where MV3
| implementation is provably counter to Google's claims of
| performance enhancement - MV3 extensions need to rehydrate
| state every 5 minutes as Chrome shuts down their service
| worker and for highly active extensions such as ad blockers
| this is actually less performant than the MV2 implementation
| with a long-lived background.
|
| Basically, Google is full of shit.
| hoffs wrote:
| It's a big difference between letting extension provide
| some rules and letting extension do whatever it wants with
| the request.
| matheusmoreira wrote:
| > Basically, Google is full of shit.
|
| Not _completely_ full of shit. Declarative rules are a good
| idea in the general case. Random browser extensions really
| should not have unrestricted access to network. This is how
| we get malware.
|
| It's just that uBlock Origin is too important and trusted
| that these limitations should not apply to it. I'd even say
| ad blockers should be a built in browser feature but thr
| conflicts of interest prevent that.
| userbinator wrote:
| I hope filtering proxies like Proxomitron become popular again.
| They'll work on all browsers, and as long as locked-down
| corporate environments with their own needs for filtering
| content and the requirement to go through a proxy exist, it's
| not something they can easily kill off (despite trying their
| hardest to do so with all the "security" propaganda.)
|
| Stop being at the whims of the Google-controlled browser
| monopoly --- by filtering content before it gets there.
| pkulak wrote:
| Man, I used Privoxy back in the day and it was amazing. Now,
| however, you need to set up custom certs so that you can MITM
| yourself, plus those things can only look at the initial HTML
| without running any JS. I don't know how less effective that
| would make filtering, but it can't help.
|
| I'd love to be proven wrong though! Right now I run DNS-based
| filtering because, no, it's not perfect, but I really like
| having network-wide blocking.
| hackernudes wrote:
| Proxy and ssl doesn't work for filtering (basically the same
| as dns).
|
| Maybe some sort of "remote browser" remote desktop or
| browser-in-browser type thing will work.
| Dwedit wrote:
| You can still install a certificate, and that will let you
| "man-in-the-middle" attack yourself with proxy server
| programs.
| guilhas wrote:
| Proxomitron was amazing, very advanced, and even worked with
| ssl. All preceding proxy apps were very weak
| ameshkov wrote:
| All true, and we (content blockers devs) were saying this all
| for years, since MV3 was first announced. MV3 brings very
| little (if any) privacy and security enhancements, this is for
| the future MV4 when extensions will be dumbed down to sets of
| declarative rules.
|
| We'll now need to rely on Chrome team for implementing what we
| need. But they do it painfully slow or not do at all.
|
| Also, where will we get the new ideas if every browser follows
| that path? Take Safari for example, every little improvement
| that we requested [1] was inspired by what we already did in
| other browsers long ago.
|
| Anyways, a working content blocker on MV3 is possible. I even
| think a casual user won't feel much difference. But there is a
| big difference under the hood and to feel the consequences we
| have to wait a few years.
|
| [1]: https://bugs.webkit.org/ (search for those reported by
| @adguard.com). Just a very small part of what we requested was
| implemented, content blocking is not a priority I guess, and it
| won't be a priority for Chrome.
| avhception wrote:
| I just wanted to say that you (content blocker devs) have
| been heard, maybe not by the majority of browser users but at
| least people like me are championing Firefox over webkit-
| based browsers precisely because to do otherwise would be to
| loose control of the web to FAANG, especially Google. I've
| been telling everyone who would listen about how Google
| leverages Chrom(e/ium) against user interests and have
| deployed Firefox to every friend & family user whose machines
| I support.
| moonchrome wrote:
| I wonder why not create a ad-free/privacy fork of Chromium.
| Especially on Mobile, I'd use that for sure. Existing ones
| have huge strings attached. Mozilla is basically FUBAR at
| this point.
| cycomanic wrote:
| Why is Mozilla fubar? I'd argue it's much less work to
| get behind Mozilla than trying to maintain a chromium
| fork.
| Melatonic wrote:
| Firefox on mobile works great for me and has for years?
| kmeisthax wrote:
| This exists, it's called Ungoogled Chromium. Removing
| whatever misfeatures Google adds to Chrome is fairly
| straightforward.
|
| The real danger to having a single codebase for the whole
| web is spec validation. Most web standards rely on two
| independent implementations. For newer technologies we
| could technically count WebKit and Blink as separate, but
| Gecko was providing an entirely separate codebase that
| isn't a fork of _anything_.
|
| Remember how WebSQL was basically put out to pasture
| because it was just SQLite, warts and all, shoved inside
| the web sandbox? That's the sort of problem we'd rather
| avoid. Single-implementation standards tend to pick up
| bugs and misbehaviors from their implementation, since
| everyone winds up depending on implementation bugs rather
| than getting them fixed to match spec.
| HWR_14 wrote:
| > Removing whatever misfeatures Google adds to Chrome is
| fairly straightforward.
|
| Yes. But adding back in Manifest v2 isn't. Even MSFT
| claims that it's too much work for them.
| NeverFade wrote:
| IIUC, the only problem with Mv3 is that they disabled the
| WebRequest API. A fork of Chromium that solves this
| problem will just have to re-enable the WebRequest API,
| which seems doable.
| HWR_14 wrote:
| Isn't the lack of a WebRequest API one of the primary
| changes in Manifest v3?
| NeverFade wrote:
| It's apparently quite possible to keep supporting the
| WebRequest API in Mv3, since Firefox is doing just that.
| Tijdreiziger wrote:
| I also recommend people I know to use Firefox, but a lot of
| people either don't understand the problem or just don't
| care.
|
| A lot of people even conflate Google Chrome, Google Search
| and other Google services (understandable, as Chrome's home
| page is a big Google logo with a search box), so they think
| that they cannot use Google anymore if they install
| Firefox.
|
| The stats [1] speak for themselves: only 3.3% of users use
| Firefox. Even Edge has more users.
|
| [1] https://gs.statcounter.com/
| mdaniel wrote:
| One thing to be cautious of when trying to count browser
| stats is that the recent releases of Firefox are pretty
| aggressive about blocking tracking scripts, such as those
| used by a site like statcounter.com uses to count up
| browser usage
| <https://gs.statcounter.com/faq#methodology>
|
| I don't know how to solve that problem, since those two
| outcomes are at odds with one another, but wanted to
| raise awareness
| novax81 wrote:
| It's harder to get people to switch browsers nowadays.
| When Chrome first came out as a breath of fresh air (IE
| was IE, Firefox was better but a bit "heavy", Opera
| was... Opera), normal users would just nod and agree if
| you recommended a switch, and even as a power user, I
| only had to migrate a handful of extensions and behaviors
| over. At this point, browsers (particularly Chrome and
| Safari on their respective platforms) have ingrained
| themselves into their users daily routine. Things like
| bookmarks and some habits transfer pretty quickly, but
| casual users won't care enough about this (until they're
| impacted more).
| cycomanic wrote:
| I think the stats are showing that we really need
| debundling of the browser from the OS. I'd wadger that
| those stats pretty closely align with the percentage of
| android and IOS users, or in other words the stats are
| completely dominated by mobile browsers, where hardly
| anyone changes browsers.
|
| I can't understand why we have not seen strong
| regulatory/antitrust action on this front considering the
| precedent with MS.
| happymellon wrote:
| That's funny because my phone is weaker than my laptop,
| and has a smaller screen to show useful information
| Firefox and uBlock get installed faster to remove the
| slowdowns and popups.
| HWR_14 wrote:
| I dread the debundling. The day Google can tell iOS users
| to "just download Chrome" is the same day all non-Chrome
| browsers will stop working on Google properties. Well,
| they'll let Chromium browsers (which also support their
| ad-blcoking-blocking) work too, for antitrust reasons.
| shadowgovt wrote:
| > this is for the future MV4 when extensions will be dumbed
| down to sets of declarative rules.
|
| I haven't heard of this plan. Do you have more information?
| ameshkov wrote:
| No plans were announced so these are purely my speculations
| but to me it seems logical.
|
| The only piece of reliable information is this: I once
| asked Google engineer whether they plan to support
| declarative cosmetic rules (that's what we do ourselves in
| MV3 and that's why the extension still requires wide
| permissions) and the answer was that they definitely do
| plan to do that in the future.
| shadowgovt wrote:
| Supporting that makes sense to simplify the use case so
| that people don't have to write JavaScript for simple
| changes, but that doesn't imply they'll replace the
| JavaScript API with a purely declarative API there.
|
| The difference between that and the traffic modification
| API is the threat model. The third party were to
| compromise uBlock Origin's servers, they would have a
| frightening amount of power over millions of machines
| because uBlock Origin essentially self-modifies; it
| downloads new rules for what should be blocked. So that
| breaks the security guarantees Chrome wants to provide;
| they can't say that the lock icon on a website means
| anything if a Chrome extension is allowed to arbitrarily
| modify traffic back and forth as a man in the middle on
| the last mile and Chrome web store maintainers haven't
| looked at the source code it's running.
|
| I don't think there's a similar security threat for
| cosmetic changes.
| [deleted]
| encryptluks2 wrote:
| > No plans were announced so these are purely my
| speculations but to me it seems logical.
|
| And then people use and rely on information like this to
| further ignite their cognitive biases. Seems more like
| promoting misinformation than anything.
| kelnos wrote:
| Misinformation is presenting falsehoods as truth.
| Speculating based on past behavior is something else.
| hombre_fatal wrote:
| To be fair, this thread exists because OP made the claim
| as if it wasn't speculation and someone took them up on
| it which only then made OP clarify that they were
| speculating.
| encryptluks2 wrote:
| So if you say the earth is flat and you are just
| speculating based on no evidence it isn't misinformation?
| That is what you did and you should own it.
| d4rti wrote:
| It's pretty hard to search bugzilla, so to save anyone else
| time, this is what I ended up finding (9 bugs) https://bugs.w
| ebkit.org/buglist.cgi?bug_status=UNCONFIRMED&b...
| ameshkov wrote:
| Let's be fair to Safari devs, you should probably search
| for all statuses and not just the bugs and feature requests
| that are still open:
|
| https://bugs.webkit.org/buglist.cgi?bug_status=UNCONFIRMED&
| b...
| tech234a wrote:
| Regarding MV4: the WebExtensions working group has started to
| mention the term at some of their recent meetings, although
| details are scarce it seems MV4 will still retain JS code
| execution [1] [2].
|
| [1]: https://github.com/w3c/webextensions/blob/main/_minutes/
| 2022... (CTRL-F for "mv4")
|
| [2]: https://github.com/w3c/webextensions/blob/main/_minutes/
| 2022... (CTRL-F for "mv4")
| cycomanic wrote:
| How about simply not supporting chrome. I believe some
| responsibility for this lies with us developers. It was
| developers who made extensions for chrome. We as
| technologists recommended chrome to our friends and families.
| Without us chrome would likely not be in the position it is
| today and google could not dictate the terms like they do.
| Maybe it is time that extension authors abandon ship, and we
| recommend alternative browsers?
|
| To those who argue that chrome is faster and therefore you
| prefer using it. You should ask yourself, what is more
| important to you, to see a website a few ms faster or
| preventing Google to to dictate how the Internet of the
| future works (apart from the fact that in my experience
| browser's are so close in performance, that I don't think
| anyone can consistently pick which browser their on).
| zelphirkalt wrote:
| One problem is of course, that Google managed to convince
| many fanboys, that it is a highly progressive modern and
| technologically superb company, that spits out
| revolutionary tech every month and only the developers of
| highest skill could work there, so all that comes out of
| Google must be naturally superior to any competition.
|
| If Google says, that they value speed of their browser as
| the main attribute, that mindset if adopted by the fanboys.
| If Google says you don't need more powerful ad blocking,
| then that idea is adopted by the fanboys. Google says it,
| so it cannot be wrong. Anyone saying something different is
| just being jealous, that they are not as good a developer
| to work at Google. Google! Oh please! Tell us what to
| think!
|
| This kind of thinking also proliferates into non-developer
| communities and people, who look at it from the financial
| success side of things. Google, one of the biggest tech
| companies evaaar! Surely they must be doing something
| right! This developer friend, what do they know, compared
| to the knowledge of Google employees?! Better listen to
| Google.
|
| Google has managed to twist the minds of many, who are too
| open for authority arguments and developers are no
| exception to that.
|
| As long as we still in some way think, that Google has our
| wellbeing at heart, I think things will not change.
| However, I support not supporting Chormium-based browsers
| any longer. People only learn the hard way, which is, when
| they have to fight through jungle of ads to use even the
| simplest websites. Some learn not even then.
| bambax wrote:
| Very few fan boys can survive a day of web surfing with
| no adblock.
| kroltan wrote:
| Yes they can, because then they not will not be "annoying
| ads" anymore, they become "relevant recommendations" as a
| coping mechanism.
| HWR_14 wrote:
| > to those who argue that chrome is faster and therefore
| you prefer using it
|
| Those comparisons never take into account the runtime costs
| of ads. Yay, code runs 10% faster. It runs 3x as much code
| and has to wait on a dozen ad servers, but yay!
| throwaway09223 wrote:
| I remember switching to Chrome because it was faster.
|
| I switched back to Firefox a few years ago. Firefox has
| improved a _lot_ and the overall experience is just far
| better.
|
| One of the nicest small things is that I've got the full
| URL back in the URL bar, including http/https!
| colordrops wrote:
| Yes, Firefox is no longer second tier. This is a
| relatively recent development, and anyone who avoided it
| for performance reasons should try it again. It's fast,
| and doesn't have any rendering issues.
| staticassertion wrote:
| I use Chrome because it's faster, safer, more stable. I
| don't believe V3 in any way is a serious issue for the
| internet in any meaningful sense either.
| zelphirkalt wrote:
| Did you read the entry on HN recently, where it is
| discussed, that Chromium-based browsers allow websites to
| set your clipboard content, without user action being
| involved at all?
| (https://news.ycombinator.com/item?id=32614037)
|
| Just one example of how it is not safer, that I thought I
| should mention, on the background of such a blanket
| statement as "Chrome is safer" : )
| callalex wrote:
| It is objectively less safe to use the web without an ad
| blocker.
| tssva wrote:
| Then it is a good thing that MV3 doesn't prevent ad
| blockers as demonstrated by AdGuard having made one.
| bornfreddy wrote:
| > as demonstrated by AdGuard having made a crippled one.
|
| Fixed that for you.
| matheusmoreira wrote:
| It doesn't really matter though. What matters is uBlock
| Origin and whatever gorhill says. Either uBlock Origin
| works at its full potential or the browser vendor is
| deliberately crippling ad blocking.
| zelphirkalt wrote:
| Unless Google really wants you to see that specific
| category of ads.
| matheusmoreira wrote:
| > Without us chrome would likely not be in the position it
| is today
|
| No doubt it would. Google essentially advertised Chrome at
| the very top of the search results page. No amount of
| personal boycotting is ever going to win against that.
| tedivm wrote:
| I've been switching my family over to Firefox with UBlock
| Origin. I made the switch when these original changes were
| announced, and it's been a great experience. I run into
| maybe one website a month where I have trouble.
| Larrikin wrote:
| Not recommending Chrome is the way to go. There was a time
| where developers only tested against IE, built features on
| top of IE, and there didn't seem any way to defeat the
| garbage associated with IE.
|
| But people recommended Firefox anyway for most browsing
| since it was a better experience on the open web.
| Eventually it up ended the dominance by giving a better
| browsing experience except when forced to use IE through
| bad code, which eventually forced more developers to
| improve the experience outside of IE.
|
| I personally never stopped using Firefox for Chrome, since
| there was always some extension that just didn't work quite
| as well on Firefox for the longest time. I've always found
| it worked it well.
|
| A popular opinion of a vocal contingent of users on this
| site always say that Chrome is so fast, without any
| benchmarks other than their personal feelings for the most
| part. If Google is going to be openly hostile to extensions
| like UBlock working as intended I really wonder if they
| would feel Chrome is much faster if the developers of such
| extensions stopped looking for work arounds in an actively
| hostile environment and simply let them experience the
| garbage that is the current state of the web. They've
| already shown their hand as being a terrible steward of the
| web by blocking extensions like AdNauseum that try to
| destroy all the tracking and privacy violations they've
| created.
|
| I personally believe all the people who don't have their
| jobs tied to creating ad garbage would do another exodus.
| Although I'm sure a vocal minority would create noise on
| sites like this since their jobs are tied to making the
| world a worse place.
| bornfreddy wrote:
| This. While I appreciate the work AdBlock does,
| supporting MV3 is ludicrous. If no ad block extension
| supported it, it would be dead on arrival - with Chrome
| too (if Google tried to force it). Just let it be, fire
| up your Firefox and browse freely.
| ghoward wrote:
| I think you are right. It's not worth it.
|
| I just switched to Firefox. I'm typing this on Firefox.
|
| I used to use Ungoogled Chromium.
| bornfreddy wrote:
| Welcome! :)
| ameshkov wrote:
| This sort of boycotting will only work when widely
| supported by both developers and users and this is not the
| case. Despite all the public outcry and news outlets
| telling that the end is near, it didn't affect the Chrome's
| share.
|
| > Without us chrome would likely not be in the position it
| is today and google could not dictate the terms like they
| do.
|
| I kind of disagree with this. Google Chrome's current
| popularity stands on two things:
|
| 1. It is a great browser and it does its job very well.
|
| 2. Google in the first years was very active with its
| distribution. And this is not only about the link on their
| homepage. I remember how 10 years ago every piece of
| software you were trying to install was bringing Chrome
| alongside.
|
| Engineers recommending Chrome to their friends and
| relatives shouldn't be discounted, but I tend to think that
| it's less important that the two other points above.
| Fatnino wrote:
| If suddenly there was no ad blocking available on Chrome
| cold turkey we would see nearly all users who are
| accustomed to an ad free experience go looking for a new
| browser. Coordinate this with a marketing blitz from
| Firefox and essentially you can take nearly all the
| Chrome ad block users and turn them into Firefox users.
| And from there it's word of mouth even from the non-
| techies.
|
| Good ad blocking is an essential part of a browser. Even
| Google who is actively slow boiling the frog knows they
| can't just hard cut it off because the users will jump
| ship immediately.
|
| Why should we let Google get away with this? I feel the
| right move is to proactively take steps that make Chrome
| very obviously noncompetitive. By not providing ad
| blocking at all or at least making it a much inferior
| experience. It needs to be obvious to the users, not just
| to tech folks.
| taiiat wrote:
| _If suddenly there was no ad blocking available on Chrome
| cold turkey we would see nearly all users who are
| accustomed to an ad free experience go looking for a new
| browser_
|
| so.... Utopic best case scenario, 30% of the users? and
| that's if 100% of People using AdBlocking across the
| entire Planet were to make a move. and those are the
| users that don't provide any Revenue back to the Owner,
| anyways. the average user is using official Chrome, with
| very few Plugins, maybe like Reddit Enhancement, extra
| Twitch Emotes, Et Cetera.
| Bedon292 wrote:
| What is the market share of Chrome users who use ad
| blocking though? I don't know if its large enough to make
| a dent in the overall market share. And even then not
| sure everyone who has one installed would jump. I have it
| in my mom's browser but if it stopped working tomorrow
| she wouldn't know enough to make any changes.
| Fatnino wrote:
| It won't tip the balance but it is a significant
| percentage of active users. I want to say greater than 15
| percent but I can't remember where I saw that.
|
| Anyway, it doesn't really matter what percentage of all
| users, just what percentage of techie word-of-mouth types
| use ad blockers. And that is a very significant
| percentage.
|
| Maybe your mom can't change it herself but come
| Thanksgiving she's going to complain about it to you and
| you are going to fix it so she has an ad free experience
| again.
| gxnxcxcx wrote:
| I agree. And a very small percentage of Chrome users
| turned Firefox users could still mean a significant
| increase in Firefox usage, which in an ideal world would
| allow Mozilla a much needed breather from their metrics-
| driven efforts to stop bleeding users.
| [deleted]
| dont__panic wrote:
| Why not fight fire with fire?
|
| Consider checking for the Chrome user agent on your
| personal website. When you detect it, either:
|
| 1. Display a screen that encourages to use a browser that
| respects their privacy, such as Firefox.
|
| 2. Show a popup explaining that "for an ad-free
| experience, try Firefox + uBlock" and add a bunch of fake
| (or real) ads to a special Chrome-exclusive piece of the
| site.
|
| If enough of us do this with personal websites, more and
| more people will stop using Chrome and start using
| Firefox. You don't even have to cut Chrome users off from
| the content -- just annoy them a little, and suggest
| Firefox.
|
| After all, if Google refuses to fix bugs introduced by
| Google developers who don't test software in browsers
| other than Chrome (https://support.mozilla.org/en-
| US/questions/1069227), the least that the rest of us can
| do is fight back in some small way.
| MikeHolman wrote:
| >If enough of us do this with personal websites, more and
| more people will stop using Chrome and start using
| Firefox. You don't even have to cut Chrome users off from
| the content -- just annoy them a little, and suggest
| Firefox.
|
| It's a nice idea, but your personal website doesn't
| matter. Most people go to a Google website at least a few
| times a day, and they already tell you to switch to
| Chrome for the best experience. And almost all of the top
| non-Google websites also have a vested interest in less
| adblockers, so none are going to riot over this.
| lapinot wrote:
| If the serious ad-blockers would stop supporting chrome,
| then all the shady freemium/quasi-malware stuff would be
| more than happy to be the only option. Most people don't
| "really" choose their browser, they just use what someone
| (or themselves years ago) installed for them. The main
| reason for chrome's shares is google's search&android
| domination and how hard they pushed it.
| blibble wrote:
| they're not stupid enough to block it all at once
|
| MV3 will slowly make adblocking more and more useless,
| like boiling the frog
|
| at which point most people who formerly used adblockers
| will become accustomed to the ad-infested web again
| bambax wrote:
| I strongly believe the above to be true.
|
| Devs of adblockers should all, suddenly, stop supporting
| Chrome. Make it a specific date (Jan. 1st 2023?) and make
| it known.
|
| The web is unusable without strong, efficient adblocking.
| All power users would stop using Chrome in an instant.
| Even if they are a minority, the move would become
| visible on usage charts.
| tsimionescu wrote:
| Unfortunately, we have a negative case study for this
| belief, one that proves the impact would be minimal:
| Android. Chrome on Android doesn't support any
| adblockers, while Firefox does, with perfectly simple
| installation. Still, Firefox Android is only a tiny
| sliver of the pie.
|
| (posted from Firefox on Android)
| BeefWellington wrote:
| It feels like this was always going to be how this played out.
| Google being the world's largest ad company has a vested
| interest in ensuring ads are still displayed to users and once
| a sizeable enough amount of the Chrome userbase started
| adblocking it directly threatened their revenue growth.
|
| The only option here it seems is to switch browsers.
| staticassertion wrote:
| But these changes don't ensure that ads are displayed to
| users. This won't impact Google's ad revenue at all. At most
| it will negatively impact their revenue because the less
| powerful API will let the sketchier advertisers try to bypass
| the filters.
| BeefWellington wrote:
| Google _is_ the sketchier advertiser you 're speaking of.
| e3bc54b2 wrote:
| For context, gorhill is the veteran author of original uBlock,
| and current uBlock Origin. He knows what he's talking about as
| author, maintainer and one of the community leader/voice of
| probably the single best and only conflict-of-interest-free ad-
| blocker currently in existence.
|
| His past post[0] was reposted and generated quite a discussion
| on HN [1].
|
| For further details on why uBO is conflict free, this is the
| README.md on github repo[2] says:
|
| ---
|
| Free. Open source. For users by users. No donations sought.
|
| ---
|
| 0: https://github.com/gorhill/uBlock/wiki/uBlock-Origin-
| works-b...
|
| 1: https://news.ycombinator.com/item?id=32542968
|
| 2: https://github.com/gorhill/uBlock
| dylan604 wrote:
| thank you gorhill for making the internet a useable space.
| naikrovek wrote:
| hear, hear.
| Abishek_Muthian wrote:
| uBlock Origin is the only browser extension I use on Firefox,
| Even after loosing trust on browser extensions in general
| after witnessing a recommended Firefox add-on indulge in
| malicious activity[1] and reading numerous stories of how
| browser extension publishers with large number of users are
| routinely approached to integrate malware.
|
| The reason why I cannot do away with uBlock Origin is because
| its not just an Ad-blocker as its philosophy states, I need
| it to make websites usable by blocking elements like auto
| pop-up news video player, Blocking side bars to resize the
| websites to preferred width (When playing videos), Disable
| tracking and often just to load the websites faster.
|
| [1] https://web.archive.org/web/20210924045611/https://github
| .co...
| behnamoh wrote:
| > I need it to make websites usable by blocking elements
| like auto pop-up news video player, Blocking side bars to
| resize the websites to preferred width (When playing
| videos),...
|
| Exactly. I use uBlock to "detoxify" websites and rid them
| of such nonsense elements.
| RunSet wrote:
| To those familiar with the HTML DOM I recommend uMatrix
| from the same author as uBlock origin. It makes a good
| companion to uBlock Origin and provides much finer control.
|
| https://github.com/gorhill/uMatrix
| dicriseg wrote:
| That repo is archived. Is the project dead?
| 411111111111111 wrote:
| Isn't it pretty much redundant? You just have to enable
| advanced mode in ublock origin extension settings. The
| interface is arguably slightly harder to figure out
| though, but the functionality is there once you've
| enabled it.
|
| the ublock origin repo actually has a video linked how it
| works: https://youtu.be/2lisQQmWQkY?t=294
| emaro wrote:
| Yes, it's not actively developed anymore because of the
| large overlap in functionality with uBlock Origin as well
| as the maintainance burden.
|
| However it's not equivalent, because in uMatrix you have
| even more fine-grained control which content a certain
| domain in a certain context can load (i.e. scripts,
| images, css and xhr requests).
| 411111111111111 wrote:
| Its functionality is equivalent, its ease of use isn't
| (at least in my opinion)
|
| with uBlock origins UI you can block by content type and
| then whitelist the domains which are still allowed and
| that feels less granular then the uMatrix configuration
| dialog.
|
| But if you check the generated dynamic rules in the
| settings you'll see that it supports the same granular
| controls as uMatrix
| lapinot wrote:
| GP is correct afaik: the request categories for dynamic
| rules in ublock are image, 3p, inline-script, 1p-script,
| 3p-script, 3p-frame. The 3p vs 1p vs inline is kinda
| weird in itself since it's contextual and not relating to
| the content-type of the request, and we are missing css
| and xhr. Thing is, i realized i most of my dynamic rules
| are by domain anyway. Maybe if i find a real use case
| i'll try to look into the code and make this a bit more
| versatile.
| Arnavion wrote:
| https://news.ycombinator.com/item?id=26284124
| Mathnerd314 wrote:
| I tried uMatrix for a bit and it seems the dynamic
| filtering capabilities of uBlock do 80%+ of what uMatrix
| does.
| nightpool wrote:
| Has Google said that they would reject CLs to the
| declarativeNetRequest API if filter list maintainers propose a
| new feature? Have any filter list maintainers tried to propose
| those CLs? Obviously it would require a new set of skills and
| talent to maintain the C++ code that now powers Chromium's ad-
| blocking capabilities, but Chromium is still an open project
| with guidelines for contribution, no?
| loeg wrote:
| > Chromium is still an open project with guidelines for
| contribution
|
| Hah. The default is to reject changes from the community. I
| would not pin my hopes on Chromium accepting any adblocking
| community changes.
| Multicomp wrote:
| It is such a bummer to me that Firefox is implementing MV3 and
| deprecating MV2[1]. Internet Explorer 6 never left, it just
| became Google Chrome*.
|
| Vivaldi? Killed, Chrome clone. Edge? Killed, Chrome clone. Brave?
| Killed, Chrome clone. Firefox? Technically a separate engine and
| in theory among the last hopes, but so sclerotic it follows
| Chrome in almost all of its decisions. (Can MV2 be kept as a
| stable basic-security-maintenance-only API? Probably not) Safari?
| Can be gone around on desktop (my grandparents use Chrome because
| of Google prompts), has a stranglehold on mobile, but that has
| its own problems, and likely once users can ~sideload~ install
| software (potentially from other app stores), there will be a
| Chrome surge on mobile, forcing manifest V3 over there too, and
| the ad trackers will win the war.
|
| Or maybe they already have? More likely, I personally am tiring
| of the cat and mouse game between the spyware makers and devs
| that fight for the users.
|
| [1] UPDATE:
| https://blog.mozilla.org/addons/2022/05/18/manifest-v3-in-fi...
| PREVIOUSLY:
| https://blog.mozilla.org/addons/2022/06/08/manifest-v3-firef...
|
| * In the sense that one browser implementation, and not W3C or
| WHATWG web standards, drives the web browser market. Chrome is
| much more evergreen than IE.
| dagurp wrote:
| Vivaldi has been using MV3 for more than a year now and the
| adblocker works fine.
|
| https://vivaldi.com/blog/ad-blocker-vivaldi-browser/
| Multicomp wrote:
| I'm glad it does. I was mixing/matching my arguments a bit. I
| don't want to use Chrome both because (MV3 by Chrome is super
| locked down) and (Blink browser engine monoculture is bad for
| web durability), so when I said Vivaldi was a dead Chrome
| clone, I was referring more to the latter than the former.
| bambax wrote:
| What you call "Chrome clones" are in fact based on Chromium,
| but aren't Chrome. The difference is not huge as they all use
| the same rendering engine, but appart from that they're free to
| do other things. Brave for instance comes with full-on adblock
| built-in.
| catach wrote:
| Isn't this a better link for Firefox, since it covers their
| reasoning and where they're not following Chrome?
|
| https://blog.mozilla.org/addons/2022/05/18/manifest-v3-in-fi...
| Multicomp wrote:
| Yes, this is. duck.com search didn't surface that one on my
| first SERP so will update my post to reflect. Thanks!
| jefftk wrote:
| _> Vivaldi? Killed, Chrome clone. ... Brave? Killed, Chrome
| clone._
|
| Brave and Vivaldi have always been built on Chromium, because
| that was the easiest way for them to get started as new
| browsers. There wasn't some pre-Chromium version of either that
| was killed.*
| jacooper wrote:
| Also its just simply the best engine on the market.
| bpye wrote:
| Is it the best or does it just _seem_ to be the best as
| most web content is only tested on Chrome, or Chrome and
| mobile Safari perhaps?
| shadowgovt wrote:
| Hate to say it, but I used to have the job of testing on
| Firefox and (at least at the time) no, Chrome was the
| best.
|
| The number of irritating little performance regressions
| we'd hit when doing anything interesting with the DOM in
| Firefox was notable (as in, we noted it in the bug-
| tracker ;) ). Broadly speaking, I began to assume Mozilla
| didn't have enough real-world integration tests back-
| stopping changes to their rendering engine.
|
| I haven't tested in a few years so that information is
| stale.
| jacooper wrote:
| Its technologically better.
|
| Especially when talking about security.
|
| https://madaidans-insecurities.github.io/firefox-
| chromium.ht...
| maskros wrote:
| Not true.
|
| Firefox is vastly better in terms of rendering quality for
| scaled and/or transformed raster images. Chrome always
| sacrifices quality for performance, with no way to choose.
|
| Firefox's SVG support is also miles ahead, both in
| rendering quality and features.
| jacooper wrote:
| This is only a part of a browser engine.
|
| Security? Website isolation? Performance? And many other
| things are just simply better in chromium.
|
| https://madaidans-insecurities.github.io/firefox-
| chromium.ht...
|
| Yes Google is abusing its influence on chromium, but one
| must admit, its simply the best engine out there.
| jefftk wrote:
| It's the best engine for building your own browser on top
| of, which is the main thing someone building a browser
| cares about. This is something the Chrome team has
| prioritized, and Firefox has not.
| arusahni wrote:
| Mozilla is not implementing[1] any of the Mv3 restrictions
| against ad blockers (i.e. WebRequest).
|
| [1] https://blog.mozilla.org/addons/2022/05/18/manifest-v3-in-
| fi...
| worble wrote:
| I don't think they've come out to support other extensions
| that will be killed in the crossfire however, such as
| ViolentMonkey or TamperMonkey.
|
| https://github.com/violentmonkey/violentmonkey/issues/1555
|
| https://github.com/Tampermonkey/tampermonkey/issues/644
|
| The only thing we have so far is a google rep stating that
| they'll "reaffirm that we plan to support userscript managers
| in Maniest V3 before the Manifest V2 deprecation"[0] back in
| May, which fills me with no hope at all that they won't
| simply be killed.
|
| 0: https://github.com/Tampermonkey/tampermonkey/issues/644#is
| su...
| Multicomp wrote:
| I stand corrected in a big way. I'm very pleased that Firefox
| is doing this, I need to go make my other doom-gloom be less
| doom-gloomy now.
| autoexec wrote:
| I'm glad they're making changes, but I'd advise everyone to
| keep a close watch on what they end up implementing and
| what potential security and privacy risks may be
| introduced.
|
| It seems like I'm having to disable something or other with
| every major update of firefox lately, and as long as they
| continue to let me disable risky features I'll keep using
| it. Nothing strikes a better balance between useful and
| secure like hardened a firefox install, but it takes a lot
| of vigilance and a willingness to add or modify hundreds of
| about:config options (after installing
| https://github.com/earthlng/aboutconfig)
| wooque wrote:
| Just install Brave, its adblocker is natively implemented and not
| affected by Manifest V3 fiasco.
| mastazi wrote:
| that's what Brave staff keep repeating but in the meantime all
| other extensions that need v2 are a pain to install, for
| example this one https://libredirect.github.io/ requires you to
| enable dev mode, load the extension and then apply any updates
| manually.
|
| They announced a Brave Extensions Store years ago and there are
| no news as of today.
|
| I'm actually thinking to go back to Firefox because of this.
| BrendanEich wrote:
| We never announced an extension store.
|
| I said we'd support uBO and uMatrix at least, and we're
| discussing that with their maintainers now.
| aaaddaaaaa1112 wrote:
| markstos wrote:
| I'm curious how the performance of the new AdGuard extension has
| changed.
| ameshkov wrote:
| It's worse than it was and the reason for that is not the
| declarativeNetRequest, but replacing background page with a
| service worker.
|
| You see, now extensions are supposed to do background work in
| an ephemeral service worker. This service worker lifetime is
| very short (up to 5 minutes, then it's getting killed
| forcibly). So it's constantly getting killed and waked back up.
| Waking up includes doing some initialization which consumes
| additional cpu cycles.
|
| The situation will improve when Google implements the
| alternative to service worker (so-called "Offscreen
| documents"), but no one knows when exactly this will happen.
| nfriedly wrote:
| Wow, that whole article and not a single mention of Firefox!
|
| Firefox still supports Manifest V2, which allows for more
| efficient and accurate blocking of advertising. (Among other
| things.)
| ehsankia wrote:
| Because that's off topic? I'm tired of seeing every single
| thread about MV3 turn into "Switch to Firefox". Yes, we know
| about that obvious solution, it's been shouted ad nauseum, I'm
| interested to see and hear about how ad blockers will work on
| MV3, not the existing alternative we've already heard about a
| billion times.
|
| Just look at this very thread, every other comment is just
| about Firefox and not the content of the post itself.
| nfriedly wrote:
| Sure, I'm "preaching to the quior" here, but given Firefox's
| current market share, I'm not sure we've gotten the word out
| much beyond our circle.
|
| The article mentioned Safari a couple of times, I don't see
| why the fact that Firefox will support both V2 and V3
| indefinitely doesn't deserve a single mention.
|
| Moreover, manifest V3 was essentially a massive middle finger
| from Google to everyone else (except advertisers), and it
| feels almost dishonest to discuss it _wothout_ mentioning
| that there are better options out there.
| hoffs wrote:
| Chrome also still supports manifest V2
| nfriedly wrote:
| Not for long
___________________________________________________________________
(page generated 2022-08-30 23:01 UTC)