Hacker News Reader

Comment by tomkinstinch | Hacker News Reader

Creator here. Happy to answer any questions!

I created this as a proof-of-concept to show that we don't have to wait for iOS 9 to block ads on iOS. MadBlocker uses a hack of the VPN subsystem to block ads, by redirecting requests for ad domains to a bogus local DNS address. Unlike some of the current iOS ad blockers, it doesn't use an external proxy, so no data leaves the device. I also included block lists for tracking scripts, since they're a problem too. Since it works at the OS level, and not via Safari it also blocks ads in (most) apps. It should continue to work fine in iOS 9 as well!

I have some promo codes I can give out too if you'd like to give it a try. If you want one, please just email me at the address listed in my HN profile.

View on HN

Can you explain a little more how this works? Can specific requests be routed to a specific connection in iOS, at the device level?

If it's a "hack", won't the possibility be blocked by Apple eventually?

Also, you say on the App Store page that using a big list can slow down browsing, as (I'm paraphrasing) the app has to scan each page against the list; why is that the case? Shouldn't request be redirected the moment they are made, and not before?

Great idea in any case! Will probably try it, as many sites are already almost unusable because of ads (and when using Chrome on iOS the problem gets worse; Safari must block more by default).

It's only a hack in the sense that is using the VPN system in a way that it was not originally intended. It is only using documented public iOS APIs.

To answer your request in more detail: it makes use of a feature that has been around since iOS 7: VPN On Demand[1]. The idea behind VPN On Demand is that requests can be routed to different VPNs (or accessed normally) based on the hostname of a request. This is useful if you get an email from work that has an intranet-only accessible website. Clicking on the link could load a connection to the company VPN for only that work domain without also sending all of your personal traffic through the company VPN. In the case of MadBlocker, I just direct requests for ad hostnames to a bogus local IP, and the ads never load.

That said, while it works in Safari and in most apps, it may not work in apps that implement their own networking or DNS retrieval, which Chrome seems to do.

> Shouldn't request be redirected the moment they are made, and not before?

Yeah, that is what happens, but since every request is checked against the list (since we don't know a priori which request is for an ad), it can take noticeable time on sites that include assets from many external domains (if using the "mega" list or depressingly-long privacy protection list).

1. https://support.apple.com/en-us/HT203743

I'd really need some data to be convinced.

e.g. videos showing popular pages loading quicker, load times measured and compared, CPU etc.

Like this one: https://github.com/chrisaljoudi/uBlock/blob/master/README.md...

(blocking is important, but it doesn't worth it if it makes things slower for example)

It's still worth something if the request doesn't go through, and the radio doesn't waste energy transmitting advertisement information. For me faster page loading is not the motivation for blocking ads: I don't want things vying for my attention, and I don't want ads taking up mobile data or energy from the battery. If you care about page speed only, make your own decision about whether or not to use the app. Feel free to contact me for a promo code.

Here's a demo video of MadBlocker in action:

https://www.youtube.com/watch?v=es11BPfUxIM

You could quantitatively test battery then.

Why is your App trying to install a root certificate alongside the VPN settings? Is that certificate unique per device?

MadBlocker uses the VPN subsystem for filtering, even though the traffic doesn't leave the device. In order for the VPN profile to work with the On Demand VPN system (used for sending ad domain requests to 127.3.5.7), it has to use cert-based auth, and MadBlocker is using a self-signed certificate so I could use a reasonable expiration time (ten years) without paying a ton of money for a cert signed by a commercial CA. It seemed silly to pay for a cert that sees no use. I had actually used a proper cert earlier in testing, but figured people would get frustrated with the one-year expiration time.

Allright, makes sense.

But does it not mean that you could basically spoof any secure connection (provided you could establish a man-in-the-middle)?

Just wondering, since the VPN destination is not easily verifiable: What stops you from shipping a profile tomorrow that directs traffic towards your server for online banking sites and breaking the TLS encryption using that root certificate?

If the cert is not trusted for server auth and doesn't have the CA flag set, it can't be used this way. Certs are also used to authenticate to VPNs, and can be trusted only for that purpose.

I was surprised to hear it's a root cert. Any pointers on what to look for in the cert details windows on iOS to check if that's the case?

Will you make the App available in other countries? In the Dutch App Store it's currently not available...

It should be available everywhere, and I just confirmed via iTunes connect that it is theoretically for sale in the Netherlands. I'm guessing that since it went live this morning it has not yet had a chance to appear on all of Apple's CDN. Hopefully it will be available to you soon!

You might also try searching for it by name on the Dutch App Store.

Reply on news.ycombinator.com