1602715 - Make Protections UI support Dynamic FPI

Status: RESOLVED FIXED

(Firefox :: Protections UI, task)

Description

[Gary Chen [:xeonchen]]

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.

Comment 1

[(no longer active)]

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.

Comment 2

[Johann Hofmann [:johannh]]

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).

Comment 3

[(inactive) Nihanth Subramanya [:nhnt11]]

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?

Comment 4

[(inactive) Nihanth Subramanya [:nhnt11]]

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

Comment 5

[(no longer active)]

(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.

Comment 6

[(no longer active)]

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.

Comment 7

[Gary Chen [:xeonchen]]

Attachment: Bug 1602715 - support `cookieBehavior=5` in protection UI; r=nhnt11

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/019a06257bf8
support `cookieBehavior=5` in protection UI; r=nhnt11

Comment 10

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/019a06257bf8