UI for easier privacy and security blockers selection

[brampitoyo]

Why/User Benefit/User Problem

With the settings re-org, we will gather all of our Privacy and Security settings in one section.

As we build more blocking settings – block autoplaying audio/video, ads/banners, pre/interstitials, third-party cookies, etc. – it becomes harder and harder to know:

1. That the more blockers are toggled on, the faster webpages will load and the less data/battery will be used, but webpages will also be more likely to behave unexpectedly.
2. That certain blockers can be toggled on and off depending on the user’s browsing habits.

The aim for this UI is to:

1. Explain the privacy+performance vs. site compatibility trade-offs in an understandable language
2. Allow easy selection tailored to every individual’s risk-adverseness
   • Including the case where the individual wants to customise each blocking setting manually

By making Focus more secure and making its security options more accessible to more users, we will increase the product’s usage (average time spent, MAU/DAU, ratings, etc.) as well as usability.

What / Requirements

1. A default (recommended) security option with a strong Focus perspective:
   • Block most ads and trackers on top websites
   • Eliminate most annoying distractions (looking at you, autoplay and pre/interstitial banners)
   • Maintain maximum site compatibility (everybody can use it as their default browser)
2. A few other security options that empowers individuals to take control of their browsing experience
3. A manual setting, for fine-tuned control and maximum flexibility

Acceptance Criteria (how do I know when I’m done?)

The user has a rough understanding of what each option means, and which one is right to select for their use case.

[brampitoyo]

Some early UI concepts:

[brampitoyo]

After conversation with Amin, I’ve revised the UI:

• 4 easy to tap radio button options
• Default option is secure by default
• When tapped, each option expands to explain which blockers are on
• On “Manual” mode, all blocking settings show up underneath, allowing each user to customise at will

[brampitoyo]

This issue is just about the UI, but I’m particularly curious to hear from @pocmo @ekager @boek about:

• If we support ad blocking, which is the right ones to include and turn on by default?
  • As an example, I’ve selected EasyList, Adblock Warnings, Fanboy’s Annoyances and NoCoin as starters. What do you think?
  • There are a lot of lists there, certainly. Including ones for specific locales. Do we want manual list additions? How to keep these lists manageable? We think to think a lot more about this.
• Is blocking autoplay audio and video realistic? We will certainly have a place to put it, if we have this feature.
• On “Very high protection”, we even block sending usage data to Mozilla. Maybe this “Paranoid Mode” is a bit overkill? I thought that it’s also necessary.

[brampitoyo]

Note that this simplified UI will become necessary only after we build more blocking features.

Some of these features are things that we’re already considering in other products:

• Block slow 3rd party content (if page loads for more than x number of seconds, block all 3rd party content from loading)
• Block crypto-mining
• Block fingerprinting (canvas, WebGL, AudioContext, WebRTC IP leakage, SVG)
• Block cross-site tracking
• Block tracking cookies

Some of these features may not ship in other products, but is highly relevant for a privacy-centred, distraction-less product like Firefox Focus:

• Block ads (blocklist that are specifically designed to eliminate ads, such as EasyList or AdGuard – we don’t need many; we just need one that’s comprehensive)
• Block autoplaying audio and video

@bbinto @ekager @boek what do you think about opening a separate issue to discuss these blocking features? Some we can already build today, some may not be possible at all, and some may only be possible after we ship GeckoView.

[bbinto]

I think that's a great idea, @brampitoyo - please go ahead and file those issues and leave them un-labeled so we can discuss in triage etc.

As for this ticket, I'll put a blocked label on it and move it to the backlog again.

Great ideas/work, Bram!

[brampitoyo]

Filed #2768 to discuss developing more blocking features.

[pocmo]

Note that this simplified UI will become necessary only after we build more blocking features.

@bbinto With that and #2768 not being in 7.0 I think this here doesn't need to be either?

[pocmo]

Oops, I just saw you removed the 7.0 milestone and not added it.

[brampitoyo]

The UI has been updated to account for the fact that Tracking Protection has been renamed to “Content Blocking” on desktop, and that we want it to be really inclusive and cover a lot of things (which includes autoplay, cookies, webfonts, javascript, etc.)

[ghost]

IMO there should be "Fanboy Ultimate List" + option to use custom filters (URL to filters .txt)

[brampitoyo]

@runboy93 Agreed on both points!

Having the ultimate list means that the user doesn’t need to turn on a bunch of other lists.

Having the ability to add custom filters means that the user can customise Content Blocking to their hearts content.

However, the really big questions are:

• What happens when blocklists under “Ads” overlaps with blocklists under “Trackers”?
  • Can we somehow combine these two pages?
• Are the sub-categories (ads, privacy, annoyances, annoyances) useful?
  • What is the right way to breakdown these blocklists?
• What blocklist do we want to turn on by default?
  • IIRC, only 2% of users go to Settings. This means that most users won’t change blocklist
  • The safest blocklists are ones that provide the most benefit to speed and privacy, with the least impact to site compatibility. What are they?
  • Focus should come shipped with a good default already turned on.

[brampitoyo]

Updated UI slightly. See notes for details.

Some notable features:

• Most controls are put underneath the “Manual” content blocking control
• Content Blocking doesn’t only control Trackers, Ads or Autoplaying Audio/Video. It controls most contents that the website can load. This includes Cookies, JavaScript and Webfonts (and if we have a feature to block images, it would also be included here). This means that users can easily set exceptions for those features, and that the Privacy & Security setting screen will contain less items if the user leaves the “Recommended” setting on.

[brampitoyo]

Updated UI to include some icons from Firefox for Desktop Content Blocking, and some newly designed/adapted icons for Ads, Autoplay, Webfonts, JavaScript and Unencrypted Pages.

[brampitoyo]

Updated UI based on earlier directions that was never explored thoroughly.

The idea is to separate all of our Content Blocking settings into three “big categories” that are easy to comprehend and control.

Three “big categories”

1. Ads, trackers & cookies
2. Autoplaying sounds & videos
3. Insecure (HTTP) page

1. Ads, trackers & cookies

Under it, there are few sub-categories:

• Ads
  • Blocklist selections
• All detected trackers (new name for “Tracking Protection”)
  • Disconnect blocklist selections
• Slow-loading trackers (ON/OFF toggle)
• Cookies & site data
  • Allow all, block certain cookies, block all cookies

2. Autoplay

It contains two options:

• Stop all videos from autoplaying
• Stop videos that contain audio from autoplaying

3. Insecure (HTTP) sites

It contains an ON/OFF toggle.

+ 4. Advanced

This control hides a section that you don’t need to worry about most of the time.

When you tap it, it expands into:

• Other web contents (it’s not recommended to block these; nevertheless, you can still do it)
  • JavaScript (ON/OFF)
  • Web fonts (ON/OFF)
• Exceptions
  • A list of sites where you’ve disabled Content Blocking

Benefits

Forgoing the simplistic “Recommended vs. Manual Control” model has a few benefits:

• Most users won’t ever go to Settings This is why we’ll turn all three “big categories” ON by default.
• Some users go to Settings Focus is an app that gives them powerful yet simple (but not simplistic) controls. These “big categories” are things that will impact day to day browsing immediately, and significantly. The “Advanced” category are things that they shouldn’t worry about.
• A minority of power users go to Settings For them, Focus makes it easy to drill down into each “big category” and fully customise each control.

CC @vesta0

[brampitoyo]

Updated the mockup to:

• Take out features we haven’t built: autoplay, HTTP pages
• Take out features that won’t provide any benefit to us: slow-loading trackers
• Add features we’re planning to ship: block cryptomining, fingerprinting & session replay trackers
• Put ads, trackers and cookies directly under Content Blocking. rather than in a sub-page

This brings us to parity with desktop, and makes ad-blocking easier to turn on (less hidden).

We will almost certainly block more things in the future. When we do that, we should re-evaluate how these sections are organised. The aim is to keep the Setting simple, minimal, and able to function well without any customisation (turning it on is all you need to get a good level of blocking).

---

Just to clarify our Content Blocking policy:

• The recommendation was to not block Ads by default
  • We should let users know of this feature, and have a direct way of turning this setting on (e.g. we can show toggles in onboarding, start screen tips, etc.)
  • When ad blocking is turned on, we should automatically turn some block lists on by default (so users don’t need to go in and customise further – it works out of the box once you turn it on).
• We’re already blocking ad and analytic trackers by default (are we blocking social?)
  • To our existing lists, we will also block cryptomining, fingerprinting & session trackers by default

[dimqua]

I think the major problem with blocklists is that even those from "reputable" sources can potentially cause fasle-positives (especially aggressive ones like fanboy's enhanced tracking list). And (at least) non-experienced adblock users can't usually do much about it, since it might be hard for them to figure out which particular rules cause the false-positives. That's why I think it would be great to add an UI to see which network requests are blocked on the website you visit by blocklist's rules, so you can whitelist those rules if they case problems.

[brampitoyo]

@dimqua Do you have any recommendation of blocklists that we should enable by default once you turn on the “Ads” subcategory?

• To me, EasyList, EasyPrivacy seems like no brainers.
• The functionality of NoCoin will be baked into Disconnect’s Cryptomining list, so we don’t need it.
• Locale-specific lists may also be useful.

For “enhanced” protection, we can try adding Adblock Warning Removal List and Malware Domains, but I’m not sure if they will create more false positives than we can afford?

So, to be on the safe side, we should use EasyList, EasyPrivacy and locale-specific lists.

As for the rest of the lists that are more aggressive (Fanboy’s Enhanced Tracking List, Fanboy’s Annoyance List, Fanboy’s Cookiemonster, etc.), I’m pretty sure that we shouldn’t enable them by default.

I’m hoping that, if users know “When the site looks wrong, turn off Content Blocking”, it would be enough to solve the problem. It’s not perfect, of course. There’s no network request info available. But it’s simple, and it fixes the problem without too much fuss.

Thoughts?

[dimqua]

Disconnect’s Cryptomining list

What is it?

For “enhanced” protection, we can try adding Adblock Warning Removal List

I'm not sure whether anti-adblock filter lists (as well as any other anti-annoyances lists) should be enabled by default, but you may also consider ABP Anti-CV and Fanboy's problematic-sites filter lists as an options.

So, to be on the safe side, we should use EasyList, EasyPrivacy and locale-specific lists.

You may also want to enable some of the Adguard's lists, such as English filter, Spyware filter or Mobile ads filter (sadly, I don't know any other mobile and browser -specific blocklists, but there're more general ones though, like MobileAdTrackers). There is also Disconnect ad filter list (isn't it currently uses by default?).

it would be enough to solve the problem

Another available solution is using additional whitelist filter lists, such as uBlock Origin Unbreak, Brave Unblock or/and you can maintain your own. :-) See also this list of commonly white listed domains.

[boek]

• [ ] Privacy and Security settings re-org (M) #3508
• [ ] Add new built-in blocklists (M) #3512
• [ ] Custom blocklist manager (storage, add, remove) (needs investigation/breakdown) #3513
• [ ] Custom blocklist management UI (List/Add/Remove) #3514 (Needs UX)

[brampitoyo]

Updated the ad blocking mockups with two separate proposals (I’ll update the rest of the flow accordingly, after we agree on a proposal for ad blocking):

Proposal 1

• Three different levels of blocking:
  • Allowed (off)
  • Block some ads (default – integrating EasyList and EasyPrivacy)
  • Block ads and more (integrating EasyList, EasyPrivacy, Annoyance list and Mobile ads filter)
• This proposal has no “Custom” option. There’s no ability to turn individual blocklist on and off manually.

Proposal 2

• Three different blocklists that are named according to its functionality:
  • EasyList and EasyPrivacy are integrated into “Block ads”
  • Annoyances list is integrated into “Block annoyances”
  • Mobile ads list is integrated into “Block mobile ad networks”
• This proposal is functionally similar to how our current Tracking Protection UI works (you can turn individual tracker on and off)

[dimqua]

Is there a possibility to use custom filter lists?

It's probably better to not combine EasyList and EasyPrivacy filters, and move the latter one to Trackers category. Since EasyPrivacy is not focus on blocking ads (advertisements), it blocks tracking, see their policy.

[brampitoyo]

Hi @dimqua,

Unfortunately, ad blocking will not be able to be implemented the way we would’ve liked it.

We all know how ad blocking work, but here’s a short refresher primer just in case (and for anybody else who’s reading this issue).

1. When you visit a site, the browser sends out requests for all sorts of assets to be loaded from many places.
2. Not all assets are essential to the page. Some are ads.
3. An ad blocker is powered by filters. Filters contain a list of places known to serve ads. When an ad blocker sees that the browser is making requests to those places, it stops them.
4. Ads occupy spaces. When ad requests are blocked, they leave empty spaces that aren’t pleasing to look at. An ad blocker can hide the spaces where ads would normally appear on.
5. Sometimes, stopping ad requests will also make important parts of the sites not work properly. In these situations, the ad blocker can still load the ad, but it can still hide the spaces where ads would normally appear on – at least you won’t see it.

We believe that ad blocking is going to improve so many lives, that we want it to be implemented straight away.

In order for this to happen, we can only use the same method that’s already implemented by Tracking Protection: we can block network requests (number 3), but we cannot hide elements (number 4 and 5).

It’s not perfect, but it’s still going to make pages load faster and save bandwidth/battery. And most importantly, it can be improved when we have time to implement element hiding using future technology currently unavailable to us.

To do this, we have to take each filter list in raw/text format, strip-off all the element hiding parts, and adapt the list of network requests that are left to a format that Focus can understand. Unfortunately, this process cannot happen on each individual device. We will have to do it from our end.

Because we have to process each filter list that we choose to ship with Firefox Focus, we have to be judicious. We want to ship filters that will be most useful, but we cannot ship too many filters because it would also be too many for us to maintain.

When our future ad blocking technology is able to understand both blocking network requests and element hiding rules, then we don’t have to process each file on our end. The user’s device can do it. When that’s the case, then using any arbitrary custom filter list becomes possible.

Until then, we can only implement a subset of any filter. And in that case, we can’t even say “EasyList”. We can only say “Based on EasyList”.

Hope this is a good explanation of our situation!

[brampitoyo]

@dimqua One additional question for you: if we already implement Disconnect.me’s lists by default, do we still need EasyPrivacy – assuming the two does similar things, which is to block trackers?

My thinking is that we still want EasyPrivacy, just in case Disconnect.me misses aything. But it would be confusing for EasyPrivacy to be combined with other lists inside “Tracking Protection”. This was why I thought that maybe it should just be bundled together with EasyPrivacy. Thoughts?

[brampitoyo]

@boek @ekager After discussion with @vesta0, I’ve updated the ad blocking UI to further simplify it. Feel free to disregard my two proposals up above.

It looks like this:

• We’re not redesigning the Privacy & Securty settings, so “Ad Blocking” no longer gets a fully fledged sub-page. Now it’s just a heading with 3 items underneath.
• To make wording and behaviour consistent with the rest of the items on this page, each item underneath “Ad blocking” is described as “Block x”. Each item also comes with a toggle.

[dimqua]

it can be improved when we have time to implement element hiding

Good to hear that!

we have to take each filter list in raw/text format, strip-off all the element hiding parts, and adapt the list of network requests that are left

But it can be done by someone else too, in theory. It means, you can provide a possibility to load custom lists in supported format. However, I'm not sure if it would be useful even for advanced users.

This was why I thought that maybe it should just be bundled together with EasyPrivacy. Thoughts?

EasyPrivacy probably contains too much entities to be bundled with other "Tracking Protection" lists, e.g. this pre-processed version of EasyPrivacy contains more than 6k domains. You may want to use a version of EasyPrivacy without international filters, but I think it's still bigger than all Disconnect.me’s lists combined.

[dimqua]

Do you have any plans to add and maintain any language-specific blocklists? There are plenty of them.

[brampitoyo]

@dimqua wrote:

Do you have any plans to add and maintain any language-specific blocklists? There are plenty of them.

If we get the ability to not only block network requests but also hide elements, then shipping more blocklists (including language-specific ones) will be possible.

For starters, we’ll no longer have to ship our own version of blocklists without element hiding rules. This will make including new lists easy.