An introduction to WebKit content blockers

June 15, 2015

I'm not sure what to think of content blockers in Apple's Safari for iPhone and iPad browser, and the technology that powers it, the open source WebKit.

As someone who makes content, I never block it. That's because I want more content and blocking it will lead to less. That said, I'm trying to understand content blocking and what it means not just for my work on the web, but my life on it.

I had the chance to talk to several people about the technology at WWDC 2015 and it's absolutely clear to me no one is making content blockers to hurt any creators or any companies. They're doing it to give people more control over what they see, hear, and experience on the internet. It's a tool, and how it's used will determine if it's good or bad for you, me, and the websites we all know and love.

The WebKit blog, Surfin' Safari, has posted some more information about what content blockers are and how the extensions work.

We have been building these features with a focus on providing better control over privacy. We wanted to enable better privacy filters, and that is what has been driving the feature set that exists today.

There is a whole universe of features that can take advantage of the content blocker API, around privacy or better user experience. We would love to hear your feedback about what works well, what needs improvement, and what is missing.

A major benefit of the declarative content blocking extension model is that the extension does not see the URLs of pages and resources the user browsed to or had a page request. WebKit itself does not keep track of what rules have been executed on which URLs; we do not track you by design.

Everything has been developed in the open; everyone is welcome to audit and improve the code. The main part of content blockers lives in Source/WebCore/contentextensions.

If you're considering making or using a content blocker in Safari for iPhone or iPad, read the rest and let me know what you think and why.

WWDC 2015