Re: [tor-bugs] #14061 [Tor Browser]: Develop a new cookie inspector accommodating double key logic

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#14061: Develop a new cookie inspector accommodating double key logic
-----------------------------+----------------------------------
     Reporter:  michael      |      Owner:  tbb-team
         Type:  enhancement  |     Status:  new
     Priority:  normal       |  Milestone:
    Component:  Tor Browser  |    Version:
   Resolution:               |   Keywords:  TorBrowserTeam201506
Actual Points:               |  Parent ID:  #3246
       Points:               |
-----------------------------+----------------------------------

Comment (by michael):

 Replying to [comment:8 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.)
 [[br]]
 > 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 security slider, your
 [https://bugzilla.mozilla.org/show_bug.cgi?id=777620 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?'''
 [[br]]
 > 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[[br]]...since that gets
 complex and would benefit from in depth usability testing.

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

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/14061#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs