[UX] Tracking Protection

[lime124]

TP should be on by default with the option to disable by user.

We need to think about:

• what settings this feature may need to have
• how can we control this from the site page
• do we use the existing on/off patterns from focus
• do we want to show any UI like ios focus
• do we want to surface # of trackers blocked
• do we want to surface the type of trackers blocked (post MVP)
• how do we let users know that they can turn this feature off if their site/video isn't loading
• do we want users to be able to turn TP off for specific sites (allowlist)
• Disconnect attribution
• Types of trackers blocked (disconnect lists):
  Ads
  Analytics
  Social Media
  Content
  Cryptomining
  Fingerprinting

Invision Spec:
https://mozilla.invisionapp.com/share/Q5RJ982HY23

┆Issue is synchronized with this Jira Task

[vesta0]

Added some additional notes and considerations to the description.

[brampitoyo]

@vesta0 @lime124 – @mheubusch and I talked about my initial design proposal for Enhanced Content Blocking. The document is at a good point to share with Engineering.

Our goal next week is to schedule a meeting with @st3fan and find out which part of the proposal is technically plausible for MVP, and which part we should hold off until post-MVP.

[brampitoyo]

@vesta0 @st3fan @lime124 Progress report:

• I’ve updated my proposal document to say that we should turn TP on everywhere
  • It’s simpler than before – where normal browsing only blocks tracking cookies, and private browsing has TP on.
  • This should be complemented with a pre-MVP site audit of top sites. We believe that TP doesn’t break many sites. We’ve even researched it. Now we need to catch all the edge cases and report them to Disconnect.me, so they can ship an updated list that’s even better.
• I’ve mocked up how TP will interact with other parts of the app (URL bar, site info panel, Site permission settings, Exceptions, etc.)
  • @mheubusch has reviewed it and submitted some great feedback
  • I’ve answered them and modified the design where necessary
  • Michelle and I will iterate a few times, until we reach a point where we think that the design is relatively bulletproof and ready to post here

[sblatz]

@lime124 to link to mocks

[lime124]

uh no idea how i closed this sorry

[shorlander]

@st3fan Hi! This is ready for Feedback, is there someone assigned to this area?

[vesta0]

@brampitoyo thanks for the designs, looks great! One comment: it may not be very clear in the doorhanger UI right now that turning the toggle off will add the site to the Exceptions list. Maybe just a string below the toggle would suffice but I’ll leave that to you to decide how you'd like to handle it.

[brampitoyo]

Hi @vesta0,

[…] it may not be very clear in the doorhanger UI right now that turning the toggle off will add the site to the Exceptions list

That’s fine. The exceptions list inside Settings isn’t a preferred way to manage Tracking Protection. Why? Because modifying TP when a site is currently open allows you to observe its effects directly. If you want to see whether a site issue will be fixed by toggling TP off, it helps to be able to see a before and after.

Should users feel the need to turn TP off globally (which we don’t recommend), they can go to Settings. In that process, they will discover an overview list of all TP exceptions.

[ekager]

Could someone on UX let me know if this "Report a Problem" page is required for MVP? Where does that report go? For the first iteration of eng work (so in Nightly now), I just linked the normal report site issue that goes to webcompat.

[AmyYLee]

@brampitoyo @mheubusch Do you have insight on where the "Report a Problem" page goes to and is it required for MVP? See above

[kbrosnan]

On desktop it goes to https://$IETF_BCP_47_LANG.phish-error.mozilla.com/?hl=$IETF_BCP_47_LANG&url=$PERCENT_ESCAPED_URL

For example https://en-us.phish-error.mozilla.com/?hl=en-US&url=https%3A%2F%2Ftestsafebrowsing.appspot.com%2Fs%2Fphishing.html

From https://testsafebrowsing.appspot.com/s/phishing.html

[brampitoyo]

@ekager @kbrosnan @AmyYLee This dialogue mirrors the “Report a problem” dialogue found on Desktop Tracking Protection:

I think that Fenix reports should go to the same place that desktop reports are being sent to.

Since turning TP off can already solve problems, TP reporting is probably not required for MVP.

[topotropic]

@brampitoyo how do I get to the "Report Problem" section on desktop?

[brampitoyo]

@topotropic Go to a site like cnn.com, then open the site information panel. Content Blocking will be active, since the site has blockable trackers.

You’ll see “Report a problem” as a link on the bottom of the “Content Blocking” section.

[ekager]

@topotropic (since Amy is PTO) do we always want TP on for private browsing? If so should we be hiding or disabling the TP Quick Settings toggle when the user is in private browsing?

[yoasif]

I think TP should be enabled by default in private browsing, but should be able to be toggled off [keeping the toggle], but the preference should not be stored (otherwise, it isn't really "private").

This is how Focus works, as far as I can tell.

[ekager]

Thanks for your feedback. I'm concerned that your suggestion could be confusing UX because in normal browsing, toggling the TP in the quick settings sheet adds the site to the exceptions list. Having different actions for Private mode and Normal Browsing on the same toggle doesn't seem very intuitive.

[yoasif]

I definitely understand the concern about the possibilities of a confusing UX, but the alternatives seem worse:

1. keep TP as default in PB, but save preference - this is bad for privacy
2. keep TP as default in PB, but don't allow disabling TP - to allow pages to load correctly, users have to use non-PB browsing, which feels really weird
3. disable TP by default - this is contrary to the way desktop and Fennec work, and ends up being less private than the default non-PB mode in Fenix

How about instead of a toggle, it is a button instead? "disable TP for this session" or something with a better label that means the same thing.

That way it is clear that the preference is not stored.

[vesta0]

@mheubusch @lime124 please review the current implementation and confirm that it matches the basic tracking protection mocks for MVP and close this.

For post-mvp, I have created a new Meta #2594 to track the updated mocks with advanced settings. Feel free to open a new UX ticket to track against #2594

[topotropic]

For MVP we should go with the current implementation – if we don't introduce new UI, I agree with @ekager, that the UX is going to be confusing. I'd suggest to review this as part of the new meta #2594

[vesta0]

@topotropic sounds good. Please close this issue and open a new UX issue to track the UX work needed for #2594

[vesta0]

@mheubusch can we close this issue?