Hacker News Reader

Comment by danpalmer | Hacker News Reader

There seems to be a lot of misinformation about Apple’s stance in this thread.

Apple explicitly allows and provides APIs to develop content blockers.

Apple does not allow content blocking through custom VPN implementations, seemingly because these a) introduce a performance impact, b) may be confusing for users as it’s abusing the point of VPNs, and c) may allow more easy abuse, as VPNs can do a lot more than just block content. This is what the article linked as evidence for Apple’s policy covers, and the statement provided by Apple, while not especially clear, does match up with this.

I think the title should be reverted to remove Apple, as they do allow ad blockers on the store (I personally use 1BlockerX https://itunes.apple.com/gb/app/1blocker-x/id1365531024?mt=8 )

View on HN

The linked app is a Safari-only adblocker which doesn't cover apps, so I feel the title is pretty accurate. There have been full system ad-blocking solutions developed for iOS and apple refuses to host them, it's a statement of fact.

`a` is permitted for other apps; `b` is, as far as I know, not a criteria anything else gets judged on; and `c` is the point of having a curated store, because any app "may allow [...] abuse".

It's not strictly "Safari only*. It works with any embedded web view that uses the SFSafariViewController.

For instance, ad blocking also works with Feedly - my RSS reader.

That's a rather uncommon exception. Very few apps load ads in a web view. Mainly because, imo, the ad platforms want a lot more user data than they'd get that way. And fraud would be a bit harder to detect.

And hey fuck users, the ad platforms are the real good guys in all this right?

So instead we should install an untrustworthy intermediary that can record all of your internet data (the VPN), and do God knows what with it?

Isn't that all of them? It was my understanding that Apple forbids any non-Apple web view.

There are two modern web views in iOS. The SFSafariViewController is an out of process view. The hosting app doesn't have access to the DOM or what the user enters. The user has access to all of the same cookies, saved passwords, and ad blockers that they would have in Safari. The other (WKviewController?) is your standard embedded web view. It doesn't share cookies, passwords, etc and the embedded app has more access to the web view.

The latter is WKWebView https://developer.apple.com/documentation/webkit/wkwebview

As of iOS 11, cookies are no longer shared between SFSafariViewController and Safari or instances of SFSafariViewController in other apps.

Why stretch the facts to make it seem like Apple is allowing system-wide ad blockers? You seem to concede repeatedly it doesn't, yet argue that as long as Safari is covered, even when hosted in 3rd party apps, it's the same thing?

How am I "stretching the facts" by stating the technical limitations and benefits of Apple's approach (i.e. not introducing a third party that can potentially track all of your internet activity)?

This isn't theoretical. iOS apps were in fact storing and selling data that went across the ad blocking VPN solutions.

Ad blocking Chrome plugins have a sordid history. Why would I trust them on my phone when I can set up my own solution relatively easily?

The IOS solution for in browser plug ins is more secure and it protects your privacy.

Sure, you also get it in embedded safari views. You still can't block apps in ads, you can just block ads in content your apps show, usually incidentally - those ads in the feedly view are not _Feedly_'s ads.

I can honestly say that I have no apps with embedded ads. If it's an app I'm going to use, I pay for the no-ads in app purchase. If it's an app that doesn't allow me to pay for a no ads version or that's not worth paying for, I uninstall it.

There is one exception. Overcast, my podcast player. There is a no ads in app purchase, but the ads are usually for other podcasts in the same category that I'm listening to. The ads are actually useful.

https://marco.org/2016/09/09/overcast-ads

Only VPN apps doing regular VPNs are allowed, obviously they have a performance impact, but that’s necessary for what they do. Anything using a VPN to implement other behaviour is not. Apps get judged on usability when it comes to system level concepts like VPNs all the time - keyboards are an example where there’s a lot more review for usability and “playing nicely”.

Not quite true. Charles Proxy uses a VPN in order to inspect network traffic, and that was approved. But I think in the general case what you said is correct and that Charles Proxy's approval is an exception.

True. I wonder if that’s because it’s explicitly a developer tool, and developers will understand what’s going on, and the risks/benefits of using a VPN.

I think the main reason they block apps using VPNs for other things is that it’s very easy for them to break internet on the whole phone with buggy software, and Apple don’t want lots of support time at the Genius Bar of turning off crappy ad blocking VPN apps.

It's probably partially that, and partially the fact that the VPN usage here is obviously beneficial. The information doesn't leave the device and it doesn't interfere with the normal workings of the apps (like ad blocking does). There's no reasonable complaint to levy against what Charles Proxy is doing. Versus ad blocking, which many people think is beneficial but which is clearly detrimental to app developers (especially when they end up blocking more than just ads, as sometimes happens).

Indeed, Apple is significantly worse in this regard. Both Amazon and Google devices allow you to install system-wide ad blockers from other sources.

Amazon does not allow you to install anything from other sources without hacking the device.

Sure they do. My Fire HD tablet has a simple option in Settings-->Security & Privacy-->Apps from Unknown Sources. I have a number of F-droid apps installed. I also have the Play Store hacked in, but F-droid only required downloading the app from the web. Standalone APKs can also be installed.

What makes you say that? It is clearly false.

Apple's move against device-level ad-blocking came coincidentally soon after the news regarding Facebook using a non-FB branded VPN to gather user data.

Walking the line between the pro-privacy aspects of VPN ad blocking and the the very anti-privacy possibilities that such functionality enables isn't easy. There's nothing to stop any VPN from scary levels of metadata collection, but Apple did close the door to one way of promoting or selling these services.

App devs hate hearing this, but I've always found it interesting that Apple doesn't try to take a cut of ad revenue that apps receive. And yet they insist on taking a cut of "tips" and pretty much any other revenue stream. I'm glad they don't because it would put them in an adversarial position with privacy.

I guess they tried with iAds, but even that was going to be optional I believe.

> There's nothing to stop any VPN from scary levels of metadata collection, but Apple did close the door to one way of promoting or selling these services.

What I do now -though on Android- is using WireGuard as VPN to my home router which runs basically a Pi-Hole (and WireGuard).

The benefits:

1) I get a system-wide adblocker on top of uBlock Origin.

2) My mobile provider cannot perform DPI (Though its owned by same company as my cable company. YMMV, plus it will work when you roam internationally. Heck, I can perform DPI on it via my router.)

3) When on a public WiFi (e.g. railway station) all my data is encrypted.

4) When I switch networks it automatically swaps connection.

5) Far less performance hit and battery usage than traditional VPNs such as OpenVPN. Home router also barely uses any Watt.

Brilliant software, I can highly recommend. My only beef with it is that a full blown SDN such as ZeroTier is a lot easier to set up.

Which router are you using that runs wireguard?

I recently acquired an Edgerouter-Lite (EdgeOS / Linux MIPS), with a RPi (Raspbian / Linux ARM) behind it also running WireGuard/ZeroTier/Tor (WG in case I need more horsepower on the ER-L). WG works on OpenWRT as well, though ZT doesn't work on EdgeOS (there's an obscure Linux MIPS *.deb somewhere but the c++ lib is too out of date on EdgeOS). [1] OPNSense is in the works [2], and also runs ZT. If you're not afraid to build your own I can recommend PC-Engines APU2 + OPNSense [3]. For me it'd cost too much time/effort to build/maintain, YMMV.

[1] https://www.wireguard.com/install/

[2] https://forum.opnsense.org/index.php?topic=8758.0

[3] http://www.pcengines.ch/apu2.htm

Thanks. I have a similar setup, with Edgerouter X and rpi running pi-hole. I hadn't realized what Edge route can run wireguard, thanks. I've been thinking about running VPN on the rpi since pihole barely uses any cpu but have been procrastinating, might have to take a relook.

This isn't true :/

Easiest way to address the claims, let me know if you need a more detailed breakdown: Note Facebook's VPN is still available - they're just not allowed to advertise it blocks ads, which they never did in the first place.

There is no misinformation about it. Apple has made it clear to the system-wide blockers developers that this was happening because of ad blocking.

There are still a lot of apps using the VPN API for additional purposes. For instance, AdGuard Pro for iOS is still there, and it lets users use DNSCrypt or block domains manually. The difference is that it does not do system-wide ad blocking by default.

I don’t think they’ve made that clear at all. To me it seems they’ve made it clear they don’t want misuse of VPNs. The fact they provide APIs to do ad blocking across all web content says that they are very much ok with it.

I note from reading AdGuard’s App Store description that it seems to do as blocking with the content blocking APIs, and uses the VPN only for DNS changes.

Blocking ads system-wide with DNS filtering (intercept dns requests, block ad and tracking domains) is exactly what AG was doing before the policy shift; and it is still able to do it, but now the default blacklist is empty because of Apple.

Right. So now it is NOT a VPN ad blocker. It’s an ad blocker using the system frameworks, plus a VPN app that allows finely grained network customisation, one use case of which is ad blocking, but not one that the app itself encourages. That fits my hypothesis.

Reply on news.ycombinator.com