Many oceans of virtual ink have been spilled over what it will mean. To sum up, sites that rely on mobile visitors who use iOS to generate advertising views and click-throughs as part of how they fund themselves may be out of luck.
To try it first hand, I tested three beta content blockers against the latest public iOS 9 build: Adamant, Blockr, and Crystal. (That they go A, B, and C is absolutely coincidental!) These extensions are from developers who plan to release versions when iOS 9 ships.
What I found on newer iOS devices is that the time to load isn’t affected as much as what’s being loaded that you don’t see, which continues to be downloaded long after you’re interacting with a page.
I tested several popular news and Mac-related sites using the fourth-generation iPad (late 2012 model). I first used Safari’s settings to clear any cached data (Settings > Safari > Clear History and Website Data), to make sure already loaded JavaScript, media, and CSS didn’t distort load time. I then ran a stopwatch against each page load from the moment I tapped the link to the moment the page was usable.
You’ll see many comparisons that tracked from entering a URL to when the final referenced item was loaded; I didn’t employ that, because I was looking at how long it takes for a page to be usable. The difference is minimal to substantial depending on the site.
Another interesting tidbit: Many iPad or mobile-optimized sites aren’t substantially different with content blockers installed or not. Even sites that take an egregiously long amount of time to load on the desktop and are festooned with stuff other than content have clearly migrated rapidly towards more stripped-down mobile presentation.
It’s interesting to look at Buzzfeed, a pioneer of native advertising, in which editorial content is developed for advertisers and presented as sponsored stories or other items. The homepage for Buzzfeed with and without Blockr enabled to block ad networks and privacy-dubious scripts differed only in about a second of load time, and only one advertising element disappeared.
The biggest differences were seen behind the scenes: By blocking a variety of non-content items from downloading, megabytes per site are saved on the first load. (Some of that is cached for subsequent loads, so it’s not overhead for every page.) And JavaScript-based tracking of your behavior from blocked scripts while you use a site, which can include keeping track of how long it takes you to perform a task, what you hover over, and what you click, is fully disabled. This reduces battery drain while also improving a site’s interactivity. (In July, Monday Note’s Frédéric Filloux ran some numbers on desktop ad blocking and mobile page loading that are worth reviewing.)
Blockr’s unique feature is an option to block all media. While this may seem extreme, if you’re on a slow connection (like T-Mobile users roaming internationally on 2G or a bad hotspot network), or you have a bandwidth cap or are charged for usage, such an option keeps the web available without having to switch to a specialized browser—and, wow, do pages load even faster.
Content blockers are much simpler even than OS X Safari extensions, which are written in JavaScript. Instead, they’re a series of instructions, rather than a software program. Apple examines all the loaded content-blocker instructions, compiles them to execute faster, and runs through them for every single retrieval, whether a full webpage or any media, style sheets, scripts, or other content retrieved from a page. This approach to performance makes them ideal for mobile Safari, but also will aid with filtering faster (and using less battery power on laptops) for desktop Safari.
The filters are written as a series of statements about what URL or URL pattern is to be affected, and then what behavior should take place against it. This includes an optional resource type, such as an image, document, a popup, and the like, so that only that kind of data is affected. (For all the technical details, the WebKit team’s Surfin’ Safari blog entry has oodles.)
For any matched item, it’s also possible to filter depending on whether it’s fed from the same origin as the webpage that’s loading it, or from a third-party site. Ad networks and other tracking systems have ways around this, such as running subdomains that are customized to the sites that are feeding them out.
Finally, a filter doesn’t have to block a page entirely. While it can do so, it can also just strip all cookies or strip specific CSS (Cascading Style Sheet) selectors. These two options have two dramatically different purposes. Cookies are one way to feed a unique identifier to a browser, which it stores and then sends back every time it requests a page or other item from the same server (or sometimes, same domain). Unfortunately, there are a lot of other ways to bypass the limitations of regular browser cookies by using evercookies and supercookies. Blocking browser cookies won’t prevent determined tracking networks from seeding other kinds of IDs. Apple could expand the filters to disallow access to some HTML5-based features that are used to keep a cookie persistent when it shouldn’t be set in the first place or after it was intentionally deleted.
Stripping out CSS might sound a bit obscure if you don’t design or develop webpages, but it’s straightforward. HTML defines the bones of a page, like the girders of a skyscraper, and contains the innards—text and images and other stuff—just like an office contains workers and furniture and printers. CSS is the glass and metal panels covering the skyscraper, while also painting the outside and creating the walls and cubicle barriers: It defines how things appear, including the dimensions and placement of both fixed layout areas and boxes that can seemingly float above the page.
A CSS “selector” defines the scope of what style definitions apply to. They can be used to attach to an HTML element, reused for multiple parts of a page, or define a specific structure, which is used for those floating boxes among many other purposes. By allowing a blocking filter to strip out specific selectors, it can suppress advertising overlays or other annoying or intrusive behavior.
Apple allows any combination of content-blocking extensions to be enabled at once via Settings > Safari > Content Blockers. And you can override all content filters by holding down the reload button for a few seconds. Instead of a simple reload, it becomes a “reload without filtering.”
Content blockers have to be packaged inside of apps, though the apps themselves can be exceedingly simple. In testing just three extensions, I’ve already seen a lot of variety. When we get to the release stage for iOS 9, I expect a huge ecosystem of filter apps, some more sophisticated and configurable than others.
Some will be simple. At this stage of development, Crystal is just a holding place for rules set up by the developer. Adamant has a couple of settings. Blockr has a full configuration screen with three kinds of blocking types, and the ability to whitelist in the app portion. We’ll definitely see a lot of baroque options over time. If Ghostery winds up implemented as an extension, it wouldn’t be able to show its pop-up display, but could offer all its intricate and per-network choices on the app side.
There will definitely be a market for apps that focus on blacklisting and whitelisting. The former is easier, because it’s a subset of everything on the internet, and developers will carve out area like anti-phishing and anti-malware, which will be a great thing to install for relatives and friends who don’t care about technology, but want to browse safely.
Whitelisting apps will be more complicated, because they will need to block everything and only allow a subset, such as child-appropriate sites (by whatever standards they pick) or sites that never feature adult content or obscenity (again by their definitions). Apple says that too many over-broad matches are a problem, and the WebKit team’s blog post notes, “Using too many of them can cause the rule set to be rejected.” Because rules can be updated remotely and dynamically, this seems like a Safari limitation: It will opt to ignore rules if they wind up exceeding some thresholds at compilation time.
Some blockers will surely offer sync via iCloud or other services to allow any user-customized settings, like whitelisted sites, to be kept the same across multiple iOS devices—and perhaps OS X.
The differentiation isn’t going to come in performance, since Apple ultimately controls how that works in practice. Rather, it will be by features, usability, and cost.
AT&T recently performed a dubious experiment at two airports in the Washington D.C. area: they injected JavaScript code into pages being loaded by users of the free Wi-Fi network that overlaid advertising on websites. Discovered by a privacy and security guru, AT&T quickly stated the experiment was over and intended to be limited. (I wrote in a Private I column why this was a terrible idea on AT&T’s part.)
This sort of behavior could be prevented with content blockers, because ad networks that employ such tactics quickly wind up on the darkest of blacklists, as privacy violators or script invaders, rather than just purveyors of commercial information.
A recent Reuters Institute for the Study of Journalism report found in a survey that 47 percent of regular online news readers in the U.S. and 39 percent in the UK regularly used ad-blocking software. Between this injection, the large amount of data loaded that’s not content related, slower load times, and privacy concerns, I expect content blockers in iOS will have the same level of popularity.