Closed Bug 1602715 Opened 3 months ago Closed 1 month ago

Make Protections UI support Dynamic FPI

Categories

(Firefox :: Protections UI, task)

task
Not set

Tracking

()

RESOLVED FIXED
Firefox 74
Tracking Status
firefox74 --- fixed

People

(Reporter: xeonchen, Assigned: xeonchen, NeedInfo)

References

(Blocks 2 open bugs)

Details

Attachments

(1 file)

In https://searchfox.org/mozilla-central/source/browser/base/content/browser-siteProtections.js it doesn't handle the case when network.cookie.cookieBehavior=5, we should check this value and make it display correctly.

One question is how we want the UI to look like. For simplicity I would suggest pretending we're in cookieBehavior=4 mode, that is, show what's blocked (as if normal ETP was in effect) and don't show anything about what's partitioned.

I agree that this seems like the easiest thing to do that is not too misleading. It would work best if we would replace the word "Blocked" with something like "Restricted" (since that could mean both blocked and isolated).

Adding Betsy. If we use a word like "Restricted" we'll have to figure out a way for users to be able to discover what that means. Also need to think about how this will fit into the blocked/allowed/none detected categories and whether that classification needs to be rethought.

Personally I think that we shouldn't expose complexity to users. Perhaps we can provide details in the subview after the category item is clicked?

Johann, did you mean to completely replace our usage of the word "blocked" with "restricted"? That could work, but I'm a fan of keeping language simple and stable. WDYT?

Flags: needinfo?(bmikel)

FWIW I agree with Ehsan's proposal to treat 5 and 4 equivalently at least for now.

Assignee: nobody → xeonchen

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

I agree that this seems like the easiest thing to do that is not too misleading. It would work best if we would replace the word "Blocked" with something like "Restricted" (since that could mean both blocked and isolated).

Um, why? In this mode, what gets blocked in normal ETP (cookieBehavior=4) would still be blocked.

Before this gets super complex maybe I should add a little bit more context here.

  • The exact behaviour of this blocking mode hasn't been decided yet, so spending a lot of time designing user interface around what we have at this stage is probably not a good idea, as some or many parts of what we have now may change. (For example: we may decide to block more cookies, who knows?!)
  • We're not going to run user tests on this feature yet, or advertise it to users, and there will be no way to activate it in Firefox except for knowing the secret number in about:config. So the UI is really only targeted at the few folks who are working on the feature at various capacities, and various deficiencies may be possible to tolerate for now (see above).
  • The current feature expands what the existing ETP feature does, that is, it does some extra things on top of ETP. IOW what currently gets blocked in ETP will get blocked in DFPI as well. For the rest, DFPI partitions the storage based on the eTLD+1 domain of the top-level page, such that site data from news.example always gets separated from social.example. Exactly as if we had one container per top-level eTLD+1.
  • The current bug is filed to make the UI understandable for the developers working on the feature, by making sure the code works and doesn't throw exceptions etc., and shows something very close to what we have with ETP, given that this feature expands it.
Depends on: 1611559
No longer depends on: 1611559
Duplicate of this bug: 1611559
Attachment #9124224 - Attachment description: Bug 1602715 - support `cookieBehavior=5` in protection UI; r=johannh → Bug 1602715 - support `cookieBehavior=5` in protection UI; r=nhnt11
Pushed by xeonchen@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/019a06257bf8
support `cookieBehavior=5` in protection UI; r=nhnt11
Status: NEW → RESOLVED
Closed: 1 month ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 74
You need to log in before you can comment on or make changes to this bug.