commit 65eea97d5006c0daaa68266e47c92821aa7109fc Author: Mike Perry <mikeperry-git@fscked.org> Date: Thu Sep 29 18:37:51 2011 -0700 Add cookie managers graphic. --- docs/design/CookieManagers.png | Bin 0 -> 121020 bytes docs/design/design.xml | 66 +++++++++++++++++++++++++--------------- 2 files changed, 42 insertions(+), 24 deletions(-) diff --git a/docs/design/CookieManagers.png b/docs/design/CookieManagers.png new file mode 100644 index 0000000..b979f30 Binary files /dev/null and b/docs/design/CookieManagers.png differ diff --git a/docs/design/design.xml b/docs/design/design.xml index cc2b27b..2c87e74 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -540,26 +540,29 @@ permissions can be written to disk. Otherwise, they should remain memory-only. <para> Filter-based addons such as <ulink -url="https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/">AdBlock Plus</ulink>, <ulink -url="">Request Policy</ulink>, <ulink url="http://priv3.icsi.berkeley.edu/">Priv3</ulink>, and <ulink +url="https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/">AdBlock +Plus</ulink>, <ulink url="">Request Policy</ulink>, <ulink +url="http://priv3.icsi.berkeley.edu/">Priv3</ulink>, and <ulink url="http://sharemenot.cs.washington.edu/">Sharemenot</ulink> are to be -avoided. We believe -that these addons do not add any real privacy to a proper <link -linkend="Implementation">implementation</link> of -the above <link linkend="privacy">privacy requirements</link>, as all third parties are prevented from -tracking users between sites by the implementation. Furthermore, filter-based -addons can introduce strange breakage and cause usability nightmares, and will also -fail to do their job if an adversary simply registers a new domain or creates -a new url path. - -<!-- XXX: Don't forget: Filters are also crazy fingerprintable --> +avoided. We believe that these addons do not add any real privacy to a proper +<link linkend="Implementation">implementation</link> of the above <link +linkend="privacy">privacy requirements</link>, as all third parties are +prevented from tracking users between sites by the implementation. +Filter-based addons can also introduce strange breakage and cause usability +nightmares, and will also fail to do their job if an adversary simply +registers a new domain or creates a new url path. Worse still, the unique +filter sets that each user is liable to create/install likely provide a wealth +of fingerprinting targets. + </para> <para> -Furthermore, we are generally opposed to shipping an always-on Ad blocker with -Tor Browser. We feel that this would damage our credibility in terms of -demonstrating that we are providing privacy through a sound design alone, as -well as damage the acceptance of Tor users by sites who support themselves -through advertising revenue. + +As a general matter, we are also generally opposed to shipping an always-on Ad +blocker with Tor Browser. We feel that this would damage our credibility in +terms of demonstrating that we are providing privacy through a sound design +alone, as well as damage the acceptance of Tor users by sites who support +themselves through advertising revenue. + </para> <para> Users are free to install these addons if they wish, but doing @@ -739,7 +742,7 @@ XXX: Write me.. --> <sect2 id="identifier-linkability"> <title>Cross-Domain Identifier Unlinkability</title> - <!-- XXX: Mention web-send?? --> + <!-- FIXME: Mention web-send?? --> <para> The Tor Browser MUST prevent a user's activity on one site from being linked @@ -763,11 +766,28 @@ six or seven different pieces of privacy UI governing these identifiers and permissions can become just one piece of UI. For instance, a window that lists the top-level url bar domains for which browser state exists with the ability to clear and/or block them, possibly with a context-menu option to drill down -into specific types of state. - -<!-- XXX: Include graphic as a 'Design Goal' --> +into specific types of state. An exmaple of this simplifcation can be seen in +Figure 1. </para> + <figure><title>Improving the Privacy UI</title> + <mediaobject> + <imageobject> + <imagedata align="center" fileref="CookieManagers.png"/> + </imageobject> + </mediaobject> + <caption> <para/> + +On the left is the standard Firefox cookie manager. On the right is a mock-up +of how isolating identifiers to the URL bar domain might simplify the privacy +UI for all data - not just cookies. Both windows represent the set of +Cookies accomulated after visiting just five sites, but the window on the +right has the option of also representing history, DOM Storage, HTTP Auth, +search form history, login values, and so on within a context menu for each +site. + +</caption> + </figure> <orderedlist> <listitem>Cookies <para><command>Design Goal:</command> @@ -1198,13 +1218,11 @@ a new circuit to be created. </blockquote> </sect3> - <para> -XXX: Cookie protections.. <!-- XXX: Missing pieces: 1. DOM Storage? IIRC, it is cleared, but also disabled anyway. 2. Do we kill keep-alive connections properly? +XXX: Cookie protections.. --> - </para> </sect2> <sect2 id="click-to-play"> <title>Click-to-play for plugins and invasive content</title>