[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