Closed Bug 1643191 Opened 4 years ago Closed 4 years ago

Display storage access exceptions as permissions in the identity panel

Categories

(Firefox :: Site Identity, enhancement, P2)

enhancement

Tracking

()

VERIFIED FIXED
84 Branch
Tracking Status
firefox84 --- verified

People

(Reporter: englehardt, Assigned: nhnt11)

References

(Depends on 4 open bugs)

Details

Attachments

(5 files)

The protections panel only displays tracking domains. It does not display non-tracking domains. There are two questions we need to answer:

  1. Do we want to show isolated third-party domains in the protection panel.
  2. How we want to show domains with a storage access exception.

I'm inclined to say no to (1). Isolated storage is more intuitive for users, so it feels like dFPI is just aligning our underlying storage to that intuitive model. Our approach for (2) may depend on what we do for (1).

We definitely need a way for power users to check and delete storage access grants for a specific first party. The current model buries storage access permissions behind panels as shown in the attached screenshots (here I've simulated that englehardt-tracker.com is a tracker using urlclassifier.trackingAnnotationTable.testEntries). The "Allowed" language doesn't seem right since that origin's cookies aren't initially "blocked".

Attached image allowed_panel.png

In the meeting I proposed removing the [x] UI and instead having something like:

---------------------------
The following websites are currently allowed to use cookies to track your visit on example.com:
google.com, facebook.com, twitter.com
[ Revoke Access ]
---------------------------

As a section in the main protections panel. Just a very rough idea, though.

(In reply to Johann Hofmann [:johannh] from comment #3)

In the meeting I proposed removing the [x] UI and instead having something like:

---------------------------
The following websites are currently allowed to use cookies to track your visit on example.com:
google.com, facebook.com, twitter.com
[ Revoke Access ]
---------------------------

As a section in the main protections panel. Just a very rough idea, though.

I think this is much better than the current display, both for normal ETP and for dFPI.

The simplest approach I can imagine (UI-wise) is to add a new category called "Partitioned" with a sub-item called "Third-party Cookies". This would be functionally equivalent to the UI when all third-party cookies are blocked. That seems sufficient for a study and simpler to define, but I'm not sure how much platform work is required to support that (i.e., are partitioned cookies discoverable by the UI). Do you have a sense for whether it's worth going down a simple road like this for the study, and working on the redesign in parallel?

Regarding technical feasibility: Both approaches are doable and I think both not very difficult. The "partitioned panel" requires a bit less UX work of course since we sort of have the other panels to copy from.

Taking a step back and looking at who's our audience for this UI, I don't think we can really just expose "Partitioned" to users in the protections panel and call it a day. I would guess that the vast majority of people who use that panel are somewhat technical as in they follow tech blogs occasionally and have an opinion on which browser, OS or phone they use. But I wouldn't think that partitioned storage is a concept we can convey to them. On the flip side, we've heard from UR that users tend to be scared/disengaged if they don't understand our UI.

I think it's cool that we give users the ability to see trackers that were on the page so that they can share it with their friends or just feel protected. We shouldn't undermine it by adding complexity for the sake of correctness (and I don't think there's any, say, legal requirement to precisely list all our anti-tracking mechanisms in that panel).

We should absolutely give this prime time support in devtools, though. That's unfortunately an area where our team has a little less direct control over, code-wise.

Blocks: dfpi-mvp-ui
No longer blocks: dfpi-study-ui

We've decided to go something that roughly matches Johann's description in Comment 3. We suggest the following design (subject to UX feedback):

  1. List all third-party origins that have a storage access permission on the current site in a separate section. These should not be hidden in the "fold-out" subpanel (e.g., Comment 2). This will include storage access permissions granted via the storage access API, ETP heuristics, or dFPI heuristics. We don't see a need to differentiate between how these permissions were added within the UI.
  2. The new section should go in the Protections Panel (i.e., the shield). We discussed the possibility of having it in the Permissions panel, but decided against it for a few reasons: it's unclear how to display the individual storage access grants (no other permission has that context), it's away from the rest of the context the user has about tracker blocking (e.g., who is blocked, whether ETP is disabled for the site).
  3. The section could say something like: “Firefox is preventing third parties from tracking you on this site, except the following ones which you’ve interacted with:” The section would then list a series of third-party origins with the word "Revoke" next to each one. The user could then individually revoke access as desired.
  4. We should have hover text that explains why or how these permissions are granted. A "Learn more" link could also be helpful.
  5. When a user interacts with the Storage Access API, we show a hint that lets the user know they can manage their storage access permissions in the protections panel. We don't think we should show this when the heuristics are activated, since that may be jarring for the user and feel out of context (the heuristics are silent).
  6. Remove the "Allowed" UI (i.e., Comment 2) once this has landed.

Telemetry: It would be great to understand how many users manage their exceptions / interact with the panel compared to how many users overall have an exception set.

Questions/concerns for UX:

  1. The protections panel is quite busy, and we worry that adding another sub-section could overload users with technical information. Ultimately this still seems better than the alternative of adding it to the permissions panel where it feels out of place.
  2. Right now automatically granted storage access permissions are super buried and non-intuitive (see Comment 2). By making this more visible, we're concerned that some users may be surprised that a specific tracker (e.g., Google or Facebook) was automatically granted storage access. The hover text and/or Learn more link mentioned in (4) can help hedge against this, but we're not sure if it's enough or if there's a better way. (We don't want to go back to burying this information as a solution)
Summary: Determine how to display isolated storage + storage access exceptions in the protections panel → Display storage access exceptions in the protections panel
Flags: needinfo?(senglehardt)
Flags: needinfo?(senglehardt)
Assignee: nobody → nhnt11
Severity: -- → S3
Priority: -- → P2
Severity: S3 → N/A
Depends on: 1651137
Attachment #9183706 - Attachment description: Bug 1643191 - [WIP] Show storage access permissions in the identity panel. r=pbz! → Bug 1643191 - Show storage access permissions in the identity panel. r=pbz!,johannh!
Depends on: 1674958
Depends on: 1675198
Pushed by nhnt11@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/2ec6433cb132
Show storage access permissions in the identity panel. r=pbz,fluent-reviewers,johannh,flod
https://hg.mozilla.org/integration/autoland/rev/182c7b082c6f
Add a test for the 3rdPartyStorage permissions. r=pbz
https://hg.mozilla.org/integration/autoland/rev/f4e0f0aa3004
Check for 3rdPartyStorage permission items in identity panel in storage access doorhanger test. r=timhuang
Component: Privacy: Anti-Tracking → Site Identity
Product: Core → Firefox
Summary: Display storage access exceptions in the protections panel → Display storage access exceptions as permissions in the identity panel
Depends on: 1676074
Depends on: 1676861
Flags: qe-verify+

Verified as fixed with Firefox 84.0b8 and Fx 85.0a1 with Windows 10x64, macOS 10.13.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: