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.
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).
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.
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.
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.
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.
Larger question, not just confined to the world of iOS ad blocking; as the creator of ad-blocking code, are you at all concerned that you're hurting the only revenue stream for sites that rely on ad revenue to pay the bills?
We're not just talking the big boys here, a bunch of indie content producers publish online and I don't begrudge them a few ad dollars for producing content that's worth reading, or is it that we're making the call that content should be free or is inherently value-less?
It's definitely a concern, especially since I run a side project for STEM education that has ads[1]. My site doesn't break even at all from ads, but they help offset the running cost (revenue is in the single-digit dollars-per-month range). Ad revenue has fallen greatly though for sites displaying ads, I believe owing to the fact that online ads have been found to be much less effective at driving sales than they were once thought to be (though they may still buy mindshare). Current ads are more flashy, more annoying, and are a greater source of frustration. On desktops that's one thing, were the cost of viewing the ad is largely paid with your attention. On mobile though, they take up even more attention but they also use expensive mobile data and drain precious energy from the battery.
I'm not sure of how things will look in the future, but it will probably be a more heterogeneous mix of funding sources. We'll see more subscription-based sites, we'll see more sites run as cashflow-negative hobby projects, and we'll still see ads. We will also certainly see another category: sites the sell your info for money. We'll see sites that combine all of these. I suspect we'll also see more content distributed solely in app form, with in-app purchases buying more content. Since operational costs have fallen and continue to fall, the world won't look so different for a while. I think the best model for consumers is one where ads are the default, and a cheap subscription can be paid to remove them. Microtransactions are an alluring solution, but no one has really made them work yet. There is also a growing trend of sponsoring content before it is created, via sites like Patreon.
Do you want a whitelist in the sense that you want to see ads on certain websites, or that you want to see specific ads?
In the case of the latter, a whitelist is planned (mostly to correct for false positives). In the case of the former, it's not possible technically since I'm not proxying anything, and the whitelist acts on the request domains ads are coming from not the domains in which they are embedded.
Interesting. Did you restart Safari before trying it in iOS9?
I haven't tested it yet in iOS9 yet because the VPN system doesn't work in the simulator, and I haven't installed the beta on my personal phone yet since I value stability. Once iOS 9 is out to the public I'll do some testing and make any updates necessary.
I hadn't, but just tried restarting safari, restarting device, and clearing safari history/data - and still having the same output.
* I'm completely fine with this being the case. Before installing I was completely unsure if it would work for iOS9 before trying (not expectant with it still being beta, but simply curious as it's an interesting approach).
I hadn't seen that; thanks. I like their comic book explanation.
It looks like their VPN profile is not included with the app though, and is instead sourced from their website[1]. That means that a) Apple has not inspected the block list (they specifically asked me via the resolution center to list which domains were blocked), b) that the VPN profile is subject to interception or changes of control since it is sourced from a website, c) that updates to the block list require a new download of the block list from their website, d) that an uninstall of their blocklist requires the installation of a new (presumably blank?) blocklist, and e) when you uninstall their app, the VPN profile remains on the device (it is removed upon uninstall of MadBlocker).
Thank you - this is a wonderful thing to have on mobile. I hate going from my home wifi, where I use squid guard + blacklists, onto LTE. This seems to catch most of the crud and the performance hit is acceptable.
That's a valid question, and it is always the challenge of closed-source software; it's a black box. So you either have to trust me, or you could have your iPhone connect to a wi-fi access point on a network you are monitoring and check for requests to anomalous domains. You could also probably install it on a managed iOS device and then inspect the VPN profile with Apple Configurator.
Right, and in iOS9 the features to allow ad blocking are built in to Safari, not iOS. Since MadBlocker works at the OS level, it can also block ads in (most) other apps as well. I believe it should work fine with iOS 9 too.
Right, I get it. That's logical but this is Apple we're talking about who used vagueness and distortion of their rules to outlaw stuff like this in the past.
Keep in mind that Apple have their own ads network as well, another reason why I'm surprised they'd allow this in the first place.
That may be an early bug, my apologies. You should be able to enable both. Please message me at the email listed in my HN profile and we can troubleshoot.
using a dummy proxy is another approach to this problem. This is how Weblock works, which I'm pretty happy with. It seems to have almost no overhead on the device, though it only works for wifi connections.
I guess it has to do with mobile carriers wanting more control over your connection. The same way that you can't change your DNS when on a mobile data connection, you can't specify a proxy server (except through a VPN profile).
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.