Develop a new cookie inspector accommodating double key logic

New concept

Design and implement a cookie inspector resembling the concept graphic suggested by mikeperry:

Existing reuse

An alternative design to be considered involves reusing the existing ESR cookie representation while adding a widget controlling indexing of cookies by 1st or 3rd party contexts: This design could be improved by allowing quick changes of indexing via a widget directly on the cookie inspector interface.

Challenges

• Mitigate the listing of duplicate (hidden in legacy 3rd party cookie logic) 3rd party cookies, otherwise bloating cookie lists considerably.
• Avoid forcing the user to inspect cookies by one of 1st or 3rd party keys, and support choice of either indexing method.
• Allow the user to find individual cookies at least as easily as preexisting representations allow, and avoid exaggerated scrolling.

---

Requirements

To be announced.

Trac:
Username: michael

added component::applications/tor browser owner::tbb-team parent::3246 priority::medium reporter::michael resolution::wontfix status::closed type::enhancement labels

Trac:
Username: michael
Status: new to assigned
Owner: to < default >

Trac:
Username: michael
Owner: < default > to tbb-team

Trac:
Username: michael
Summary: Develop a new cookie inspector accommodating dual keys to Develop a new cookie inspector accommodating double keys

Trac:
Username: michael
Summary: Develop a new cookie inspector accommodating double keys to Develop a new cookie inspector accommodating double key logic

Trac:
Username: michael
Status: assigned to new

Trac:
Username: michael
Keywords: N/A deleted, TorBrowserTeam201506 added

Trac:
Cc: N/A to brade, mcs

I am wondering why we need a new cookie inspector at all? "Show Cookies..." should be the one showing you the cookies and domain they are bound to, I think. Which requires fixing https://bugzilla.mozilla.org/show_bug.cgi?id=777620 which is probably needed anyway.

Mike's idea is not cookie specific and introducing it just for cookies might therefore be confusing. What do you have in mind with the alternative design? I think I did not get that one.

Trac:
Cc: brade, mcs to brade, mcs, gk

Replying to gk:

I am wondering why we need a new cookie inspector at all? "Show Cookies..." should be the one showing you the cookies and domain they are bound to, I think.

I assume that Mike's graphic implies the function of clicking a 1st party domain/favicon to drill down into cookie names where associated 3rd party cookies are specially marked. This assumption is based on a contract/bounty titled UI support for double-keyed cookies but it's possible that the correct interpretation is implement double-keyed UI support for the old cookie inspector design only.

Old cookie inspector design

When interpreting that, note that the latter is a NOOP and the old cookie inspector works just the same after applying the double keying patch. That means that the cookie inspector ignores 1st/3rd party context, displaying all cookies indexed by their corresponding HTTP host header.

Should we implement a graphical indication of party context? If yes, we need to decide on one of the many UI designs contrasting cookie representations lacking a 3rd party context from those including them, as well as deciding on how much UI support to provide (indexing and search strategy, exposing configuration, etcetera.)

Mike's idea is not cookie specific and introducing it just for cookies might therefore be confusing.

It might be time to reevaluate UI design since making so many party isolation changes (along with your cool #9387 (moved) security slider, your B2G and channel referral, and other relevant UI considerations.)

Should we free this child ticket and redefine it to specify all party isolation UI improvements?

What do you have in mind with the alternative design?

My intentions are not part of this, but if I wanted to indicate cookie party association:

• I would stick to tabular text instead of a graphic representation.

• I don't know what style of indexing/searching and inspector configuration widget (a slider?) to provide ...since that gets complex and would benefit from in depth usability testing.

Cookie party association UI is dependent on unresolved questions from other #3246 (moved) child tickets and maybe even non cookie ones. Should we put this on hold since the old inspector is working just fine?

Trac:
Username: michael

Trac:
Username: michael
Status: new to needs_information

A stellar discussion on PBM UI which subordinates a privacy sensitive cookie inspector has been posted.

Trac:
Username: michael

Replying to michael:

A stellar discussion on PBM UI which subordinates a privacy sensitive cookie inspector has been posted.

...and there's the B2G motherbug (which may or may not relate to TB UI simplification.)

Trac:
Username: michael

Trac:
Keywords: TorBrowserTeam201506 deleted, N/A added

No need for those tickets on our side anymore as Mozilla implemented double-keying of cookies which we ship in 7.0a3 when we switch to ESR 52.

Trac:
Status: needs_information to closed
Resolution: N/A to wontfix

closed

mentioned in issue #14062 (moved)

moved to tpo/applications/tor-browser#14061 (closed)

mentioned in issue tpo/applications/tor-browser#14062 (closed)