Comment by Fire-Dragon-DoL 2 days ago
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.
Orion is the only viable option on iOS IMO. The fact that, to this day, Safari has no way to block ads on iOS means it's just awful. Before Orion, I avoided using my web browser like the plague, because the experience was just bad.
Now I'm on Android, and Ironfox is pretty good and Firefox is also available. The browser story on Android is leaps and bounds ahead of iOS.
I find the "switch to Safari" talk amusing because the adblockers available for Safari are functionally equivalent to the MV3 API that everyone's complaining about. The problem with the "static list of content to block" approach that Safari and MV3 use is that you can't trick the site into thinking that ads have been loaded when they haven't, like MV2 allows via Javascript injection. The effect of this is that you'll run into a lot of "disable your ad blocker to continue" pop-ups when using an adblocker with Safari, while you won't see them at all when using an adblocker with Firefox.
I've never used these, but if I had to guess: these probably don't have the same power as full Manifest V2 extensions.
Also names like "Adblock Plus" scare me. I don't want someone I don't trust getting my web activity.
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!
There must be ways of injecting custom non static js because mv3 version of tampermonkey works https://chromewebstore.google.com/detail/tampermonkey/dhdgff...
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.
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).
I don't think in this case your argument is as clear cut and the use cases that people have today arent solved by the choices out there.
George Carlin: "You don't need a formal conspiracy when interests converge. These people went to the same universities, they're on the same boards of directors, they're in the same country clubs, they have like interests, they don't need to call a meeting, they know what's good for them and they're getting it."
The interests of APPLE (who makes money on hardware, and credit card processing) don't align with the interests of Google (who makes money on ad's). I am all for open source, I'm all for alternatives. But honestly if you own an iPhone and a Mac then safari makes a lot of sense. I happen to use safari and Firefox on Mac and am happy to bounce back and forth.
I also keep an eye on ladybird, but it isnt ready for prime time.
And I'm still going to have a chrome install for easy flashing of devices.
No company sells your data. They sell access to you based on the data they have about you. Apple is no different
I'm a huge fan of Orion by Kagi: you should have a look! It's a little rough around the edges but the extension support on iOS is amazing.