Actual extensions (like ublock!), bleeding edge/experimental web features like new webassembly or web APIs (firefox and chrome usually implement these before Safari does), stuff Apple has decided to sabotage because it threatens the app store (like fullscreen).
> But on the other hand, if you care about your privacy, why would you trust a third party to intercept all of your web traffic?
uBlock Origin is free and open source, and its code is thoroughly reviewed by many contributors every release. I trust uBlock Origin over a filtering mechanism built into a closed source browser such as Safari.
WebKit may be open source, but Safari is not. The interface to access Safari's content blocking settings and the platform on which Safari content blocking extensions are built are both closed source, so your FUD about "intercepting web traffic" would be more appropriately directed at Safari than at uBlock Origin.
Yes, I have personally downloaded the uBlock Origin source code. I have also reviewed the code and suggested improvements. However, I don't even need to download the code to realize the benefits of uBlock Origin being free and open source. Even if I hadn't downloaded the code, there are many other users and contributors who have reviewed the code, and you can confirm this by taking a simple look at the activity in the GitHub repos.
So you think there is sone great conspiracy and that Apple is secretly tracking your web browsing history. But it only happens when you install a third party extension that sends it a bunch of JSON rules and that it went through the trouble of having two content blocking implementations that work ‘em the same way - one in Safari and one in WebKit?
My point is that because uBlock Origin is free and open source, anyone can see that it is not tracking users maliciously. On the other hand, Safari is closed source, so your FUD would be more applicable to Safari. There is no easy way for users to verify how a closed source browser such as Safari implements its content blocking. In terms of transparency, uBlock Origin is strictly superior to Safari.
You're changing the topic. You originally accused developers other than Apple of maliciously intercepting web traffic. I responded that your FUD is actually a greater concern with the closed source Safari than the free and open source uBlock Origin. What you're saying now about ad blocking coverage and web views is completely irrelevant to the invalidity of your original argument against an open browser ecosystem on iOS.
You are comparing a “web blocker” to a “browser” you are also waxing prosaically about how much better is and failed to show any examples.
The fact is that your ad blocking extension won’t work at all within embedded web views.
We know for a fact that a third party ad blocking extension can not intercept your web browsing history on iOS whether it is open source or closed sourced. It has no access to your web browsing history.
Your assurance comes from open source, mine comes from knowing that my third party as blocker doesn’t have any access to my web browsing.
The comparison is between Safari + Safari-compatible content blocking extensions and other browsers + fully-featured content blocking extensions (such as Firefox + uBlock Origin).
You have been spreading FUD about fully-featured content blocking extensions like uBlock Origin, which is not a very good argument because Safari itself is closed source and its behavior is opaque. A combination of Firefox + uBlock Origin is fully free and open source, and its behavior is fully and easily verifiable. It is absurd for you to criticize combinations such as Firefox + uBlock Origin when the combination of Safari + a Safari-compatible content blocking extension is clearly less transparent due to Safari being closed source.
Apple's anti-competitive App Store restrictions are preventing the superior combination of Firefox + uBlock Origin from existing on iOS. Fortunately, regulations will soon make some of Apple's anti-competitive restrictions illegal in some major markets.
uBlock Origin not being able to protect web views on iOS is yet another restriction imposed by Apple. If browsers on iOS were able to supply web views to other apps and activate extensions in those apps, as the Custom Tabs feature works on Android, uBlock Origin would have no issues blocking content in iOS web views. Don't blame uBlock Origin for a restriction that Apple created.
The difference is, webkit doesn't have an army of angry weaponised nerds that will go out of their way to remove every single unwanted pop-up and ad imaginable the second they appear.
Yes because people who care about unwanted advertising and tracking by a phone with an operating system built by an adTech company whose default browser doesn’t allow any type of ad blocking…
You are always welcome to run arbitrary JavaScript in the page. However, this does not mean the APIs other extensions use to block resource loads will work.
So it went from “it only supports JSON” to “yeah it supports more. I just don’t know if it will actually work. Because I haven’t looked into it’s capabilities”
That's a different question than was being asked. The current API does not really allow for anything like uBlock to exist. I expect if Chrome moves to a similar interface sites will start serving ads that 1Blocker will not be able to stop.
I said what I meant to say, I've literally drafted web standards before and Safari is often the last to implement them. I'm not talking about WebUSB or WebGoogleAnalytics or whatever
Don't forget about the times where Safari implemented standards wrong, or changed the standards after the fact.
Viewport units have been around for a decade now, and Safari still can't get them right.
For example:
Let's say we want to make a chat window, where a user can type in an input field at the bottom and little message bubbles appear above. Sounds like a job for flexbox and viewport units.
Okay, we'll have one flexbox div container with it's children being the chat messages and the input which get aligned to the bottom. Now we'll position the container so it takes up the full page using viewport units (e.g. take up 100% of the viewport's width, and take up 100% of the viewport's height).
Oh no! When the user scrolled through the messages, the browser's tab bar appeared and instead of calculating that 100% of the viewport is 100% of the viewport, the viewport isn't being updated, and now the input field has been scrolled out of the page.
That's okay, we'll just use the new dynamic viewport units which specifically account for the problem that Safari had invented, and which only took 8 years to come out.
Okay looks good, time to send a message.
Oh no! When tapping on the field input, now the keyboard covers up field so we can't see what we're typing.
>_<
Good work Safari...
Real good work...
When I say I want something to take up 100% of the viewport, I mean 100% of the viewport.
MediaSourceExtensions (https://caniuse.com/mediasource)is one good example of a useful API which has been supported by roughly ~every browser for years except for safari on iPhone.
On that page it says that media source was implemented in 2014, on year before Firefox and Edge.
I guess in your world "every other browser" is Chrome. And, sure enough, there are some parts of the API that are only implemented by Chromium-only browsers, and are not implemented by either Safari or Firefox.
