[HN Gopher] uBlock Origin Lite: Description
___________________________________________________________________
uBlock Origin Lite: Description
Author : bertman
Score : 194 points
Date : 2022-09-20 13:50 UTC (9 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| bertman wrote:
| I know there have been some threads about the mv3 uBO version
| recently, but this is a new, consise and imho good description by
| gorhill himself.
| syntaxing wrote:
| If this works, is there any reason this won't work as a content
| blocker for safari?
| viktorcode wrote:
| I believe there's none.
| novok wrote:
| It just won't work that well. Recently in the past few months
| I've been noticing more and more ads with safari style content
| blockers, while ublock style continue to work fine. I fear this
| style of 'adblock' will have similar issues.
| webmobdev wrote:
| Switch to Orion browser - https://browser.kagi.com/ - it's a
| Safari / webkit clone with built-in uBlock Origin.
| [deleted]
| Ligma123 wrote:
| Gorhill should have a statue somewhere for making the web
| browseable.
| morsch wrote:
| He really should. I'd pitch in 50 EUR for that.
| throwaway64643 wrote:
| Haha. This reminds me of a Redditor's story. Despite having
| no money to afford professional hardware, he still managed to
| take good astronomy photos using his phone. In one of his
| posts, his photos impressed a "kind stranger" so much that
| they gifted him one of the most expensive Reddit awards,
| whose value can buy him a third of his desired gear.
| baal80spam wrote:
| You bet he should!
|
| To me, there are 3 projects I'd throw my money to:
|
| - uBlock Origin
|
| - ytdl
|
| - The Internet Web Archive
| runjake wrote:
| But, do you donate?
|
| https://archive.org/donate?origin=wbwww-TopNavDonateButton
|
| (Couldn't find links for uBo and ytdl. I've asked gorhill
| where to donate in the past and they've refused donations.)
| jchw wrote:
| Note that you cannot manage your recurring IA donation for
| any reason without manually contacting them. For this
| reason I have not moved my IA donation to my newer credit
| card nor increased my donation since it was set up. I do
| not know if this is a dark pattern or just an oddly limited
| system, but the only officially recommended solution is to
| use PayPal. So I'd recommend that.
| https://help.archive.org/help/how-do-i-update-or-change-
| my-r...
| johnmaguire wrote:
| SponsorBlock is on my list these days too.
| cptaj wrote:
| Not wikipedia? It seems way more important
| von_lohengramm wrote:
| Have you seen how much money they receive and where they
| squander it all?
| sbarre wrote:
| Can you share more information on this?
| icelancer wrote:
| There are fast-growing sections of their budget slated
| for political-like causes, not technical ones that keep
| the website online and accessible. They call it the
| Thriving Movement and it's largely based around DEI-type
| initiatives.
|
| "The Thriving Movement budget has increased from $14.3
| million last fiscal year to $36.7 million in this budget
| which represents an increase of $22.4 million or 157%. It
| has also grown from being 13.2% of the Foundation's
| overall budget to 24.5%."
|
| Not only is more money going into it, a larger share of
| their budget is being allocated to it, so a larger share
| of each donation goes into DEI initiatives. If you're the
| kind of person that does not think this is a valuable
| investment of your money, you might not be inclined to
| donate anymore (or to donate less than before).
|
| I personally believe a 24.5% share of the budget for what
| are largely DEI initiatives is not something I'd prefer
| to support with increasing donations, so I have scaled
| back my donations to them (as well as Mozilla/Firefox for
| the same reasons). I am sure many people agree with DEI
| initiatives and donate more. That's fine. We all vote
| with our wallet.
|
| Source: https://meta.wikimedia.org/wiki/Wikimedia_Foundat
| ion_Medium-...
| capableweb wrote:
| As someone who never heard of "Thriving Movement" nor
| "DEI-type initiaives" before, it seems to be around
| making the workplace (Wikimedia Foundation) more diverse,
| equal and inclusive. At a glance, those seems like good
| things to introduce to global organizations (especially
| foundations) that is supposed to be represented by the
| whole world. But I can agree that it seems like a large
| part of the budget, for being what it is.
|
| But if I understand what you're saying correctly, you're
| saying it's a negative for them to put such a focus on
| it?
| SteeCee wrote:
| If you've ever seen how topics are treated in a Wikipedia
| discussion thread you'd feel like the whole website has
| zero credibility. There's a reason academics don't let you
| use it.
| longtimelistnr wrote:
| The reason is that it is not a direct source of course
| because the authors cannot be validated. Never met a
| college professor that said don't use Wikipedia (if
| anything it was encouraged) as long as you're pulling
| from the citations. I had plenty of high school teachers
| talk about how awful it is though and I think it was
| because they just didn't understand it
| comfypotato wrote:
| I'll take this a step further to say that my graduate
| algorithms professor assigned Wikipedia articles as
| reading. The parent blanket statements are just that:
| overgeneralizations.
| Dwedit wrote:
| The contributors to EasyList should be getting their share of
| credit here. Basically every adblocker depends on them.
| [deleted]
| dang wrote:
| Related:
|
| _uBlock Origin Lite_ -
| https://news.ycombinator.com/item?id=32904591 - Sept 2022 (13
| comments)
|
| _Proxy Chrome extensions are not going to be usable in MV3_ -
| https://news.ycombinator.com/item?id=32899846 - Sept 2022 (199
| comments)
|
| _"UBO Minus (MV3)" - An Experimental uBlock Origin Build for
| Manifest V3_ - https://news.ycombinator.com/item?id=32754274 -
| Sept 2022 (255 comments)
| mrieck wrote:
| How is everyone else's MV3 upgrade going?
|
| I have 3 extensions and each one has multiple feature-breaking
| changes that will take hundreds of hours to implement less than
| ideal work arounds. I guess I'll focus on SnipCSS
| (https://www.snipcss.com) because that's the only one I have
| paying customers.
|
| For people who do manage the upgrade, at least we can look
| forward to less competition in the Chrome Web Store?
| gnicholas wrote:
| Partly cloud with a chance of thunder. I have 2 extensions and
| we've gotten one in sight of the finish line (after months of
| work), and the other appears to be dependent upon some as-yet
| unfixed third-party code.
|
| We are really hoping Google doesn't force this through on their
| originally-announced timeline. This is the third massive
| Google-induced change that we've stomached in the last couple
| years. We spend more time keeping our head above water than we
| do adding new features...
| somehnacct3757 wrote:
| Took us about a quarter heads down to do the conversion which
| involved quite a bit of rewriting. We had been prepping and
| planning for the work pretty much since they first teased MV3
| in 2018.
|
| Now we are figuring out the right way to flip the switch. You
| get stuck in the long review queue every time you flip manifest
| versions, cuz your permissions list has likely changed.
|
| Google's rollout has been the absolute worst; but hey, as you
| say, everyone who can't eat a bowl of shit and keep on smiling
| will simply disappear from the competitive landscape.
| ck2 wrote:
| Isn't the biggest problem with MV3 the 5000 rule limit?
|
| Or are there ways around that by compiling it into something
| internal?
|
| This is how adguard did it: https://adguard.com/en/blog/adguard-
| mv3.html
|
| I'd suggest stop trying to support chrome and let it die?
|
| It won't work on mobile anyway, only Firefox supports ublock
| origin on mobile?
| mirashii wrote:
| > Isn't the biggest problem with MV3 the 5000 rule limit?
|
| Not really, the bigger problems come from the removal without
| alternative of a number of useful primitives that uBlock Origin
| used for blocking. See https://github.com/uBlockOrigin/uBlock-
| issues/issues/338 for a detailed accounting of the changes and
| their impacts.
| SquareWheel wrote:
| The current limit is 30,000 rules, but they've talked about
| raising it further beyond that point.
| hombre_fatal wrote:
| Trivia: 1Blocker convinced apple to raise the limit from 50k
| to 150k per list for Safari content blockers.
| novok wrote:
| My question is why have limits
| hombre_fatal wrote:
| Unbounded lists rarely seems like a thoughtful way to
| start out.
|
| But there are probably some DX and UX improvements over
| unbounded lists. e.g. recompilation takes time, so you
| set up developers for better UX when their dynamic lists
| are shorter and separate from their static lists, and
| they can compile multiple lists at once. (A 50k rule list
| took seconds on my old Macbook Air). Also encourages
| breaking lists into logical sublists which is better UX
| (e.g. regional lists)
|
| Also might discourage append-only accumulation where
| there's no real incentive to prune the list (i.e. see
| EasyList). _Some_ limit can help here.
|
| Kind of like deciding on a queue size vs unbounded: makes
| sense to set a limit, see who hits it, and cross that
| bridge as needed. In Apples case, they 3x'd the limit
| after a real world product made a real world case.
|
| Just some thoughts having built my own Safari content
| blocker.
| tssva wrote:
| "It won't work on mobile anyway, only Firefox supports ublock
| origin on mobile?"
|
| Kiwi Browser which is chromium based supports Chrome extensions
| including ublock origin on Android devices.
| novok wrote:
| Brave iOS has a built in adblock that I find about as good as
| ublock, compared to the ineffective iOS native safari style
| that MV3 forces you into.
|
| So the future for chromium browser based adblock are small
| mini-forks that re-add the proper hooks needed to implement
| adblock properly
| groovybits wrote:
| > I'd suggest stop trying to support chrome and let it die?
|
| You're living in a bubble. If the extension doesn't support
| Chrome, its the extension that dies, not Chrome.
| staticassertion wrote:
| If no one were building an adblocker for Chrome I'd just build
| it myself. I'm sure I'd do a worse job than the people doing it
| today but it'd be better than nothing.
| hombre_fatal wrote:
| Also, there _are_ other adblockers on Chrome. They just
| aren't as good and are sketchier. By pulling the extension
| you just enrich worse actors at the expense of innocent
| users.
| concinds wrote:
| A chance for the return of the Safari extension perhaps?
| viktorcode wrote:
| MV3 version should be directly portable.
| Nextgrid wrote:
| You just need build infrastructure. As far as I know, you
| need XCode to generate the "app" that contains the extension
| (all extensions need to be provided by an "app" even if it
| doesn't have any logic in it), then code sign and upload to
| the App Store. There are open, third-party implementations of
| the code signing tools so it _can_ be done without a Mac but
| it just requires effort.
| SquareWheel wrote:
| The ability to opt-sites in to cosmetic filtering seems like a
| big upgrade. I'm now looking forward to seeing this version used
| in practice.
| kristofferR wrote:
| "Lite" is such a bad name, it's often a positive signifier that
| describes low resource usage/costs. It should have a more
| negative name, like uBlock Origin Reduced.
| FiloSottile wrote:
| The page itself mentions how it consumes less resources, and
| requires less permissions.
| MichaelCollins wrote:
| I agree, uBlock Origin Minus was a better name. "Lite" is
| carrying water for Google.
| flatiron wrote:
| People in HN get a chuckle about the name. 99% of people
| would see it and just download something else that isn't
| "minus" for some reason.
| [deleted]
| AdmiralAsshat wrote:
| The problem is that something pejorative on the surface is only
| meaningful to an end-user that is intimately familiar with the
| limitations of ManifestV3.
|
| If you titled an adblocker "uBlock Crippled Edition", you might
| be protesting Google, but the unfamiliar end-user is just going
| to see it and think, "Well I certainly don't want a crippled
| adblocker! Let me just grab one of these numerous others from
| the appstore that claims it's 100% effective."
| MichaelCollins wrote:
| > _The problem is that something pejorative on the surface is
| only meaningful to an end-user that is intimately familiar
| with the limitations of ManifestV3._
|
| You don't need to be "intimately familiar" with the
| limitations of ManifestV3, a casual understanding, from
| perhaps an explanatory note in the description of the
| extension, is sufficient to understand such a name.
| melony wrote:
| Your average user has no interest in Google politics, nor
| would they bother to read through the explanation. Most
| people install an adblock to block ads. The politics of
| internet browsers and privacy only matter to power users.
| [deleted]
| zinekeller wrote:
| It was indeed named "uBO Minus", but what do you expect from
| Google? Accept that name?
| some_furry wrote:
| Why not name it uBO Neutrino?
|
| It has the connotation of being "Lite" since they're low-mass
| particles. And it sounds vaguely like "neutered", which is
| what MV3 attempts to do to ad-blockers.
|
| (That being said, this description from gorhill looks great.)
| novok wrote:
| I would call it "uBO Reduced". Reduced resources, reduced
| permissions, reduced capabilities, reduced effectiveness in
| actually blocking ads, trackers and content.
| postalrat wrote:
| Why would they reject it? Is it offensive?
| jjulius wrote:
| >... it's often a positive signifier that describes low
| resource usage/costs
|
| Third sentence:
|
| >This means that uBOL itself does not consume CPU/memory
| resources while content blocking is ongoing -- uBOL's service
| worker process is required only when you interact with the
| popup panel or the option pages.
| hombre_fatal wrote:
| Sounds like a plus for manifest v3 then. Fewer resources,
| fewer permissions, to do most of the same task.
| deathanatos wrote:
| Adding support for a less-resource intensive API to filter
| is fine. The problem people have is the destruction of the
| more powerful APIs to permit the fine control that UBO
| requires, to do the job proper. There was no need for that,
| there was no trade-off1 being made.
|
| 1of technical concerns.
| bornfreddy wrote:
| I'm really really _really_ hoping that the non-crippled version,
| which works in Firefox, doesn 't die the way uMatrix did (loved
| it, still miss it). That said, huge thanks to gorhill and all the
| others working on this project!
| staticassertion wrote:
| I guess the biggest issue I have with V3 is I don't really "get
| it".
|
| The idea was initially that extensions have too many privileges
| and that malware can leverage those privileges for harm. I'd
| _love_ data here! This is such a good area to share information
| on, as someone in security I 'd really value that.
|
| I'd like to see case studies on malware, or even broad things
| like "malware uses these permissions X% of the time".
|
| But back to the point, assuming that this is true, how does V3
| help? Specifically, what can malware _not do_ with V3 that it
| could do before? Given the data, how will this impact the threat
| landscape?
|
| I can think of some obvious things, like that you can't have
| dynamic scripts - cool, makes sense, I bet malware loves that and
| removing it seems like it'd be a huge win.
|
| But WebRequests? I'm sure malware was using it, I guess, but what
| in V3 makes the _malware use case_ for it harder? It seems like
| we 're getting something that can be used maliciously just like
| before, but it's somewhat weaker in ways that malware won't care
| about? Again, data here would be great. I'd love to see "X% of
| malware used it this way, we removed that way".
|
| Communication has seemingly been pretty bad around the
| motivations, which has led to a lot of people being pretty upset
| and confused about the changes.
|
| Google, please share the data and reasoning!
|
| edit: With regards to uBlock Lite specifically, I'm looking
| forward to seeing it evolve. I do like the idea of having a
| permissionless blocker that works decently and can then have the
| opt-in approach. I don't honestly consider it a massive security
| win though.
| tyingq wrote:
| The reason you don't get it is that taking away the functional
| part of onBeforeRequest() doesn't really help with privacy.
| Because extensions can, for example, still inject arbitrary
| javascript if those permissions are in the manifest.
|
| What it really does is ensure that adblockers can't do
| heuristics, and instead have to rely solely on semi-static
| lists of urls. That's a nice outcome if you're a company that
| makes most of their money from ads.
|
| There's not really a nice way to say that aloud though, so
| trying to make it sound it's a way of ensuring extensions honor
| privacy and security sounds better.
| staticassertion wrote:
| Yeah, I said this in another comment, I don't really believe
| that to be the case. I'm not saying that a conflict of
| interest doesn't exist, I just don't believe that this move
| is part of an overall plan to have Google start bypassing
| adblockers.
| krackers wrote:
| Most bad extensions I've come across when trying to vet what
| I'm installing fall into two categories: those that are
| passively malicious: inserting redirections to affiliate links
| (or sometimes randomly spawning ad), and those that are
| "actively malicious" by scanning for browsing history and then
| sending that over to be sold off.
|
| I guess the general idea of manifest v3 is to limit the
| page/extension boundary to being declarative in nature. I
| haven't looked into this too much to know how restrictive it is
| in practice, but at least one such thing is that webRequest is
| neutered so extensions can't run their own logic for request
| pre/post processing (where they might try to obfuscate/disguise
| the target redirect), instead they have to declare the list of
| redirect targets upfront, where presumably they can be scanned
| by trivial static analysis.
|
| While I think there is indeed a problem of malicious
| extensions, I don't believe that manifest v3 is the solution.
| Switch to a more granular but still non-declarative permission
| model might be useful to gain a stronger signal on malicious
| extensions, or maybe requiring web store extensions to be
| declarative but allowing "power-users" to still manually
| install non-declarative extensions.
| BrianGragg wrote:
| Maybe I'm out of touch but I think the 'malware' they are
| worried about are ad blockers.
| staticassertion wrote:
| I don't think so. That gets repeated a lot but I think people
| are just unaware of the fact that Google ads are particularly
| uninvasive and easy to block. If ad blockers are less capable
| that will only help Google's competitors, not Google. Another
| comment the other day confirmed that Google's ads continue to
| be blockable with V3.
|
| This could change - AdSense ads could start implementing
| bypasses. I think that's unlikely because Google would likely
| end up with a few lawsuits, questions about browser
| monopolies, and a congressional hearing. Certainly the EU
| would be on their asses. One day that may change, but I don't
| see this move as being part of any specific plans to improve
| AdSense revenue.
| ssth wrote:
| > That gets repeated a lot but I think people are just
| unaware of the fact that Google ads are particularly
| uninvasive and easy to block.
|
| Not true in my experience, i have encountered adsensw that
| pretty invasive to my 2012 laptop's cpu core i3 gen3 (i
| know its pretty old), i dont think any ads should be that
| way.
| staticassertion wrote:
| I don't know what you're trying to say - the ads you're
| running into are explicitly working to bypass your
| adblocking?
| e40 wrote:
| What I don't get from this is how uBOL (MV3) compares to uBO
| (MV2). Anyone?
| skyfalldev wrote:
| Since MV3 adds quite a lot of limits on what uBO can do, you
| have to grant permission for each site to have cosmetic
| filtering.
| nottorp wrote:
| So we need to build something external to the browser that
| will detect uBlock Origin asking for permissions and
| automatically grant them :)
|
| Edit: doesn't this mean that any site you visit will get a
| chance to track you the first time, until you manage to click
| to grant permission?
| forgotusername6 wrote:
| From the blog post on how adguard built their v3 extension
| the ads themselves are blocked but aren't removed from the
| page if the cosmetic filters aren't run
| SquareWheel wrote:
| That limitation has nothing to do with MV3. Adguard does not
| suffer from this problem. Making it opt-in is a specific
| design consideration that gorhill took with this version of
| uBlock to reduce its permission scope.
|
| I wish people were not so quick to share misinformation like
| this.
| nightpool wrote:
| I'm really happy that Gorhill has listened to feedback on the
| branding and explanation of this, and added back in the ability
| to "opt in" to extended permissions on individual sites. Thank
| you for your work, and I'm sorry if my comments in the preview HN
| thread came off as overly hostile, because given the original
| comments you made about MV3, I couldn't imagine this sort of
| outcome. I hope that you or someone else still works to release
| an MV3-compatible "Full site permissions" version of uBlock as
| well, since I think there are a lot of potential options for
| improvement by using declarativeNetRequestFeedback, and it's
| certainly more convenient to not have to opt-in. And I'm still
| worried that without an MV3-compatible version of full uBlock
| Origin, users are still going to assume that "MV3 means that ad
| blockers are broken".
| vntok wrote:
| Can't wait for the Chromium team to land the new permissions GUI
| so that all that whining around how MV3 is the end of uBlock
| Origin can stop. Many here will look silly overnight when that
| happens.
|
| See here:
| https://bugs.chromium.org/p/chromium/issues/detail?id=113549...
|
| > We have always intended to provide support for this
| functionality in Manifest V3 (for both user-installed and force-
| installed extensions), and have been iterating on different
| possible approaches. Our tentative plan (which is not yet
| finalized) is that the Manifest V3 version of this capability
| will require extensions to request a new permission scoped to
| intercepting authentication requests, but will otherwise allow
| extensions to handle these requests in a similar manner to how
| they do in Manifest V2.
|
| > The permission string and end user facing warning string have
| not been finalized yet. Also, we have not yet finalized how this
| new permission will interact with other permission grants, but
| extensions that currently have the webRequest permission and
| broad host permissions will likely not require an additional
| grant for this permission.
| yyyk2 wrote:
| Why even pretend like MV3 isn't meant to cripple adblockers so
| Google can extract more revenue from their advertisement
| business?
| mirashii wrote:
| The MV3/UBO issues are not really at all related to this ticket
| or GUI. The thing people take issue with is the removal of a
| number of mechanisms for intercepting and blocking traffic that
| uBlock Origin uses.
|
| https://github.com/uBlockOrigin/uBlock-issues/issues/338 has a
| more detailed list of issues.
| vntok wrote:
| If you have a look at the bottom of the discussion in that
| link:
|
| > The redirect-rule= filter option is also not compatible
| with DNR redirect action due to differing matching algorithm.
| In uBO, redirect filters do not compete with block/allow
| filters, as the redirect directives are looked up only after
| a network request has been matched to a block filter,
| whichever that is. This works differently in the DNR matching
| algorithm, redirect rules compete with other block and allow
| rules.
|
| > The no-large-media-elements feature can't be implemented as
| this requires to inspect response headers on the fly.
|
| > There is no concept of exception modifier filters in DNR,
| i.e. csp=/removeparam= exceptions cannot be accurately
| translated to DNR rules. For a specific example, all the
| removeparam= filter exceptions from AdGuard URL Tracking
| Protection, meant to override the main
| _$removeparam=utm_source filter, can 't be converted to DNR.
| At best, those exception filters maybe could be less
| accurately be excepted using the excludedRequestDomains
| property of the main _$removeparam=utm_source filter.
|
| These issues are all fixable by acting as proxy and
| inspecting/modifying/replacing requests on the fly (in
| sync/blocking mode).
| Semaphor wrote:
| Isn't that unrelated as it's about the proxy issue and not the
| adblocking issue?
| aendruk wrote:
| What happened to the name "uBO Minus"?
| tech234a wrote:
| https://github.com/gorhill/uBlock/commit/93e5133783301c0329b...
| return_to_monke wrote:
| Why was it controversial, tho?
| enlyth wrote:
| Quoting gorhill from a GitHub conversation:
|
| "Side note about the experimental uBO Minus MV3 extension:
| I did not pick the Minus part out of spite, it's to make
| clear that this is not uBO proper and I want to be sure
| there is no expectation that this will be the case. I
| picked Minus for the same reason that the Plus in Adblock
| Plus was to highlight that this was an improvement over the
| previous Adblock version.
|
| Now the fact that uBO Minus does not require broad
| read/modify data on all websites can be seen as an
| improvement over uBO proper by many people who are
| uncomfortable with granting such broad permissions to an
| extension. In that case, if you have a better qualifier
| than Minus, I welcome suggestions."
___________________________________________________________________
(page generated 2022-09-20 23:00 UTC)