[1] - https://www.youtube.com/watch?v=VqHA5CIL0fg [video][10 seconds]
It's because they were literally sued and are not allowed to remove it, not because they don't want to.
I have a simple tab organizer extension and some greasemonkey scripts that should work perfectly fine on Firefox without any changes.
I think Firefox is the only viable solution to continue using UBO at this point.
What does that mean? Firefox uses the same API. At most you have to change `background.service_worker` to `background.scripts` (literally just rename the key)
Plus I personally consider ads a cancer of modern society. White and not so white lies, manipulation... nothing respectable regardless (or because ) of tremendous money circulating in it.
1) Google-owned sites seem to just chew CPU on Firefox. In particular I'm thinking of GMail and Youtube, both of which I'm a heavy user of, and also Maps. But no non-google sites seem to have this problem.
2) I'm constantly getting websites saying "This is your first time using this device, are you sure you're you?", and I haven't tried whether it's better on Chrome, but it's pretty crazy because I've literally never used your stupid site with any other device, and I used it with THIS device just last month you idiots. I'm just blind guessing that this is some kind of problem as a result of Firefox privacy choices, like maybe the site doesn't know how to use cookies in a way that doesn't trigger anti-tracking. For example banks.
But Firefox can keep thousands of tabs open at once (thousands. plural. not kidding, not exaggerating.), it has working uBO, and the frequency of "just because we wanted to" UX changes is much lower. It's just a better choice all around.
secushare[1] makes the case that this is because the internet lacks a secure micropayments layer, so the funding model for everything has to be advertising-based instead of patronage-based. Paypal and the like are exploited as cash cows because of their centralized nature. Cryptocurrencies were later tried but have technical limitations that broadly prohibit this use case (even with payment channels/LN).
Even in torrents you have private trackers and all of these annoying incentive systems for people to host content. If you had a good reward system on top of bittorrent/IPFS I think that idea could take over the world, but it is not efficient or decentralized to do so.
Normally when you visit contentsite.com which serves ads from adsite.com. Adblocker rules can just block adsite.com and the ads won't be shown. CNAME cloaking would have the main site have a subdomain like adsite.contentsite.com point to adsite.com, now the adblockers have the impossible task of blocking millions of subdomains that seemingly belong to legit sites, this also allows the legit sites to keep changing the subdomain since the adblocker will have no idea which subdomains serve legit content vs ads. As a bonus since the content is being served from the same domain, they can bypass certain cookie browser policies and track users even better.
This update allows you to set rules so that you can filter by resolved ip.
My dream scenario would be this happening to an in-company administrative user with the keys to the kingdom. Imagine an ad-ridden site like Fandom.com getting hacked in that way.
Now that thanks to EU laws and browser imposing restrictions about third-party cookies it's more difficult, the whole "serve ads from other domain" may not be that relevant anyway.
If you use a random wildcard subdomain... just serve them from the main website, what is the difference? On the other side with a proxy just route the AD requests to another server if it needs to be, of course you have to find a way to distinguish which requests are for AD and which are not, something you can do with some sort of signature in the filename, so that only the server can know which requests shall be handled locally and which one forwarded to the AD provider server.
How much of the efficiency of online advertising comes from the actual "art" of tracking users and their preferences to display "personalized" ads vs the "efficiencies" from firing/outsourcing your marketing, ad sales and creative workforce.
selling ad space was always a lot of work. algorithms do it cheaper and in general better.
next step is just to run a GoogleAds lib/proxy...
I'm not surprised there are people who prioritize the latter, especially for small sites where they may not have someone who fully understands the risks.
Edit: A combination of DNS CAA with an account identifier restriction in the record would prevent this. Then the advertiser would complain, and any ads served would have to be over plaintext, which would cause browser warnings about mixed content and allow MITM injection of (more) malicious content.
And yeah, I can trivially block stuff in uBO by using CSS rules for example, so that's still on the table.
Higher impressions? Higher integration cost? I guess I'm not sure what the confusion might be. Advertisers obviously want to ram their bullshit down as many eyesockets as they can find.
They could have become the dominant advertisers online too, and then no doubt they'd be just as nasty. But they lost that war multiple times, first to doubleclick-likes and then to social media.
That said, the average person's conception of what acceptable needs to change. I did briefly think that they need suffer through more ad-infestation first, but I realized that the answer is more in line with what my wife seemed to have gone through. The low exposure to ads made her less willing to deal with them. This might be the way forward.
It is hard for a person used to existing ecosystem to even imagine, there could be something better.
It will be interesting when this kind of technology moves down to browser add-ons.
Most of the web works. Anything that does not, and I care about, gets blessed.
The only content I allow by default, even in low-security browser profiles, and even from first-party domains, are HTML, CSS, and images.
I consider the occasional broken page to be a successful test of my configuration. If I care, I adjust permissions.
(I guess ad providers have gotten good enough to not need cookies? Like they know my browser window size, installed fonts, GPU vendor and model, IP address, geolocation, header order, etc. so they don't even need cookies anymore to track my activity across the web? I suppose it was only a matter of time.)
It's somewhat scary how much information our browsers leak to unknown parties.
(I don't really take sides on this. I use an ad blocker and am very anti-ad, but am impressed when ad companies come up with tech to thwart them. The cat-and-mouse game is entertaining to read about.)
It's a war of escalation with advertisers. Google is the arms dealer to both sides. They won't give you what you would need to win.
Of course, this all relies on browser vendor (Google) wanting to add this API. Doing this imperatively with "live code" allows for innovations in userland before browser makers add built in support for it.
Had they not taken away onBeforeRequest with manifest V3, plugins could implement it themselves. Which is the thing you're suggesting...before the request goes.
>The change allows early availability of ip address so that `ipaddress=` option can be matched at onBeforeRequest time.
It is using some other functionality, on Firefox only, to get that early availability. But I'm saying Chrome is a non-starter since onBeforeRequest is hobbled there. So the "early availability of ip address" doesn't help. You need both.
Technically manifest v3 has nothing to do with APIs that the browser makes available to extensions. On firefox manifest v3 is supported with blocking web request[1], which is the filtering api prior to "manifest v3". Therefore the statement that it certain functionality "by definition" is false.
[1] https://blog.mozilla.org/addons/2022/05/18/manifest-v3-in-fi...
Here's the design document. The hobbling is noted there as part of the spec. "API Changes WebRequest: Restrict the blocking capabilities of the webRequest API."
https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3Nzz...
That firefox chose to skip that portion of the design and still call it 'v3' doesn't change history. A true-to-spec implementation kills live heuristics.
To block those ads, blocklists that uBlock Origin use have rules then that say "block requests being made to the domain name A-ads-tracking.example", which blocks the ads.
CNAME cloaking is where SAAS provider A sets up their ad-tracking services not on domain A-ads-tracking.example, but instead at a specific IP address of e.g. 29.1.2.3; then (and here's the important part) SAAS A tells you Company Q that you need to set up a subdomain of q-company.example which has a CNAME record pointing to 23.1.2.3, a subdomain with an innocuous name like media.q-company.example; once you've set up that CNAME, you at Company Q add a script tag to your website for `media.q-company.example` and now SAAS A is able to track all the users on your site. This indirection allows for effectively infinite cat-and-mouse on the part of you the owner of the Q Company vs the blocklists that the public assemble.
To get around this CNAME cloaking problem, the software powering extensions like uBlock Origin need to be able to see not only the destination domain of requests by browsers, but the underlying IP addresses of those domains as well. This commit makes that behavior possible, or at least is related to making that code work better.
Browsers might not offer intermediate DNS names to extensions (I don't know), so something like uBlock might need to rely on IP lists, but DNS-based filtering like pihole should just block it by a rule against `ads-tracking.example`. In any case, it's good to use both browser based and DNS based malware blockers.
https://developer.chrome.com/docs/extensions/develop/migrate...
https://www.bleepingcomputer.com/news/google/google-chrome-w...
https://github.com/gorhill/uBlock/wiki/Dashboard:-Settings#u...
I think that's around 2021 time frame. FYI.
https://brave.com/blog/brave-shields-manifest-v3/
Not that you really need it as Brave has its own very capable built-in ad blocker with -- last time I checked -- higher performance than uBO (since it's compiled into native code) and full support for same ad lists.