> However, uBOL allows you to explicitly grant extended permissions on specific sites of your choice so that it can better filter on those sites using cosmetic filtering and scriptlet injections.
Which I would expect allow it to work as well as uBO.
Note that there are still some adblocker workarounds that will foil MV3, such as CNAMEs. uBO will always be more effective than MV3, unless some substantial improvements are made to MV3.
For people not understanding how it works: you can set a CNAME entry on your tracker.domain.tld to bypass all Browser's third-party tracking preventions, and make it look like it's a normal subdomain of your website.
You need to make a CNAME tracker database manually by resolving the reverse entries for known IPs. Usually there is hundreds or thousands of CNAME entries pointing to the same IP address.
The AdGuard team also made a database for this, in case anyone needs it for UBOL [1]
Most, if not all of those trackers use assets that they serve from there (like a tracking pixel gif socket), so I highly doubt that uBOL will catch those; because the cat and mouse game is now in the ad tracker's favor and it is impossible to keep up now. And that was the intended purpose. We now have to play our hand with marked cards.
How so?
Because it shifts the contractual obligations and the "legitimate interest" of data to a seemingly first party, which all companies seem to think they can get away with.
Well, until the tracked subjects do a reverse DNS lookup anyways.
you are allowed to track some information first party for certain purposes without user agreement (e.g. fingerprinting for DDOS protection) but you are ONLY allowed to use it for that purpose and have to use _as little data as possible, store it as short as possible_ etc. You also still have to inform the user about it, give them a way to delete it (through because you also have to keep that data as little and as short as possible you often delete it faster then the time you have to process such deletion requests so that tends to be a non issue)
this section of GDPR pretty much never applies to anything ad related ever, because even if you collected some fingerprints for DDOS protection you MUST NOT use them for ads, not are you allowed to pass them to anyone else especially not if that entity does use them for something else.
pretty much nothing in the law text of GDPR ever implied you might get away with aliasing tracker domains, actually very clearly the opposite
generally GDPR is not technology specific, so pretty much any case of "this technical trick to work around GDPR limitations" is pretty much not legal as long as the trick is not to not collect data
I am just stating the trend of ad tracker technologies, and how useless the Datenschutzbehoerde is in practice, from the perspective of someone that builds a browser network that tries to uncover these types of constellations.
because from what you posted above it clearly seemed you don't understand GDPR
people which don't know anything about the topic might come to believe that using CNAME is an actually legally working workaround instead of just a way to hinder ad-blockers
No. The migration to CNAMEs has to do with the phasing out of third party cookies. The GDPR literally does not care about how the technology works.
nonsense
GDPR is not technology specific weather you use aliases or not makes not difference (neither weather you use cookies or other e.g. heuristic methods for fingerprinting btw.)
You can still write a unsandboxed extension with MV3 (and in Firefox it will still be able to intercept requests, while in Chrome it will not be on the network hot path) but the point is that you can also write a permission-less ad-blocker now, which is what I want.
Chrome is deprecating it with v3, Firefox supposedly no.
I guess deferring updates would give me lead time to let others get targeted / detect an issue before it's likely I would get the update. Still, installing the permission-less version is so much simpler and reassuring.
If there is something big enough to warrant quick update, my HN addiction will make sure I find out about it before it is a 1day.
There really isn't a great configuration for browser security rn, is there? The gold standard I think is Qubes, which afaict is not practical.
This is a total non-sequitur. The source of all malicious browser extensions is Google, Apple and Mozilla, and none of them have demonstrated any willingness whatsoever to fix the problem, even when a mere grep across their distributed extension base can trivially identify all the various openly advertised trojan SDKs that cause millions of users to be tracked or have their internet connection reused for various shady proxy websites.
You are not speaking for all users and you know it.
It's my understanding that because uBlock Origin is a "recommended extension", it must undergo a formal code review each time a new update is published. A malicious update would not face zero obstacles.
https://support.mozilla.org/en-US/kb/recommended-extensions-...
You can just decide for each case the tradeoff between advanced blocking and security.
- one thing that is much less powerful is cosmetic filters, which means ads may be replaced with gray squares if uBOL can't remove them entirely
- less filters overall, because the limits on how many filters are possible are pretty strict
- extension updates will be both larger and much more frequent because filter lists can no longer be updated separately from the extension
I can not give you an exact number, but it is massively bigger than the number of trackers / elements that any usable web page can realistically implement. Probably you can do several thousands database calls in less than a second due to indexing; and that can be further optimized by doing it in batches, bringing it up to tens of thousands, if not in the hundreds on modern PCs. It is literally not an issue.
I'm sure it's fast but if people want unlimited number of rules that number could start exploding.
They didn't, Google did. It is part of MV3 specs, afaik.
The only apparent upside to this version is if you don't trust Raymond Hill to refrain from spying on your browsing sessions via his add-on. By every other metric this seems like a downgrade.
However, it's true some websites (like YouTube) are especially problematic and a declarative adblocker is not enough. What you can do is combine both approaches: use a declarative adblocker (uBlock Origin Lite) as a baseline, and selectively enable non-declarative adblockers (uBlock Origin) for specific websites (see [2] for a detailed overview).
I like this layered approach because it gets you the best of both worlds: the security and performance of a declarative adblocker, and the functionality of a non-declarative adblocker when you need it, without compromising your entire browsing session.
[1] https://portswigger.net/research/ublock-i-exfiltrate-exploit...
[2] https://seirdy.one/posts/2022/06/04/layered-content-blocking...
Say I open HN on my morning coffee and open 5 links in new tabs. They don't have to be to sites I've opened before. I will be tracked until i go to each tab and add it to uBlock Origin.
How is that an improvement?
-- https://support.mozilla.org/en-US/kb/tips-assessing-safety-e...
*May* is important here. That is also what I remembered changing years ago.
I was sort of aware but your post clearly reminds me that Firefox extensions are probably my single biggest point of general vulnerability on my phone and computer, given how much is done in browser.
Appreciate your original thoughts either way.
a regular user would not have the capability to audit an update. A power user, with entirely too much time on their hands, could of course, but one should not be designing systems based on such niche scenarios.
Essentially, there's an issue of hypocrisy in the threat model and type of user proposed.
Yes, maybe that is some weird kind of fear of missing out (on security), but I have a hard time ignoring security fixes, even without details.
Yeah, but is this really a risk for anyone who isn't the sort to have installed Bonzi Buddy back in the day?
That attack surface, compared to that of brew, npm, pip, gem, etc., is miniscule. And browser plugins don't yank in obscure dependencies at install time.
I only run uBlock, and I suspect I'm in the majority here, and my choice of browser is predicated on the availability of a non-crippled ad blocker, because malicious ads are the primary threat.
(as noted by fsckboy): uBlock was the original name for the add-on that subsequently was ethically compromised/"sold out to" advertisers
uBlock Origin is the 2nd version written by the original author (gorhill) and is not compromised.
How is the FDE story on macOS? Isn't it closed source - how can you tolerate that as a cryptographer? (Not saying Linux is perfect, cryptsetup doesn't have a secure AEAD mode)
You asked how someone can trust a crypto implementation that isn’t open source. I replied to the to it directly: it actually is open source. Personally I see the source being available largely irrelevant but I replied to exactly what you asked for.
Your second question is an entirely different topic, which is how you can trust that something isn’t backdoored. Notably, this has nothing to do with whether source is available. How I would typically do that is by inspecting the compiled artifacts themselves, which is the same whether the code is available or not. Of course, this requires that the OS or the AP or the crypto engine isn’t backdoored, for which there exist more involved verification processes. Whether this is possible to do in general is a difficult research area. It is, however, completely divorced from your view on how this works because auditing the properties you’re looking for does not rely on source code at least in a traditional sense.
It isn't like the average hard disk permits padding oracles and chosen plaintext/ciphertext attacks to be mounted easily, except of course if you are storing disk images in the cloud, but then you're using the wrong tool anyhow - do crypto at the file level where you aren't constrained by sector sizes.
Really, I'd say that 99% of the uses of block device encryption would be better served by using a filesystem that supports encryption natively. The remaining 1% is for block devices that handle the encryption in the hardware.
Manifestv3 will have negligible improvements on potential security risks and will significantly decrease overall security.
Yah, probably not a lot of HN users falling for it, but I was constantly surprised by the demographic. I’d regularly see smart, accomplished people get bamboozled by ads. It’s wild.
Why would you even have autoupdates in the first place if that is your threat model?
Good on you nonetheless to check one less, but the one still open is much larger, so the fight goes on.
MV3 is safer, but so is running no adblocker at all. There is a tradeoff. I get much more ads on Safari+AdGuard (iPhone) which uses MV3 or some similar declarative approach, than on Firefox+uBlock-Origin where I get basically none.
I still prefer to trust one extension like uBlock Origin, just like I trust other software packages on my system, and to really fend off all the web tracking nonsense.
Can you or someone else elaborate way it would be more secure? I dont quite follow or see the benefit.
But it also comes with costs. The browser is less customizable and further locked down. That reduces possibilities without netting advantages for me. Overall this is security FUD in my opinion. And the negatives can be observed in mobile OS.
Firefox—my daily driver—still supports the "main" uBlock Origin (and I'm a somewhat heavy user of features unavailable in Lite like custom filters), but I had been waiting for Lite to be available and immediately went ahead and replaced uBlock Origin with uBlock Origin Lite.
The security win can't be understated: with its permission-less design (enabled by MV3) I am down to zero third-party developers that can get compromised and silently push an update that compromises all my web sessions. Sure, attackers could still get into Mozilla, Apple (as I run macOS), or cause a backdoored update to be pushed via Homebrew (how I install unsandboxed applications when no web app is available, which thanks to the likes of WebUSB is getting less common), but unsandboxed browser extensions were clearly the lowest hanging fruit, so this update (and MV3) significantly raised my security posture (and transitively that of projects I have access to, and that of their users).