[meta] Enable and disable trackers via Allowlist

[bbinto]

Why/User Benefit/User Problem

• Give user control what sites may or may not download cookies onto their device, instead of all-in or all-out

What / Requirements

• Whitelist/Blacklist feature to add/remove cookies and trackers
• When a user navigates to a side and disables Content Blocking for that site, the site will automatically get added to the allowlist, and tracking protection will remain off as long as the user is on that site. Once the user navigates away to another site, content blocking is re-enabled.

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

• Blocks or does not block items based on the list

• Disabling content blocking adds the site to the allowlist
  -Content blocking is re-enabled once the user navigates to another site

• https://appbot.co/apps/926238-firefox-focus-the-privacy-browser/reviews/475076741

• http://appbot.co/apps/926238-firefox-focus-the-privacy-browser/reviews/488627651

and here

[pocmo]

The desktop version of Firefox has an exception list for tracking protection. We could talk to the GeckoView team in order to decide how we could make use of that list.

One complicated thing here is: We do more than just tracking protection (blocking JavaScript, blocking web fonts, ..) and those things are global settings and not limited to a specific site (if we want all those things to use the exception list)..

[bbinto]

/cc @brampitoyo

This might be something for past 7.0

[brampitoyo]

@pocmo @bbinto As Tracking Protection on Firefox Desktop expands to blocking many other things in the future, the same exception list would also activate and deactivate the un/blocking of slow 3rd party content, crypto-mining, tracking cookies, etc.

So having a master toggle still makes sense – except that in our case, this toggle controls so much more.

The questions are twofold:

• How fine-grained should our controls be?
• How permanent should our exceptions be?

On one end is a UI that allows you to turn each blocker on and off individually. On the other end is a master toggle that turns all the blockers on and off at once. But let’s say that we want to do something inbetween. Maybe 2–3 separate controls instead of just 1. What should they be? A separate control for cookies, and a control for everything else?

On permanence: it feels as if we should be proactively protecting our users all the time, and this means doing things like not giving them the ability to add any exception. Want to add? You can, but only once. The next time, you’ll get asked again. We can of course have something more generous. Maybe we’ll have the exception stored for a certain period of time.

But now we’re dealing with the problem of, when the user taps “Erase”, not every data is truly cleared. And a secondary problem of Focus becoming more like another browser.

While we should give this issue a very careful look beyond v7.0, if we are to look at what Focus already does best, it seems as if building more blockers (especially ones that Firefox and other browsers aren’t willing to build) fits our ‘core competency’ better than building ways to skip blockers.

[brampitoyo]

Here’s a proposal that gives users:

1. Fine-grained control over elements that may be blocked on all sites (closely related to this issue – a prerequisite)
2. Site-based control over which site can bypass these content blockers (covered by this issue)
   • Currently, site-based control is either all-on or all-off, because we want to make the “master switch” as minimal and easy to operate as possible
   • In the future, we can include site-based control that is more fine-grained. E.g. On some sites, the user might want to allow all cookies, but keep blocking trackers and ads.

The way it works:

1. “Tracking Protection” will be renamed “Content Blocking”.
   • Current: when you turn it off, the setting doesn’t persist and isn’t saved.
   • Proposed: when you turn it off, we add the site to the ”Exceptions” list.
2. Inside Settings -> Privacy & Security -> Content Blocking, there’s a new sub-section called “Exceptions”
   • Go inside this sub-section to show all the sites where you’ve disabled Content Blocking.
   • You’re able to remove individual site from the Exceptions list, or remove all sites.

Since this issue only has to do with building a way to add sites to the whitelist, we will discuss all the elements under Content Blockers itself (trackers, ads, cookies, autoplay, etc.) in #2603.

[brampitoyo]

I’ve just updated the “Exceptions” screen flow up above, to accurately reflect the newest way to access the page.

[vesta0]

@brampitoyo We chatted about changing the privacy & security options yesterday and having exceptions as one of the options. Do we need updated mockups for the allowlist component before Eng breakdown?

[vesta0]

One clarification on the toggle logic: my understanding is that users can add a site to their allowlist by disabling the tracker toggle, but then can only remove a site from their allowlist only by going to the allowlist page in the settings. So for instance if a site is added to allowlist, turning the toggle back on will temporarily enable tracking blocking again, but won't remove the site from the allowlist. Does that match your design/interpretation? @ekager @boek @brampitoyo

[ekager]

Hm in the current implementation once a site is on the allowlist they can't temporarily turn trackers back on because we are checking the allowlist as the site is loading and then turn on/off blocking. Maybe we could override the list on a single load basis but then what if they click a link on the same domain, should we have it blocking or not?

[vesta0]

@ekager I am ok with the current logic you described. I mainly wanted to make sure that they dont accidentally remove a site from their allowlist by turning the toggle back on. Let's stick with this behaviour and later on revisit and optimize based on usage data.

[ekager]

I agree @vesta0 it can be confusing.
Hey @brampitoyo should we change the toggle description to something like "Toggle to turn off blocking and add to allowlist" or something similar?
I think it will be confusing for users if they accidentally toggle it and then they can't get it off because they don't understand it's now in settings.
Maybe we should even remove it from the allowlist if they toggle TP back on (dynamically changing the description to something like "Toggle to remove this site from the allowlist")?
Think we just need to be a bit more clear before adding this feature. :)

[brampitoyo]

Actually, I was thinking that the on and off switch works permanently both ways.

Let’s say that you visit a website, and a video doesn’t show up. You know how to fix this. Just open the menu, then turn the “Content Blocking” toggle OFF. The site reloads, and the video plays. Problem solved.

The next time you visit this site, do you want the video to show up again, or not? My educated guess is that, users who have deliberately turned “Content Blocking” OFF will want to keep it on the OFF position indefinitely. To toggle it over and over again would be annoying.

What about turning the toggle back ON? Usually, there isn’t a good everyday use case for this. The site has been fixed. Everything works. So why risk breaking it again?

Nevertheless, let’s think of a scenario. The site is starting to misbehave again. The video that you want is playing every single time. But today, the site has put in an unskippable interstitial video ad that takes over the whole screen. It’s so annoying, that you want to block again. You also know how to do this. Open the menu, then toggle “Content Blocking” back ON.

When you want to turn blocking OFF, you want it to stick permanently. The question is: when you want to turn blocking back on, do you want it to stick permanently or not?

My argument is that you want it to be permanent, and there are a few reasons why:

1. All you care about is solving problems with websites, not what the Content Blocking status is. And when a problem is solved, you’d like to not solve it again the next time around.
2. The “always permanent” model is a lot easier to grasp than “ON → OFF = permanent; OFF → ON = temporary”. When a light switch is OFF, it remains OFF until I turn it ON – and then it’s ON until I turn it back OFF.
3. The “Allow list” Settings sub-page was never designed to be a primary means of re-blocking sites. Even though it’s placed logically, it’s simply too deep to access. Too few users will ever go there. To solve this problem, we’ve made the “shallow” access point (the toggle inside menu) more powerful. And we follow user’s expectation: “I can turn it OFF permanently by going here. And I can go to the same place to turn it ON permanently”.
4. Our own stance has changed. Before, we know that Disconnect’s lists only blocks trackers, not ads. And we were confident that is worth sacrificing some site compatibility for. Therefore, we would always make turning it OFF a temporary option. Now, we’re about to add more block lists and functionalities. We think they will be as site-compatible as Disconnect’s lists. Real-world data seems to confirm that (otherwise, so many ad blockers won’t ship Fanboy’s lists!). But we don’t know for sure. That’s the problem. We want to be extra safe, so when we block many things, the Content Blocking toggle becomes permanent.

There’s an argument to be made for a toggle that works like uBlock Origin:

1. uBlock Origin is enabled on every site
2. If I turn it off, it’s only temporarily disabled
3. I can make that disable state permanent, by clicking on a “lock” button

Just to reiterate our toggle models:

Blocking state	Focus (current)	uBlock Origin	Focus (proposed)
Default	On	On	On
Turn off	Temporary	Permanent	Permanent
After turned off, turn back on again	Permanent	Permanent	Permanent (my proposal is to not make this temporary)

[sv-ohorvath]

Verified UI and functionality on Nightly. Created manual test cases.