This is part four in a four part series on content blockers in iOS 9. Read part one, part two, and part three.
I’ve been writing a lot this week about content blocking on iOS 9, and a large part of that is because the coverage for content blocking has largely been negative. I think a lot of that negativity is less about content blocking, and more out of the fear of losing of income from the chief income source for most sites. And since almost all of the sites rely off of ads to make money — it would be near impossible for any of them to cover content blocking with objectivity.
That said, this site, only relies on membership for income, so it is in my best interest to do things to attract members. I also have a long track record of being privacy conscious and loathing ads in general. You are getting a fairly opposite view of advertising, as I neither need it, or like it.
So far I have covered just the apps: which are the fastest, which are the most full featured, and which save you the most bandwidth. With those things out of the way, it is now time to talk about what content blocking is, how it is done, and the ethics surrounding the usage of content blocking.
What is Content Blocking
Content blocking is not the same thing as ad blocking, but ad blocking is a part of content blocking. So to better understand these content blocking webkit apps, we first need to understand what they are trying to block and fix.
There are three main types of content which these apps are trying to block:
- Ads: the images, video, and anything related the visual advertising on the site.
- Tracking: This is any form of a marker a website, advertisement, or web analytics package, could use to identify you in anyway across other sites, or even just returning to that site. Google Analytics being the most pervasive of the lot.
- Comments: Ok, well also Twitter share buttons, Facebook like buttons, and actual comment areas themselves. I’ll group these all together under the label of ‘comments’ because essentially it is your interaction with the words.
While most people seem to care about blocking advertising (and who can blame them, it is ugly), a good number of people are far more concerned with tracking scripts that will attempt to identify you across websites to better target things at you.
Both tracking and advertising are intertwined as they usually, but not always, go hand and hand with each other. While advertising is visually ugly, it is rather harmless. Trackers on the other hand are invisible and are privacy nightmares.
And this isn’t just a paranoid fantasy, some of the websites you visit often are likely laden with trackers. A quick check shows just how many trackers are on each site:
- Nytimes.com: 11 trackers
- BuzzFeed: 10 trackers
- Target: 4 trackers
- Washington Post: 10 trackers
Rarely do you find a site with no trackers — even this site will show one: Piwik which is an analytics package (it tells me how popular the site is). Trackers are everywhere and they slow things down, and are invasive.
How is Content Blocking Done
What these content blockers are doing is stopping these tracking, advertising, and comment elements from either being loaded, or being displayed. And here’s where a huge difference is.
Many of these tools simply hide, not block, elements of a page. So the advertisement is still there, but you can’t see it and you don’t get any speed gains. This is very common with comment areas. Hiding content produces the least amount of issues with site loading, but doesn’t stop trackers at all — they were already hidden to begin with.
Of the apps that actively block things, they work to make sure that these trackers, ads, and comments are not loaded on your device at all. Meaning that an analytics suite won’t know you were there, because it won’t have ever been allowed to load in the first place.
Effectively letting the user dictate what is OK, and what is not OK with them.
This is done ((I am relaying information told to me by a couple different parties here.)) by a content blocking app passing information to the Webkit engine which powers web rendering on iOS — thus the app isn’t actually running or working in real time, instead Webkit is checking its list of blocked items before it is loaded. Much like a night club manager handing a list of banned people to a bouncer. He doesn’t stand next to the bouncer, instead the bouncer just checks the list whenever someone shows up at the door on behalf of the night club manager. In this case the manager of the night club is the content blocking app, and the bouncer is the Webkit engine.
That’s how content blockers work in a nutshell.
A Note on Speed vs Data Download Comparisons
How these lists are made is quite important. I evaluated both the load speed and the data downloaded, but those two are not exactly the same result. You see some blockers might load less data, but take longer to load that data — while others might load more data, but take less time to load that data.
Why is that? It seems to defy logic…
I am told this is because of how a list is constructed. This is where pattern matching and expressions come into play. Let’s go back to our nightclub bouncer, say you decide that you don’t want any Kardashian to enter the club — how do you do that? There’s a million of them, right? And you need to grab those related to the Kardashians, but not carrying the same name.
Well you write a sentence to tell your bouncer how to figure it out, perhaps something like:
If the last name is Kardashian, or West, or Jenner, don’t allow them in.
But that’s not perfect, because of course we want to let Adam West and Caitlin Jenner in, so we need to update that.
If the last name is Kardashian, or West (but not Adam West), or Jenner (but not Caitlin Jenner), don’t allow them in.
ad in it”, and they write that rule forcing Webkit to do more computation when loading a page.
And therefore more computational power is required to block content — thus some apps will take longer to check their lists and block more, or even less content than other apps. And this is in part because there is a hard limit on the size of list you can hand Webkit, and in part because it is a massive amount of work to create these lists. ((These lists are compiled into byte code, which makes it faster and allows multiple content blockers to be on at once. Presumably this keeps the same rules from being duplicated. There’s a lot more to this, but this is a simple overview.))
So when you look at an app like Adamant, which is fast in my timed loading tests, but slightly less efficient with data downloads — this is why it can still be faster than it would seem from just looking at the blocked data as the rules its using is presumably faster for Webkit to compute through.
Is it ethical?
This is the bigger question, but in my book is it not only ethical, but also prudent. While some may argue that there is an implied contract if I view a site you must also view the ads, but that all went out the window the moment those ads and sites started adding invasive trackers.
I’ll look at a shitty, innocent, picture of a product on your site, but in no universe does me reading your story give you the right to follow me around for the rest of the day.
Put another way: just because I showed up for your free book reading, doesn’t mean you get to come to dinner with me to tell me more about your awesome book. I came, I saw your book, it sucked, I left, our interaction is over.
Even if you disagree with me, then surely you want publishers to do well — and they simply are not doing well right now, yet they won’t change because that change is unknown and scary. At the very least a content blocker will force them to figure out that change sooner rather than 100s of layoffs later.
I am all in favor of web publishing but the current state of ads and trackers is insane and needs to be stopped. And as for blocking comments: well of course you should do that — most comments actually are insane.