Safari Content Blocker Wishlist for WWDC20

Salavat Khanov
1Blocker
Published in
5 min readMay 4, 2020

--

Apple’s WWDC is going virtual this year and will be live-streamed in June. What new features and improvements do you think we will see in iOS 14 and macOS 10.16? New Home screen widgets? Xcode for iPad? Multi-user support on iPadOS? So exciting!

It’s been almost five years since Apple introduced Content Blockers for Safari in 2015. The API is quite powerful and allows us to block most unwanted content on sites.

Our users are happy with the results they get after installing 1Blocker. However, there are some limitations in what the API can do. Also, we think several enhancements can be made to further improve the user experience.

Here’s our list of features and improvements we’d love to see in the next version of iOS and macOS related to content blocking in Safari.

Incremental Updates (FB7684949)

Each content blocker extension is basically a list of rules that tells Safari what to do when loading a webpage. These rules are written in JSON and look like this:

Safari content blocker JSON

The problem with this approach is that when you need to add a new rule or modify an existing one, you have to edit the whole JSON file. A content blocker extension can contain up to 50,000 rules, so these files can get very large, and parsing them takes a lot of time and resources.

On top of that, apps may contain multiple extensions. For example, 1Blocker consists of eight content blockers. Parsing and generating JSON is a bottleneck for us at the moment.

At last year’s WWDC, Apple released diffable data sources that make applying and animating changes to a table and collection view a breeze.

A snapshot represents the state of a view. To update the interface, you just need to apply the snapshot on the diffable data source and it takes care of updates and animation for you.

I think a similar concept could be used here for updating content blocker rules. Instead of supplying to the API the whole JSON file with all rules, we could provide via the snapshot only incremental changes (e.g. new, modified, or removed rules). Safari would keep previously provided rules and apply new changes.

This new approach would make adding new rules or removing old ones much faster because we would only need to generate a small file with changes instead of providing the full JSON file.

Don’t Use JSON (FB7684953)

Last year, Apple pushed declarative programming at WWDC a lot. They even released a new UI framework, SwiftUI. So if we expand that idea further, then it feels logical to improve the way app developers provide blocking rules to Safari.

Currently, we provide rules via JSON, but that may be error-prone and doesn’t feel like a good API to me.

Why not use regular struct and enum instead? We could wrap JSON properties of a blocking rule (e.g. url-filter or resource-type) into properties of a struct rather than using their string representations in JSON. Then build an array of these objects and provide them directly to Safari. A model similar to this:

This is the model we use in 1Blocker

Coupled with incremental updates discussed earlier, this would make changing rules so much easier and nicer for app developers.

Blocked Resources on iOS (FB7684965)

We recently released blocking stats in 1Blocker for Mac. This feature uses the new API announced at WWDC19. It’s so cool to see the amount of unnecessary stuff blocked on pages you visit.

After releasing it, many people asked us if this feature is coming to iOS, too. We really want to say yes to them, but for now, our fingers are crossed. 🤞

Make Enabling Content Blocker Extensions Easier (FB7684967)

After downloading a Safari content blocker app, you need to enable its extensions in Settings. It’s so incredibly hard to enable them on iOS because they are buried deep down in the Settings app.

Our current workaround is the following screen that guides the user through the setup process, but keeping in mind all the steps while scrolling through the Settings app is certainly not easy.

On macOS, things are much easier because Apple provides a convenient function in the API that automatically opens Safari’s preferences pane for the specified extension:

Apple, can we have a similar method on iOS, please? It would make installing content blockers so much easier for all users.

Add Support for Scriplets

Scriptlets are pieces of JavaScript code that can be injected into certain pages. They can extend the capabilities of existing actions available to content blockers in Safari.

Take a look at uBlock Origin’s open-source list of scriplets as an example. They are quite powerful and let developers fine-tune the blocking experience. Think of the ability to block things like pop-ups nagging you to turn off your content blocker, or automatic redirects to a different version of the site, or being able to change the style of some webpage elements.

When done right and secure, they can take content blocking in Safari to a whole new level.

Show What Elements Were Hidden

It’s unfortunate that there’s no easy way of knowing what webpage elements were hidden on a page.

Safari’s Web Inspector shows only blocked requests, but it doesn’t tell us what elements were hidden, like social media buttons or popups.

In addition to blocked requests, we would also love to show users hidden elements on our Blocking Stats screen.

Increase Rule Limit to 100K

Each content blocker extension can have up to 50K rules. Although that’s not a small number, sometimes it’s not enough. There are open-source lists with hundreds of thousands of rules.

While I think that it’s not a good idea to have so many rules, and developers should keep their rulesets as small as possible, having the limit at 100K would make us think less about hitting the limit and more about building a great user experience.

The 50K limit made sense five years ago when iOS devices were slower. But now they have fancy Bionic chips, so they probably can handle a bigger limit.

We hope our huge list doesn’t come across as ungrateful because we love Safari, and the WebKit team has done an incredible job of providing content blocker features while making sure users stay safe and their privacy is protected.

Let us know 1BlockerApp on Twitter what would you like to see?

--

--