[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [tor-browser-spec/master] Add cookie managers graphic.
commit 65eea97d5006c0daaa68266e47c92821aa7109fc
Author: Mike Perry <mikeperry-git@xxxxxxxxxx>
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>
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits