←back to thread

Bypassing Google's big anti-adblock update

(0x44.xyz)
1034 points deryilz | 1 comments | 12 Jul 25 19:06 UTC | HN request time: 0s | source
Show context
al_borland ◴[12 Jul 25 20:51 UTC] No.44545060[source]▶
Even if bigs exists to work around what Google is doing, that isn’t the right way forward. If people don’t agree with Google move, the only correct course of action is to ditch Chrome (and all Chromium browsers). Hit them where it hurts and take away their monopoly over the future direction of the web.
replies(26): >>44545103 #>>44545185 #>>44545382 #>>44545931 #>>44545951 #>>44546164 #>>44546522 #>>44546599 #>>44546664 #>>44546763 #>>44547531 #>>44548200 #>>44548246 #>>44548399 #>>44548418 #>>44548820 #>>44549698 #>>44550098 #>>44550599 #>>44551061 #>>44551130 #>>44551663 #>>44553615 #>>44554220 #>>44556476 #>>44571602 #
high_priest ◴[12 Jul 25 20:58 UTC] No.44545103[source]▶
Its not happening
replies(4): >>44545238 #>>44545244 #>>44545297 #>>44545919 #
Etheryte ◴[12 Jul 25 21:16 UTC] No.44545238[source]▶
I don't know, I switched to Safari and it was painful for like two hours and then I stopped thinking about it. The only thing I somewhat miss is the built-in page translate, but I don't need it often enough to be bothered much.
replies(3): >>44545267 #>>44545318 #>>44545577 #
Fire-Dragon-DoL ◴[12 Jul 25 21:18 UTC] No.44545267[source]▶
I find switching from chrome to safari essentially doing nothing. If you switched to a non-big-company owned browser, it would make sense but Apple has plenty of lock in which is as bad as chrome lock in.
replies(4): >>44545301 #>>44545310 #>>44545579 #>>44545945 #
creato ◴[12 Jul 25 22:03 UTC] No.44545579[source]▶
It's especially silly in this case because Safari extensions have always been equivalent to MV3 functionality.
replies(1): >>44545735 #
lapcat ◴[12 Jul 25 22:31 UTC] No.44545735[source]▶
This is not accurate. Safari had webRequestBlocking functionality from 2010 to 2019 and indeed a version of uBlock Origin for Safari. What is true is that Safari was the first browser to ditch webRequestBlocking, replaced by its Apple-specific static rule content blocker API.

Otherwise, though, Safari still supports MV2. Everyone seems to think webRequestBlocking is the only relevant change in MV3, but it's not. Equally important IMO is arbitrary JavaScript injection into web pages, which MV2 allows but MV3 does not.

MV3 is so locked down that you can't even use String.replace() with a constructed JavaScript function. It's really a nightmare.

Google's excuse is that all JavaScript needs to be statically declared in the extension so that the Chrome Web Store can review it. But then the Chrome Web Store allows a bunch of malware to be published anyway!

replies(1): >>44547423 #
rasz ◴[13 Jul 25 04:11 UTC] No.44547423{3}[source]▶
There must be ways of injecting custom non static js because mv3 version of tampermonkey works https://chromewebstore.google.com/detail/tampermonkey/dhdgff...
replies(1): >>44549596 #
lapcat ◴[13 Jul 25 11:44 UTC] No.44549596{4}[source]▶
After dragging their feet for literally years, Google finally implemented a specific userscripts API. However, the implementation was initially just statically declared rules like DeclarativeNetRequest, which sucked, and it also required that the user enable developer mode.

In Chrome 135, which is very recent—the public is currently on Chrome 138—Google added an execute() method to run an individual script. However, the API is not available from the extension content script, so if it needs to be triggered from the content script, you have to make an async call to the background script (or more accurately, the background service worker, which is a whole other nightmare of MV3). Moreover, the API accepts only a string for JS code or a filename; you still can't use a Function() constructor for example.

In Chrome 138, the current version, Google switched from developer mode to a dedicated userscripts permission toggle in the extension details, which is disabled by default. I think Google is still working on but has not finished a permissions request API. Remember this is almost SEVEN YEARS after Google first announced Manifest V3. The entire time, Google has been stalling, foot dragging, practically getting dragged kicking and screaming into doing the least possible work here.

replies(1): >>44553959 #
1. rasz ◴[13 Jul 25 21:36 UTC] No.44553959{5}[source]▶
Iv been following https://github.com/Tampermonkey/tampermonkey/issues/644 since 2020. I remember a moment in 2021 where Google came out with this ridiculous notion of User code stored on User computer and executed by User Agent being "remote" because it wasnt under Google control, but somewhere around 2022 things started clearing up and Jan Biniok managed to get a working mv3 version a year ago in May.

Surprisingly this async serialize/deserialize nature of the API (https://github.com/Tampermonkey/tampermonkey/blob/cdfc253c07... ?) somehow still manages to inject and execute scripts fast enough to make them act like content scripts at document_start. The only problem is no arbitration between extensions, cant force Tampermonkey inject before uBO (tons of adblock filters disable functions required for Tampermonkey and effectively kill Tampermonkey in the process).