[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #14059 [Tor Browser]: Revision of existing double key cookie logic to meet requirements



#14059: Revision of existing double key cookie logic to meet requirements
-------------------------+-------------------------------------------------
     Reporter:  michael  |      Owner:  michael
         Type:  defect   |     Status:  needs_information
     Priority:  normal   |  Milestone:
    Component:  Tor      |    Version:
  Browser                |   Keywords:  TorBrowserTeam201502R,
   Resolution:           |  GeorgKoppen201502R
Actual Points:           |  Parent ID:  #3246
       Points:           |
-------------------------+-------------------------------------------------
Description changed by michael:

Old description:

> Revise logic from #14058 to meet requirements implied in the #3246 mother
> bug and TBB online development meetings.
>
> Complete implementation of what is termed ''double keying'' as both 1st
> party hostname and 3rd party hostname are stored and conditionally used
> when constructing the ''Cookie'' HTTP header.
> ----
> = Nonfunctional requirements =
> == Adaption to common use cases ==
> Common browsing use cases involving cookies must be supported while
> protecting against crossdomain tracking violations. This includes travel
> reservations, shopping carts, surveys, comment providers, approval and
> rating systems, journalist drop boxes, and (one-time|two-factor)
> authentication systems.
>
> == Allow granular cookie inspection ==
> Fine grained cookie inspection must be enabled through new design of a
> user interface indexing either 1st or 3rd party URI contexts. This
> requirement does not specify the UI itself.
> ----
> = Functional requirements =
> == 3rd party cookie storage ==
> 3rd party cookies are stored under the usual conditions, according to the
> ''Set-Cookie'' HTTP header (RFC 6265.) Their storage structure enables
> 1st party association as a new measure.
>
> == 3rd party cookie retrieval ==
> 3rd party cookies are revealed according to host domain matching (RFC
> 6265) of 1st party URI contexts. This change mitigates the problem of
> identification across independent domains.
>
> == Legacy cookie behaviour ==
> New 3rd party isolation must not depend on legacy cookie behaviour
> configuraion '''network.cookie.cookieBehavior.'''
>
> == Conditional operation ==
> The configuration value '''privacy.thirdparty.isolate''' influences
> control of 3rd party cookie transmission. The '''private browsing channel
> attribute''' plays a binary role in enabling transmission but depends on
> '''privacy.thirdparty.isolate.'''
> ----
> = Unclassified requirements =
> == Complementary research ==
> Mark Nottingham's [https://tools.ietf.org/html/draft-nottingham-safe-
> hint/ IETF draft] and Alex Fowler's corresponding announcement of
> [https://blog.mozilla.org/privacy/2014/07/22/prefersafe-making-online-
> safety-simpler-in-firefox/ Prefer:Safe] include requirements relating to
> HTTP cookie control.
>
> The Mozilla B2G privacy panel and
> [https://blog.mozilla.org/privacy/2014/11/10/introducing-polaris-privacy-
> initiative-to-accelerate-user-focused-privacy-online/ announcement] of
> the [https://wiki.mozilla.org/Polaris Mozilla Polaris project] refer to
> 3rd party cookie control.

New description:

 Revise logic from #14058 to meet requirements implied in the #3246 mother
 bug and TBB online development meetings.

 Complete implementation of what is termed ''double keying'' as both 1st
 party hostname and 3rd party hostname are stored and conditionally used
 when constructing the ''Cookie'' HTTP header.
 ----
 = Nonfunctional requirements =
 == Adaption to common use cases ==
 Common browsing use cases involving cookies must be supported while
 protecting against crossdomain tracking violations. This includes travel
 reservations, shopping carts, surveys, comment providers, approval and
 rating systems, journalist drop boxes, and (one-time|two-factor)
 authentication systems.

 == Allow granular cookie inspection ==
 Fine grained cookie inspection must be enabled through new design of a
 user interface indexing either 1st or 3rd party URI contexts. This
 requirement does not specify the UI itself.

 == Application ==
 Logic must be applicable to the current [https://gitweb.torproject.org
 /tor-browser.git/ Tor Browser trunk.]
 ----
 = Functional requirements =
 == 3rd party cookie storage ==
 3rd party cookies are stored under the usual conditions, according to the
 ''Set-Cookie'' HTTP header (RFC 6265.) Their storage structure enables 1st
 party association as a new measure.

 == 3rd party cookie retrieval ==
 3rd party cookies are revealed according to host domain matching (RFC
 6265) of 1st party URI contexts. This change mitigates the problem of
 identification across independent domains.

 == Legacy cookie behaviour ==
 New 3rd party isolation must not depend on legacy cookie behaviour
 configuraion '''network.cookie.cookieBehavior.'''

 == Conditional operation ==
 The configuration value '''privacy.thirdparty.isolate''' influences
 control of 3rd party cookie transmission. The '''private browsing channel
 attribute''' plays a binary role in enabling transmission but depends on
 '''privacy.thirdparty.isolate.'''

 == Logging facility ==
 New logic must approximate the logging behaviour of legacy cookie logic.
 ----
 = Unclassified requirements =
 == Complementary research ==
 Mark Nottingham's [https://tools.ietf.org/html/draft-nottingham-safe-hint/
 IETF draft] and Alex Fowler's corresponding announcement of
 [https://blog.mozilla.org/privacy/2014/07/22/prefersafe-making-online-
 safety-simpler-in-firefox/ Prefer:Safe] include requirements relating to
 HTTP cookie control.

 The Mozilla B2G privacy panel and
 [https://blog.mozilla.org/privacy/2014/11/10/introducing-polaris-privacy-
 initiative-to-accelerate-user-focused-privacy-online/ announcement] of the
 [https://wiki.mozilla.org/Polaris Mozilla Polaris project] refer to 3rd
 party cookie control.

--

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/14059#comment:17>
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