I notice a pretty marked difference between the best ad blocker I could find for iOS (1 BlockerX) and uBlock Origin on Firefox.

The difference in utility is stark enough that if I'm on the road and need to browse the web outside of known-safe sites, I find it more pleasant to do so on my 5.7" Android phone than on my 10" iPad.

What are some sites where ads get through with 1Blocher?

It's not just ads, it's also not having the ability to only allow 3rd-party scripts and frames via whitelist.

Since I don't use Safari for "normal" browsing, I can't recall any specific problematic sites, but just opening some random news headlines I get the following unwanted behaviours, roughly half of which are nags to install the iOS app:

* theverge.com - nag to disable ad blocker

* nbcbayarea.com - nag to install app

* youtube.com - nag to install app, autoplaying video, all the rest of the junk that YouTube annoyances blocklist blocks for me with uBlock: https://youtube.adblockplus.me/

* lifehacker.com - annoying animated recommended story gif (to be fair this isn't an ad-blocking issue, it's just a configuration setting that Safari doesn't offer)

* bloomberg.com - nag to install app, nag to subscribe

* forbes.com - nag to install app

* observer.com - autoplaying video ad

* twitter - app nag, login/signup nag

I’m not getting some of the app install nagware, but I’m also not getting them when I disable content blockers so it may just be a cookie thing. Also I couldn’t manually block the nagware on the NBC site using the share extension.

I only use YouTube mostly for official AWS videos and then I use CornerTube. I usually don’t see ads. Do content producers get to choose when ads are shown?

> Do content producers get to choose when ads are shown?

That's my understanding. Also a mostly non-YouTube user though, I find the web interface really unpleasant - if I were going to "use" it on a regular basis I'd probably use youtube-dl.

IOS allows you to change rules on the fly. The chrome proposal says they are static and unchangeable, other than whitelisting specific pages. You can't, for example, add or delete a rule. The only way to change rules is to submit a new version of your extension.

One assumes that wasn't an accidental design flaw.

No need to look at motives. The end result matters, and the end result makes it as crippled as Apple's solution. Luckily, Android users will continue to have other options.

Privacy invasive options which kind of defeats half the purpose of ad blockers.

And those “other choices” only work within the browser. Apple’s ad blocking framework works with apps that embed web views using the SafariViewConttroller like Feedly.

We have a product for this. Consumer shared Adblock VPN. Or dedicated cloud or local builds for businesses. https://ba.net/adblockvpn

And non-privacy invasive options. Your point is a very poor one. Android users can use options that are worse than iOS options, the same as iOS options, or better than iOS options. Most will use the last category, as you would expect.

Android also supports blocking ads throughout the system, not just in WebViews, which is the only option on iOS.

Can you guarantee that your ad blocking framework is not recording and selling your data or be sold to another company that will?

You can buy VPN subscriptions that serve as ad blockers outside of the App Store and just go into settings and configure it yourself. Preferably, host your own VPN host on your computer where you know no third party is intercepting and recording your traffic.

Most ad blockers that people use on Android are open source, e.g. uBlock. While due diligence is good, I don't think I've seen any evidence that would suggest gorhill wants to sell my data. You can't compare an ad blocking extension to an entirely different browser (Brave) as a whole. uBlock runs on regular old Firefox for Android.

I appreciate that it would be nice if Google gave us the option to block stuff in Webviews, but it's not a replacement for having a real ad blocker like uBlock that is much more complicated and has many more features. I think the person you are talking to is mainly criticizing Apple for not letting you use such an ad blocker on their OS.

What are these extra features? I asked earlier about posting a link to some pages where ads aren’t blocked by 1Blocker but are blocked by Firefox + extension.

Right like most users are going to build their own apps and install them. Also, are you going to personally audit every line of code?

That's not how it works.

I'm also not saying that it's perfect, but it is clearly better than Apple's alternative, which you have not disputed.

You just said you have reproducible builds. Either you are going to audit the code and do the build yourself or you are still trusting a third party.

I think you can agree that being able to see the code, and detect patched builds, makes it much more risky to pull something like this.

What percentage of people have the requisite knowledge to do that? The Heartbleed bug was in open source software for over a year before anyone noticed it.

This could be avoided by only running programs written in safer languages. C/++ allows for very very hard to spot bugs that can cause serious issues like heartbleed. You would have to try a lot harder to hide such a thing in a haskell program .

Since all five widely implemented platforms (iOS, Android, MacOS, Windows, and Linux) and most mainstream open source software is written in C, that would be a tough lift. Also since there are far more people who know C than Haskell, that kind of gets rid of the “many eyes” defense.

There may be fewer people able to read haskell but I would say fewer are needed to verify that a program doesn't have unexpected behavior. Also languages like rust are becoming bigger which should help.

Sure there is a lot of C floating around but there is a solution in sight and there is some amount of effort being put in to rewriting things in Rust.

You don’t have to trust the ad blockers. The operating system won’t let ad blockers have access to your browser history. If you want to see how the ad blocking framework on iOS, you are free to go over to WebKit.org.

You really think people are auditing all of the open source software you are using? Where were they the year and a half the HeartBleed bug was out in the wild?

So a vulnerability that affects a phone with 12% market share if you downloaded an infected app is larger than a bug that affected all Android phones and all you needed was a phone number?

https://en.wikipedia.org/wiki/Stagefright_(bug)

And since Android phones both have a horrible security model and a horrible history of receiving updates, any malware or security issue is made worse.

Even though 95% and 99% of phones were vulnerable and many never got patched, there was really no problem because few were affected?

I live in a neighborhood that has never had a reported break in. Does that mean I’m not more vulnerable if I leave my door unlocked and post a huge sign outside letting everyone know?

There are many layers of security in modern OSes. Apple ignores many of them to the peril of their customers, and it shows in the results. In your example, many Android devices left the door unlocked but had a security guard. Apple locked the door but the lock on the door allowed many other keys to work.

What security guard? There was no security that kept Android from being vulnerable. It would have been just as easy for someone to infect the Android build chain.

Even if you look at something like the way that third party keyboards work on Android, it’s a security nightmare.

On iOS, users have to explicitly go into settings to add a third party keyboard and even then it doesn’t have network access by default. The user has to go back into settings to enable the keyboard to have network access and then they get a big scary warning. Android users happily install keyloggers.

Also, even after you both install the keyboard and give the keyboard network access, iOS still switches back to the default keyboard when entering passwords.

> What security guard? There was no security that kept Android from being vulnerable.

Blocking exploits in the Play Store, among other things. Why do you think Stagefright was never exploited?

> It would have been just as easy for someone to infect the Android build chain.

We were just talking about reproducible builds.

> Keyboard nonsense.

Android also displays a scary warning for keyboards.

Stage fright didn’t involve having an app in the Play store. The review process is non existent, and static analysis tools wouldn’t catch it anyway.

> Stage fright didn’t involve having an app in the Play store.

If the MMS app and the browsers were updated to filter Stagefright exploits (on Android, unlike iOS, system app updates do not require an OS update and happen through the Play Store, one of many things Android gets right and iOS gets wrong), the only way to exploit it is by publishing your own app to the Play Store and getting somebody to install it and hoping that the device doesn't have an selinux policy that limits the privileges of the exploit. The Play Store can trivially block apps that don't use an approved wrapper library for media that filters Stagefright exploits.

Back then the built in Web view that apps embedded was built into the OS as was the browser. You remember that Chrome wasn’t the browser for apps back then.

Also, what’s the differences between updating the OS from Apple’s servers and hypothetically updating an app from Apple’s servers. Are you trying to turn a weakness that Google can’t just press a button and allow every single Android worldwide to receive an OS update into a strength?