Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

What lies beneath: What you need to know about content blockers in iOS 9 Safari

Glenn Fleishman | Aug. 31, 2015
Call them content filters or ad blockers, iOS 9's ability to plug apps into Safari that handle how items are retrieved on web pages will change the way we mobile surf.

blockers buzzfeed compared

Buzzfeed’s native advertising approach means there’s very little different between a filtered (left) and non-filtered (right) page.

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.)

blockers blockr config

Blockr provides a number of configuration options about what precisely gets filtered out.

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.

How content blocking works

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.

 

Previous Page  1  2  3  4  Next Page 

Sign up for CIO Asia eNewsletters.