Safari content blocking extensions don't automagically identify ads and prevent them from loading. Instead, they identify elements and resources on a web page and can, optionally, hide those elements and prevent those resources from loading. The goal is to show how fast the modern web—read: Safari—really is when you remove all the extraneous code that's been dumped on top of it. And they're coming as part of iOS 9.
The vast majority of the time the elements and resources blocked will be those used to serve ads. Other times they'll be things like social networking buttons, performance and audience analytics, article comments, navigation headers, inline frames, "hamburger and basement" sidebars, and more.
They can't block Hulu commercials or YouTube pre-rolls or arbitrary or every mention of "prequel" on a page, but there's a lot they can do.
Note: iOS 9 is currently in beta and governed by a non-disclosure agreement (NDA) that doesn't allow for screenshots or video. All the material contained in our iOS 9: Explained series is from previous, now public versions of iOS, from iOS 9 features shown off during the WWDC 2015 keynote, and from our coverage of the event, including our iOS 9 first look.
Content blocker compatibility
Content blocking extensions require Safari or an app using the new Safari View Controller in iOS 9 to work. They also require 64-bit processors to handle the work. That means content blocking extensions are compatible with iOS devices released in 2013 or later—the ones that include a 64-bit Apple A7 processor or later. In addition to any iPhones and iPads Apple announces this fall, that list currently includes:
- iPhone 6
- iPhone 6 Plus
- iPhone 5s
- iPad Air 2
- iPad Air
- iPad mini 2
- iPad mini 3
- iPod touch 6
While older chipsets could run content blockers, they won't run them fast enough for Apple, and content blockers are all about speed. So, that means content blockers won't work with iPhone 5c, iPhone 5, iPhone 4s, iPad 2, iPad 3, iPad mini, iPod touch 5, or with apps that use the old UIWebView or WKWebView controllers.
Content blocking basics
Blocking content, especially ads, has been possible on desktop browsers for a while, including OS X and Safari . With content blocking extensions, however, Apple is improving them for OS X and, for the first time, making them available on the iPhone and iPad. Apple is also fundamentally changing the way content blockers work.
In the past, content blockers were services that Safari consulted at load time. That meant the act of blocking content itself could reduce performance, and information about the page being visited could be shared with the service doing the blocking. In some cases, that meant the blockers themselves could theoretically be worse than the content or even malicious.
That's also the biggest difference between content blockers and content cleaners, like Safari Reader. With Reader, which debuted in iOS 5, the content is loaded first, including ads, scripts, and everything else, and then its re-rendered for maximum legibility. So, ads still get displayed, no matter how briefly, and hits still get tracked.
With blockers, the content is never loaded.
A brief history of Extensibility
Extensibility, introduced in iOS 8, is one of the most important advances in the recent history of mobile computing. They unbundle apps so features are no longer trapped in a single binary but can present remote interface and functionality in the system, in other apps, and even on other devices.
With Extensibility, apps can project widgets into Notification Center's today view; provide custom upload and update functionality, and custom actions in Share Sheets; hook filters into the Photos app; provide custom keyboards system-wide; access your files anywhere via iCloud Drive or third-party document providers like Dropbox or Google Drive; fill in passwords or translate text right inside the Safari browser; and process data on your iPhone and display it on your Apple Watch.
And they can do all this while maintaining the high level of security built into iOS. That's because the app that's receiving the interface has no visibility into the data that interface is showing. It's just the host, not the container.
How content blocking extensions work
With content blocking extensions in iOS 9 (and now OS X as well), what's being blocked needs to be declared ahead of time. That way nothing gets consulted at load time and nothing about the page itself gets shared with anyone.
Content blockers, like other extensions, are hosted inside an app that gets downloaded from the App Store. Also, like any other extension, content blockers aren't enabled by default. You have to go to Settings > Safari > Content Blockers and switch them on.
Unlike other extensions, once enabled you don't have to tap a Share button to invoke content blockers or cycle through a set of options to use them. Content blockers are on all the time and applied automatically.
Here's a simulation of what iMore would look like with ads blocked (red) and with navigation and non-essential text fields (orange) hidden.
Developers can add action extensions as well, to make it easier to add or remove specific sites or content types, for example, but otherwise content blockers really are "set it and forget it".
Content blockers for developers
To create a content blocker, developers add a Content Blocker Extension template in Xcode and create a list of rules in a JSON file. The rules define what gets blocked. The rules contain triggers and actions. Triggers determine when the rules get run and actions determine what happens when they do.
For page elements like divisions (div), the trigger can be as simple as coming across a CSS class and the action, setting its display property to "none". For example, if "#about-the-author" is encountered it can be made to go away. Developers can choose to target all domains, or to include or exclude specific domains. They can also choose to target all resources or to include or exclude specific resources.
For scripts, it can be as simple as blocking them from loading. Again, developers can choose all scripts or to include or exclude specific scripts, and to exclude first party (same scheme, domain, and port as the page itself) or third party scripts.
Filtering is handled by regular expression (regex). Developers can even create rules that, if the proper conditions are met, negate other rules. So, to prevent anything about "special editions" from showing or loading, you could hide or block "special" except when it's part of "despecialized".
Or, developers could make a content blocking extension for travelers or data roamers that weighs every element, lets "light" content through, but blocks anything "heavy" to help save on bandwidth.
Once the content blocking extension is downloaded and enabled, Safari will compile the extension's rules into bytecode and apply them whenever it loads a website. If an app uses the new Safari View Controller, then the same will happen in the in-app browser as well.
That makes the extensions incredibly efficient and, because the extension has no idea what page is being loaded, incredibly private.
Since developers can provide ways to change rules in the app that contains the extension, in action extensions, and in Settings, developers can notify Safari about updates and have the rules recompiled. That includes when white lists or black lists are imported or re-imported, sites are added or removed, different elements or resources are enabled or disabled, etc.
The ethics of content blocking
There's no denying content blockers are well thought out and well executed. And when they're running, Safari flies. If Apple succeeds at nothing else, they'll succeed in making it wickedly obvious who's really to blame for poor mobile performance.
The speed difference, especially on large media sites, is ludicrous. It's like unhitching a trailer filled with lead and watching a truck, no longer burdened, take off like a rocket.
Unfortunately, there's also no denying that it's ethically questionable, at least in the case of ads.
Free web sites aren't free. Even if there's no pay wall, there's still a value exchange: You "pay" with attention and data, just like you do Google Search and Gmail. Blocking the elements and resources that collect the attention and data is effectively withholding payment. Some might call that a protest. Others, stealing.
Whether or not it's analogous to commercial skipping on a DVR, torrenting TV shows, or cracking and pirating apps, or whether it's closer to pop-up blocking, do not track, or even the push-back against Adobe Flash (opens in new tab), is beyond the scope of this explainer.
When you add malvertising to the mix, who broke what social contract first might well be a moot point anyway.
Indisputably, an ethical form of content blocking would prevent an entire site from loading. If someone determines that a site is abusing advertising, tracking, malware, or anything else, they can add it to the list and, if they ever click a link or type in a URL that tries to take them back to that site, the browser or web view prevents it and reminds them they've blocked it. Site blocking would also protect artistic integrity in cases where, for example, a creator considers a web font integral to their design.
Beyond that, what's acceptable is something everyone will have to decide for themselves.
A brave new web
Optimists will hope that providers like Google Ad Exchange will clean up their act or sites like iMore will be able to make a go of ethical native advertising and sponsorship models. Pessimists, that advertorials and supercookies from providers like Verizon will expand to fill the void and sites like iMore will give way to sites like Buzzfeed.
There's also entire realms of non-advertising based content blocking developers could explore. That includes security-related extensions for preventing malware scripts embedded in iframes from known bad actors, and privacy-related extensions that prevent any kind of online tracking regardless of intended purpose. Like with any new technology, we won't really know what developers can do until they show us.
I'll save my personal opinions on content blockers for my iOS 9 review, coming this fall when Apple ships, so for now I'll leave it at this—mobile ads served both publishers and readers poorly long before content blockers. Little could change or everything could change. The future is tough to predict even when, later, it's obvious in hindsight.
Rene Ritchie is one of the most respected Apple analysts in the business, reaching a combined audience of over 40 million readers a month. His YouTube channel, Vector, has over 90 thousand subscribers and 14 million views and his podcasts, including Debug, have been downloaded over 20 million times. He also regularly co-hosts MacBreak Weekly for the TWiT network and co-hosted CES Live! and Talk Mobile. Based in Montreal, Rene is a former director of product marketing, web developer, and graphic designer. He's authored several books and appeared on numerous television and radio segments to discuss Apple and the technology industry. When not working, he likes to cook, grapple, and spend time with his friends and family.
The iPhone 5 and 5c are both 32-bit. Edit: This refers to an error in the article that's been mostly corrected already. (I assume it'll be fully corrected shortly.)
Fixed but had to clear the cache, thanks!
Thank YOU, Rene. That was the first I'd heard of the 64-bit requirement. Now I'm looking for a replacement for my iPhone, but at least I know I'm looking. :) (And, for the record, fully fixed now.)
From what I understood from this, it's on the page developer to use this extension. Why would the page developer use? I'm pretty sure the developer of the page gets money from ads right? Why will it stop the ads then?
Simple misunderstanding. App developers can develop extension apps that do the blocking, not the web page developers. Users need to install these extension apps to get the benefits that apply to all web pages.
Thanks for the explainer, very helpful. It would be nice if one of these apps that creates the content filtering rules will allow you to set up groups or all you to set them up on a site-by-site basis. I routinely visit about 2 dozen sites, so it would be great to be able to support them and let all but the most egregious advertising through, while having a different set of rules for the rest.
Thanks for the detailed write-up. The list of compatible devices is missing iPad Air 2 but I guess it's a given it will be supported.
I'm looking forward to this feature. I think it will be helpful to block out as much crud as possible to make the users online experience more enjoyable to them.
From the point of view of the site viewer, the ethics of whether or not to block ads often comes down to the well being of your device. There are bad actors in the ad world and nothing is being done to address this. Ads infect, cover content, play and sound off.
As to whether web sites are free: actually, they are, in away. Content, with ads, is made available to everyone. What the receiver does with this information is not the publisher's business. If the publisher wants to become a store (pay the site, get the content) then they should do so up front. Publisher's fail to realize that they present themselves as enthusiasts. As such, a part of the site should enthusiastically spread content to everyone, the rest sold. Instead they perceive themselves as 100% store while selling themselves as something else. They fail to remember that enthusiasts sites were their forefathers, information freely spread. An expectation has been set. Don't blame us if we fight back as you try to change this.
To survive, sites like iMore must be up front as to the relationship they expect to have with the reader and must adhere to a strict level of conduct re ads and what the code therein does and how it affects a computing device. As it stands now, with publishers unwilling/incapable of controlling that code, viewers will protect themselves from abuse, and should.
When it comes to the ethics I'm currently on the side of ad-blockers. Like the author says, it's a value exchange. The problem is that when it comes to a real-world value exchange the items in the exchange are explicit (X dollars for item Y, item A for item B, etc), but online it's much more vague (article X for personal information that's never specified). Of course people are going to be weary about exchanges that don't explain what's being exchanged. If you picked up a newspaper for free, asked the newspaper stand operator how the paper was paid for, and the reply was "don't worry about it" while riffling through your wallet and explaining that he'll follow you for a few weeks, tracking your every location and which places you visit, you'd throw the newspaper back at the operator, walk away, and get a restraining order. Ad-blocking is the closest thing people have to a restraining order for ads, except advertisers are always trying to find increasingly-aggressive ways of getting around it. It's an arms race between privacy and commercial viability.
Yes I agree especially if you see any of the Mobile Community sites without protection. It is absolutely awful. Posted via the iMore App for Android
Nice write up. Posted via the iMore App for Android
Listening to the grousing over this on Sunday's TWiT, I find some irony in "new media" folks who in the past mocked the newspaper and magazine industry for not embracing new business models, and now that theirs are under threat, they complain and call people thieves.
I'm not so sure they're ready to embrace a new business model. The old one is so entrenched in their thinking that a complete overhaul is anathema. The recent Mobile Nations site overhauls are designed to make ads more palatable, not reduce their number in a significant way nor ask permission before collecting any data possible. In short, nothing has changed. As bynkii said, above, the flow of information is too one-side and too opaque. Transparency is badly needed.
However, I do think René and others at iMore want to see a streamlined, efficient web experience for their readers. As iMore is an Apple news site, Mobile Nations could us it as a test-bed for a complete and equitable for the reader overhaul, with reader experience and security/transparency front and center.
If iMore disappeared tomorrow it would make zero difference in my life. Sent from the iMore App
As an iOS 9 beta user, is there a way for me to try this out now? I'd love to have a bad blocker as some sites serve ads that cover up 3/4 of the screen , preventing me from being able to read the material. It would be nice if they had a skip or close button, but they either don't have it or it doesn't work.
When I click on a link in Facebook, the Facebook browser usually takes ages. Will this feature only help for Facebook on safari? Or will Facebook app's browser also be affected by it?
Appears there is no "Settings > Safari > Content Blockers" on my iPad or my iPhone. Is blocking software supposed to be downloaded first? This isn't clear.
You have to download an app from the AppStore to enable it
Or how tech bloggers called out the record companies who fought back against streaming music. What ever happened to "the people have chosen, you need to adapt to change and find new business models"?
Get the best of iMore in in your inbox, every day!
Thank you for signing up to iMore. You will receive a verification email shortly.
There was a problem. Please refresh the page and try again.