Display storage access exceptions as permissions in the identity panel
Categories
(Firefox :: Site Identity, enhancement, P2)
Tracking
()
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:
- Do we want to show isolated third-party domains in the protection panel.
- 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".
Reporter | ||
Comment 1•4 years ago
|
||
Reporter | ||
Comment 2•4 years ago
|
||
Comment 3•4 years ago
•
|
||
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.
Reporter | ||
Comment 4•4 years ago
|
||
(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?
Comment 5•4 years ago
|
||
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.
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Comment 6•4 years ago
•
|
||
We've decided to go something that roughly matches Johann's description in Comment 3. We suggest the following design (subject to UX feedback):
- 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.
- 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).
- 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.
- We should have hover text that explains why or how these permissions are granted. A "Learn more" link could also be helpful.
- 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).
- 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:
- 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.
- 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)
Reporter | ||
Updated•4 years ago
|
Comment 7•4 years ago
|
||
Please see slides 11-14 for draft UX proposal, with two options: https://docs.google.com/presentation/d/1OWIVLOVyWHmqr385W6KSA_HupFa7m3XfCwmkKJZacBs/edit?ts=5ef4c6a7#slide=id.g8ab94f0ae1_5_3
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Updated•4 years ago
|
Assignee | ||
Comment 8•4 years ago
|
||
Updated•4 years ago
|
Assignee | ||
Comment 9•4 years ago
|
||
Depends on D94703
Assignee | ||
Comment 10•4 years ago
|
||
Assignee | ||
Comment 11•4 years ago
|
||
Depends on D95655
Assignee | ||
Comment 12•4 years ago
|
||
Comment 13•4 years ago
|
||
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
Assignee | ||
Updated•4 years ago
|
Comment 14•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/2ec6433cb132
https://hg.mozilla.org/mozilla-central/rev/182c7b082c6f
https://hg.mozilla.org/mozilla-central/rev/f4e0f0aa3004
Updated•4 years ago
|
Comment 15•3 years ago
|
||
Verified as fixed with Firefox 84.0b8 and Fx 85.0a1 with Windows 10x64, macOS 10.13.
Updated•3 years ago
|
Description
•