Let user know about the new behaviour for trackers blocked/allowlist toggle

[vesta0]

Why/User Benefit/User Problem

As a user, I need to know that disabling tracking protection for a site, will add the site to my allowlist permanently (until I turn it back on) and from then on everytime I navigate to this site, tracking protection will be disabled.

As a user, I need to know that turning the tracking protection toggle back on, will remove the site from my allowlist.

What / Requirements

Add messaging (could be just in time messaging) to tracking protection toggle to communicate adding/removing sites from allowlist.

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

Toggle switch behaviour is communicated to the user.

[vesta0]

@brampitoyo would love your feedback on this!

[brampitoyo]

Under the current “Trackers blocked” toggle, we have the caption:

Turning this off may fix some site problems

To clarify the fact that it’s permanent, we can change this caption to:

Turning this off may fix some site problems permanently

We’ll also need a caption for when Tracking Protection has been toggled off. Currently, it’s the same on both states.

We can change it to something like:

Turning this on enables Tracking Protection permanently

But an important caveat here: I’d still argue that most Focus users don’t need to see the word “permanent” in order to understand the new behaviour, or to know about where the “Allowlist” page is located, in order to understand where to modify the setting.

This is for a couple of reasons:

• The proposed behaviour: “If you turn this OFF, it’s OFF permanently.” has less conditions than our current behaviour: “If you turn this OFF, it’s OFF until you erase.”
• The proposed behaviour mirrors what happens when you reverse it: “if you turn this ON, it’s ON permanently.” Being permanent both ways adds an extra layer of consistency.
• The proposed behaviour matches how every other Android toggles work: OFF means OFF permanently, and ON means ON permanently. I have a hypothesis that many Focus users already expect the Tracking Protection toggle in Focus to work like other toggles – but so far, it hasn’t. So if we are simply matching system behaviour, we don’t have to explain anything.
• Manipulating the allowlist by going directly to the site is more intuitive than going to a separate page under Settings. The Allowlist page gives you an overview list of all sites. It’s helpful in some cases. But in most cases, it’s impossible for you to know why you should remove anything from the list, if you don’t go to the site and see for yourself.

[hackel]

You need to have a big, fat modal warning the first time a use runs Focus after upgrading to a version with this change. This is huge.

Honestly, you should simply add storing the exceptions permanently as a non-default option and retain the previous behaviour. Storing tracking information permanently defeats the whole point of running a separate, private browser.

[brampitoyo]

@hackel I totally agree with your point that switching from “Protection can only be temporarily turned off” to “Protection can be permanently turned off” is a huge change.

It’s a huge change, because we’re planning to block many more things other than trackers. Our future plan includes blocking ads, cookie notices, pre/interstitials, coin miners, and autoplaying media with sound. It also includes renaming the feature from “Tracking Protection” to “Content Blocking”.

The more elements we want to block, the more blocklists we have to use. The more blocklists we use, the more potential there is for sites to break (although we’ll only include reputable providers who frequently check for false positives, such as Fanboy and NoCoin). The more potentials there is for sites to break, the more necessary it becomes to have the ability to turn Content Blocking OFF permanently – but never globally and only on a per site basis.

In other words, if all we’re blocking are trackers, and if all we’re using are Disconnect’s lists, then our current behaviour is fine.

There are a few more things to note here:

• We do store the URLs allowed to load without Content Blocking, but don’t retain any data from those URLs. Tracking cookies may be allowed to load, but each time you tap “Erase”, they will also be erased. In other words, turning off Content Blocking permanently doesn’t protect your site data from erasure.
• We believe that most users will only do this as a last resort, where the only way to fix a site is to turn Tracking Protection off. Our tracking protection lists don’t have many false positives, so only a small minority of users will need to turn it off, and only turn it off on a small minority of sites.
• We also believe that, once a site problem is fixed through unblocking, users will want it to be fixed permanently. And if things can’t be made to “just work” easily, users will jump ship to their everyday browser. We think this usability compromise is worth the potential privacy cost of unblocking (hopefully) a minimal number of sites.
• If this feature is too frequently used at launch, then it indicates that our approach to Content Blocking has broken too many sites and needs to be re-evaluated.

For more thinking around this topic, see #957 (comment).

Hope this helps clarify our direction and thinking?

[hackel]

@brampitoyo Your first point above clarifies things, thanks. I misunderstood what "permanently" disabling tracking protection meant in this context. My concern was that data from an unblocked site would start accumulating, where previously I felt free to try disabling it without worrying about any side-effects down the road. It makes more sense that it will still be erased as expected.

[ekager]

So @brampitoyo am I understanding correctly that in the current state of the allowlist, TP, and toggle behavior, you don't think we need to change the strings in the menu?

[brampitoyo]

@ekager That’s correct. When we’re only using Disconnect’s lists, we’re as confident as they are that the list will be frequently updated and won’t cause too many site issues. No change in behaviour will be needed.

When we start to block other things and ship lists from other third parties (ie. block media that autoplay with sound, block ads with EasyList or EasyPrivacy), then the chance of brokenness will increase. This is when we need that permanent toggle, and an allow list.

What do you think?

[sv-ohorvath]

I was intending to propose a new request for adding a snackbar when TP is turned on/off, then I found this which is probably a good place for it.
Is it possible to add a snackbar at the bottom of the screen with something like "Added to exceptions list"/"Removed from exceptions list", same as for adding custom urls? It would be a good confirmation that the toggle is doing something and also would lead users to find out what the list is.
I'm happy to log a new issue if this doesn't belong here.

[ekager]

Hey @brampitoyo what do you think about adding a snackbar or toast when the toggle is switched to inform users what's happening behind the scenes now? Personally I like that idea @sv-ohorvath ! I think especially because we changed the behavior, this is an easy way to indicate what's going on

[vesta0]

@brampitoyo would love your thoughts on a snackbar (see above) or a similar in-app message.

[brampitoyo]

@vesta0 @ekager Do you think that surfacing the shield icon (#3705) would already solve this issue?

When tracking protection is off, users already get two signals that things aren’t the way they’re supposed to be:

1. The URL bar aren’t coloured. Very strong signal that this is no longer a full “Focus” experience.
2. The shield icon is crossed out. Equally strong signal, because the only way to see this icon is by first tapping on it, then turning it off.

I worry that having an un-dismissable snackbar/toast on top of this UX would be so annoying.

However, if the snackbar/toast:

1. Appears after the page has fully loaded – not while the page is loading – so the user can check whether the page is working or not; and
2. Disappears within a couple of seconds

Then it may be a good idea. Something along this line:

One thing to think about is the mindset of the user when they’re going through this process:

1. Something is broken on the site.
2. Onboarding and start screen tips have told me that I can tap on the shield to potentially fix this issue.
3. I tap on the shield and see a toggle with the description “Turning this off may fix some site problems”. I know that this is the right switch to flip.
4. I flip the switch. The page reloads and tells me that Content Blocking has been disabled.
5. Two possibilities:
   • The page is still broken. I think the issue is with something else. I can enable Content Blocking by tapping “Enable”.
   • The page now works properly. I do nothing. The banner notification disappears.

TL;DR I propose to have a snackbar/toast: one that appears after the site has finished loading, and one that disappears after a few seconds.

Thoughts?

[vesta0]

@brampitoyo sorry for delay in responding to this. I like your proposal to add a snackbar/toast (^^mock-up) that appears after the site has finished loading, and one that disappears after a few seconds.

@ekager let's do this if it's a small.

[sv-ohorvath]

Verified as done on Master (both GV & WV) 8.0.6.