uBlock Origin Lite: Description
github.com
github.com
I mean, they are hobbled. If you think of it like a malware scanner, it's the equivalent of taking away all heuristics and relying solely on big lists of payload checksums or "bad words".
Otoh, with full permissions it can still do things like hide ads that aren't blocked by the declaritive rules. But, to continue the analogy, that's like killing a process after it's doing malicious stuff instead of preventing it from running in the first place.
They currently are when compared to their MV2 counterpart.
The AdGuard MV3 version which came out earlier this month[1] shows this. Though it does its best to deal with the technical challenges which comes with MV3, the end result is poor efficiency- and reliability-wise compared to its MV2 counterpart.
This is easy for anyone to see: open the browser's own Task Manager (Esc-Shift works) and notice how the service worker associated to AdGuard MV3 is regularly (every few seconds) evicted and respawn.
When it re-spawns, the process's CPU and memory usage peaks, with memory usage shooting up to between 100-200MB. This happens repeatedly every few seconds or whenever you navigate to a new webpage.
CPU/memory efficiency has always been a primary feature of uBO, and I can't release an MV3 version suffering such efficiency setback (this on top of matching algorithm not being fully compatible with that of uBO).
However I am willing to work on an MV3 version which does not suffer no CPU/memory efficiency issues, hence uBO Lite, which takes advantage of new possibilities in MV3 to be fully declarative, at the cost of sacrificing some capabilities.
---
But I agree that the heuristics for when to evict certain extensions (especially those with broad all-page access permissions) definitely remains tricky, and I hear you that Chrome's are currently too severe for this type of extension to be practical. I don't think that's a fundamental problem with the service worker model though—it seems easy to add a heuristic to cover this case like "If the extension has a async network request event registered and there's an active tab open that that extension has permissions to view, be very cautious in evicting it". In that case Chrome could still want to evict the service worker i.e. if the tab/browser is in the background and paused[1], so that it wouldn't be handling event loop / network requests anyway.
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?
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.
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...
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)
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.
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.
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.
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.
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.
I don't know what else they would really gain, or why else onBeforeRequest() was the most important thing to take away when extensions have so many other ways they can do harm.
Perhaps another way to look at it is not Google actively defeating adblockers, but giving a gift to their customers that pay for ads...making it easier for those customers to deal with the rising tide of adblockers, paywall end-arounds, etc.
This assumes that Google's ads will start to bypass the V3 adblockers. V3 in and of itself does nothing, Google's ads are still blocked by the updated adblockers.
> I don't know what else they would really gain
Well that's what I'm asking haha I'd like to hear from them on this. Even if some people at Google are nefariously implementing V3 for some future plan to bypass adblockers, surely some people at Google believe that there are benefits to the work.
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?
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.
And before you say, but app store review!, I also think that is bad too.
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.
Kiwi Browser which is chromium based supports Chrome extensions including ublock origin on Android devices.
You're living in a bubble. If the extension doesn't support Chrome, its the extension that dies, not Chrome.
So the future for chromium browser based adblock are small mini-forks that re-add the proper hooks needed to implement adblock properly
brew install orion"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."
`xcrun safari-web-extension-converter <extracted chrome extension directory>`
It'll create an xcode project and you can run the mac app from there. Safari will need the "Allow Unsigned Extensions" from the Develop menu set before it'll show up in the prefs page. No idea how it all works if you want it on iOS.
Fuck Chrome, for a moment. It sounds, to a layman, like an arbitrarily established API for web engines to expose to extension developers.
In other words, it isn't HTML5 or HTTP4. Each browser chooses whether to use it.
If it is such shit, why is Firefox doing it?
Firefox has always extended the manifest API and will deliver more functionality than required by the spec to give extensions more flexibility.
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?
I wish people were not so quick to share misinformation like this.
For some reason people are just itching to spread FUD about this topic and Google in general. I don't understand where it comes from or why it happens but it's really annoying.
With MV2, uBlock is able to inspect the DNS record while it is vetting the request, thwarting this workaround.
Not in Chrome-based browsers. Only in Firefox.
professional astronomy photos is an activity where the low end starts very expensive. Basic setups are in the thousands of dollars.
(For context: Reddit awards don't give the recipient anything except the ability to browse Reddit without any banner ads, and access to a special forum. If you make a big Reddit donation to someone, you're actually donating to Conde Nast, Spez, etc)
To me, there are 3 projects I'd throw my money to:
- uBlock Origin
- ytdl
- The Internet Web Archive
"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_Foundation_Medium-...
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?
I'm just not interested in funding those initiatives at that percentage of budget and would rather send the money to other essential Internet companies who have lesser investments in those ideas. I still give some to Wikimedia, just not as much.
In my experience, the Wikimedia Foundation seems to be the one who is most transparent about where funds go, while organizations like Internet Archive doesn't make a lot of data public, at least via their own website.
Also, Wikimedia may not be as transparent as you think. Here's more information on that, but the whole thread is worth reading.
So Wikimedia is a non-profit AFAIK, you have any idea why it's not listed on charitywatch.org?
https://www.charitynavigator.org/ein/200049703
EDIT: However it is not updated for recent years. Likely because Wikimedia is not transparent enough with their financial statements.
The road to Hell is paved with good intentions. If I were a cynical man I might speculate that it's not because things that look good don't get scrutinised as much but that anyone wanting less scrutiny might try painting their aims as "good" and those who object as therefore "bad". But I digress. Wikimedia's mission is[1]:
> to empower and engage people around the world to collect and develop educational content under a free license or in the public domain, and to disseminate it effectively and globally
What does DEI at their workplace have to do with that?
[1] https://en.wikipedia.org/wiki/Wikimedia_Foundation#Mission
+ Dark Reader
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.)
That said:
- IA doesn't even offer cancelling. That's... not a particularly technically challenging feature. I have a strong feeling that they in fact have a cancel button somewhere in their backend anyways.
- While some of this can be annoying, it's kinda table stakes these days. If you can't handle basic subscription functionality, god help you for things like 3-D Secure.
This is a non-starter for me.
> No donations sought.
> Without the preset lists of filters, this extension is nothing. So if ever you really do want to contribute something, think about the people working hard to maintain the filter lists you are using, which were made available to use by all for free.
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.)
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.
¹of technical concerns.
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."
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.
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.
https://github.com/uBlockOrigin/uBlock-issues/issues/338 has a more detailed list of issues.
> 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).
That is not possible in MV3, and is the center of the entire problem.
Note that per its author himself, uBO Lite on MV3 already does the vast majority of the work uBO was doing on MV2, largely enough for regular non-power-users people.
If Google actually wanted to cripple adblockers, why wouldn't just ban them outright and remove addons used for adblocking purposes from the Chrome extension store, or completely remove APIs that allow for content blocking? Why would they develop a new extension API that still allows you to block ads at all?
Why isn't it possible that the new APIs might have actual benefits and exist for legitimate reasons?
I understand that companies suck and exist solely to serve themselves, and I fully support being skeptical, but I think users here are way too quick to jump on the hate train and start slinging FUD. Maybe you are right and Google is trying to cripple adblockers, but I'm not so sure yet and would like to see others at least consider an alternative perspective.
They already did all this on the most popular version of Chrome. It seems very reasonable to assume their desired state is to match that version across all platforms.
Crippling enough that most people won't notice is a viable business decision. Introducing a security benefit, inserting a self interest(crippling adblocks while providing vastly inferior alternative) which won't be noticed by most people but they are being secretly compromised behind the scenes since less ads are blocked and are being tracked more effectively is a profitable business tactic. Bringing a benefit along with a profit tactic compromising customers and pretending the said compromise is as big of a detriment to the consumer, which it is not, is whats going on. Is this so hard to see? Its not a FUD but the profiting parties trying to sway the opinions.
I doubt it from market share of Android Chrome https://gs.statcounter.com/browser-market-share/mobile/unite...