- tor-commits - lists.torproject.org

r24676: {projects} Fix more minor issues (projects/articles/browser-privacy)
by Robert Ransom 26 Apr '11

26 Apr '11

Author: rransom Date: 2011-04-26 15:05:12 +0000 (Tue, 26 Apr 2011) New Revision: 24676 Modified: projects/articles/browser-privacy/W3CIdentity.tex Log: Fix more minor issues Modified: projects/articles/browser-privacy/W3CIdentity.tex =================================================================== --- projects/articles/browser-privacy/W3CIdentity.tex 2011-04-26 15:04:37 UTC (rev 24675) +++ projects/articles/browser-privacy/W3CIdentity.tex 2011-04-26 15:05:12 UTC (rev 24676) @@ -343,17 +343,20 @@ what is going on with respect to the user's relationship to the web. However, all current private browsing modes fall short of protecting against a -network adversary and fail to deal with linkability against a network +network-level adversary and fail to deal with linkability against such an adversary\cite{private-browsing}, claiming that it is outside their threat model\footnotemark. If the user is given a new identity that is still linkable to the previous one due to shortcomings of the browser, this approach has failed as a privacy measure. +% XXXX Define network-level adversary. -\footnotetext{The primary reason given to abstain from addressing the network -adversary is IP address linkability. However, we believe this to be a red +\footnotetext{The primary reason given to abstain from addressing a +network-level +adversary is IP-address linkability. However, we believe this to be a red herring. Users are quite capable of using alternate Internet connections, and it is common practice for ISPs in many parts of the world to rotate user IP -addresses daily, to discourage servers and to impede the spread of malware. +addresses daily, to discourage users from operating servers and to impede the +spread of malware. This is especially true of cellular IP networks.} Linkability solutions within the identity framework would be similar to the

1 0

[tor/master] Don't leak the local hostname in relay nicknames
by nickm＠torproject.org 26 Apr '11

26 Apr '11

commit 4c789ec08c8d52c3aab3ab775a86fe2350d584b5 Author: Sebastian Hahn <sebastian(a)torproject.org> Date: Tue Apr 26 05:07:37 2011 +0200 Don't leak the local hostname in relay nicknames Fixes bug 2979, reported by tagnaq. --- changes/bug2979 | 9 ++++++++ src/or/config.c | 55 ------------------------------------------------------ src/or/dirserv.h | 2 +- 3 files changed, 10 insertions(+), 56 deletions(-) diff --git a/changes/bug2979 b/changes/bug2979 new file mode 100644 index 0000000..fe1f45f --- /dev/null +++ b/changes/bug2979 @@ -0,0 +1,9 @@ + o Minor bugfixes: + - If the Nickname configuration option wasn't given, Tor used to pick + a nickname based on the local hostname as the nickname for a relay. + Because nicknames are not very important in today's Tor and the + "Unnamed" nickname has been implemented, this is now problematic + behaviour: It leaks information about the hostname without being + useful at all. Bugfix on tor-0.1.2.2-alpha, which introduced the + Unnamed nickname. Fixes bug 2979, reported by tagnaq. + diff --git a/src/or/config.c b/src/or/config.c index 3770301..9675c73 100644 --- a/src/or/config.c +++ b/src/or/config.c @@ -2500,54 +2500,6 @@ is_local_addr(const tor_addr_t *addr) return 0; } -/** Called when we don't have a nickname set. Try to guess a good nickname - * based on the hostname, and return it in a newly allocated string. If we - * can't, return NULL and let the caller warn if it wants to. */ -static char * -get_default_nickname(void) -{ - static const char * const bad_default_nicknames[] = { - "localhost", - NULL, - }; - char localhostname[256]; - char *cp, *out, *outp; - int i; - - if (gethostname(localhostname, sizeof(localhostname)) < 0) - return NULL; - - /* Put it in lowercase; stop at the first dot. */ - if ((cp = strchr(localhostname, '.'))) - *cp = '\0'; - tor_strlower(localhostname); - - /* Strip invalid characters. */ - cp = localhostname; - out = outp = tor_malloc(strlen(localhostname) + 1); - while (*cp) { - if (strchr(LEGAL_NICKNAME_CHARACTERS, *cp)) - *outp++ = *cp++; - else - cp++; - } - *outp = '\0'; - - /* Enforce length. */ - if (strlen(out) > MAX_NICKNAME_LEN) - out[MAX_NICKNAME_LEN]='\0'; - - /* Check for dumb names. */ - for (i = 0; bad_default_nicknames[i]; ++i) { - if (!strcmp(out, bad_default_nicknames[i])) { - tor_free(out); - return NULL; - } - } - - return out; -} - /** Release storage held by <b>options</b>. */ static void config_free(config_format_t *fmt, void *options) @@ -2976,14 +2928,7 @@ options_validate(or_options_t *old_options, or_options_t *options, if (options->Nickname == NULL) { if (server_mode(options)) { - if (!(options->Nickname = get_default_nickname())) { - log_notice(LD_CONFIG, "Couldn't pick a nickname based on " - "our hostname; using %s instead.", UNNAMED_ROUTER_NICKNAME); options->Nickname = tor_strdup(UNNAMED_ROUTER_NICKNAME); - } else { - log_notice(LD_CONFIG, "Choosing default nickname '%s'", - options->Nickname); - } } } else { if (!is_legal_nickname(options->Nickname)) { diff --git a/src/or/dirserv.h b/src/or/dirserv.h index 569abfc..a8a7060 100644 --- a/src/or/dirserv.h +++ b/src/or/dirserv.h @@ -52,7 +52,7 @@ MAX_V_LINE_LEN \ ) -#define UNNAMED_ROUTER_NICKNAME "Unnamed" +#define UNNAMED_ROUTER_NICKNAME "Unnamed" int connection_dirserv_flushed_some(dir_connection_t *conn);

1 0

[tor/master] Merge remote-tracking branch 'origin/maint-0.2.2'
by nickm＠torproject.org 26 Apr '11

26 Apr '11

commit 075d904d3935bdc5c608c1e17be835e600d6990c Merge: 5230cc4 4c789ec Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Apr 26 11:05:54 2011 -0400 Merge remote-tracking branch 'origin/maint-0.2.2' Conflicts: src/or/dirserv.h changes/bug2979 | 9 +++++++++ src/or/config.c | 55 ------------------------------------------------------- 2 files changed, 9 insertions(+), 55 deletions(-)

1 0

r24675: {projects} Fix more minor issues ?\226?\128?\156password-protected?\226 (projects/articles/browser-privacy)
by Robert Ransom 26 Apr '11

26 Apr '11

Author: rransom Date: 2011-04-26 15:04:37 +0000 (Tue, 26 Apr 2011) New Revision: 24675 Modified: projects/articles/browser-privacy/W3CIdentity.tex Log: Fix more minor issues ?\226?\128?\156password-protected?\226?\128?\157 implies ?\226?\128?\156encrypted?\226?\128?\157 these days, to anyone who has any business using the word ?\226?\128?\156privacy?\226?\128?\157. Modified: projects/articles/browser-privacy/W3CIdentity.tex =================================================================== --- projects/articles/browser-privacy/W3CIdentity.tex 2011-04-26 15:03:58 UTC (rev 24674) +++ projects/articles/browser-privacy/W3CIdentity.tex 2011-04-26 15:04:37 UTC (rev 24675) @@ -332,8 +332,8 @@ choice of Firefox Persona\cite{firefox-personas}), or it can be a text area with the user's current favored pseudonym. This idea of identity should then be integrated with the browsing experience. Users should be able to click a -button to get a clean slate for a new identity, and should be able to log in -and out of of password-protected stored encrypted identities, which would +button to get a clean slate for a new identity, and should be able to log into +and out of password-protected stored identities, which would contain the entire state of the browser. This is the direction the Tor Project intends to head in with the Tor Browser Bundle\cite{not-to-toggle}.

1 0

r24674: {projects} Fix some more minor issues (projects/articles/browser-privacy)
by Robert Ransom 26 Apr '11

26 Apr '11

Author: rransom Date: 2011-04-26 15:03:58 +0000 (Tue, 26 Apr 2011) New Revision: 24674 Modified: projects/articles/browser-privacy/W3CIdentity.tex Log: Fix some more minor issues Modified: projects/articles/browser-privacy/W3CIdentity.tex =================================================================== --- projects/articles/browser-privacy/W3CIdentity.tex 2011-04-26 15:03:15 UTC (rev 24673) +++ projects/articles/browser-privacy/W3CIdentity.tex 2011-04-26 15:03:58 UTC (rev 24674) @@ -303,7 +303,7 @@ \subsection{Conveying Identity to the User} Even if the origin model of identifier transmission and other linkable -attributes is altered uniformly to be more in-line with what users expect, it +attributes is altered uniformly to be more in line with what users expect, it is likely that the average user will still experience privacy benefits if the browser conveys the sum of all linkable information as a single, storable, mutable, and clearable user identity.

1 0

r24673: {} Add build script (projects/articles/browser-privacy)
by Robert Ransom 26 Apr '11

26 Apr '11

Author: rransom Date: 2011-04-26 15:03:15 +0000 (Tue, 26 Apr 2011) New Revision: 24673 Added: projects/articles/browser-privacy/build Log: Add build script Added: projects/articles/browser-privacy/build =================================================================== --- projects/articles/browser-privacy/build (rev 0) +++ projects/articles/browser-privacy/build 2011-04-26 15:03:15 UTC (rev 24673) @@ -0,0 +1,5 @@ +#!/bin/sh +pdflatex \\nonstopmode\\input W3CIdentity.tex +bibtex W3CIdentity.aux +pdflatex \\nonstopmode\\input W3CIdentity.tex +pdflatex \\nonstopmode\\input W3CIdentity.tex Property changes on: projects/articles/browser-privacy/build ___________________________________________________________________ Added: svn:executable + *

1 0

r24672: {projects} Fix some minor style issues (projects/articles/browser-privacy)
by Robert Ransom 26 Apr '11

26 Apr '11

Author: rransom Date: 2011-04-26 15:02:34 +0000 (Tue, 26 Apr 2011) New Revision: 24672 Modified: projects/articles/browser-privacy/W3CIdentity.tex Log: Fix some minor style issues Modified: projects/articles/browser-privacy/W3CIdentity.tex =================================================================== --- projects/articles/browser-privacy/W3CIdentity.tex 2011-04-26 11:18:08 UTC (rev 24671) +++ projects/articles/browser-privacy/W3CIdentity.tex 2011-04-26 15:02:34 UTC (rev 24672) @@ -194,11 +194,12 @@ The Panopticlick project by the EFF provides us with exactly this metric\cite{panopticlick}. The researchers conducted a survey of volunteers who were asked to visit an experiment page that harvested many of the above -components. They then computed the Shannon Entropy of the resulting +components. They then computed the Shannon entropy of the resulting distribution of each of several key attributes to determine how many bits of identifying information each attribute provided. -While not perfect\footnotemark, this metric allows us to prioritize effort at +While not perfect\footnotemark, this metric allows us to prioritize our efforts +on the components that have the most potential for linkability. \footnotetext{In particular, the test does not take in all aspects of @@ -246,38 +247,40 @@ on a per-origin basis. An early relevant example of this idea is SafeCache\cite{safecache}. -SafeCache seeks to reduce the ability for 3rd party content elements to use +SafeCache seeks to reduce the ability for third-party content elements to use the cache to store identifiers. It does this by limiting the scope of the -cache to the top-level origin in the url bar. This has the effect that +cache to the top-level origin in the URL bar. This has the effect that commonly sourced content elements are fetched and cached repeatedly, but this is the desired property. Each of these prevalent content elements can be crafted to include unique identifiers for each user, tracking users who attempt to avoid tracking by clearing cookies. -The Mozilla development wiki describes an origin model cookie transmission -improvement written by Dan Witte\cite{thirdparty}. Dan describes a new +The Mozilla development wiki describes an origin model improvement for +cookie transmission +written by Dan Witte\cite{thirdparty}. Dan describes a new dual-keyed origin for cookies, so that cookies would only be transmitted if -they matched both the top level origin and the third party origin involved in +they matched both the top-level origin and the third-party origin involved in their creation. This approach would go a long way towards preventing implicit tracking across multiple websites, and has some interesting properties that make user interaction with content elements more explicitly tied to the current site. +% XXXX I can't tell what this paragraph is supposed to mean. --RR Similarly, one could imagine this two level dual-keyed origin isolation being deployed to improve similar issues with DOM Storage and cryptographic tokens. Making the origin model for browser identifiers more closely match user activity and user expectation has other advantages as well. With a clear -distinction between 3rd party and top-level cookies due to double-keying, the +distinction between third-party and top-level cookies due to double-keying, the privacy settings window could have a user-intuitive way of representing the -user's relationship with different origins, perhaps by using only the favicon +user's relationship with different origins, perhaps by using only the `favicon' of that top level origin to represent all of the browser state accumulated by that origin. The user could delete the entire set of browser state (cookies, cache, storage, cryptographic tokens) associated with a site simply by removing its favicon from their privacy info panel. The problem with origin model improvement approaches is that individually, -they do not fully address the entire linkability problem unless the same +they do not fully address the linkability problem unless the same restriction is applied uniformly to all aspects of stored browser state, and all other linkability issues are dealt with. Behind-the-scenes partnerships can easily allow companies to continue to link users to their identities

1 0

[tor/maint-0.2.2] Don't leak the local hostname in relay nicknames
by nickm＠torproject.org 26 Apr '11

26 Apr '11

commit 4c789ec08c8d52c3aab3ab775a86fe2350d584b5 Author: Sebastian Hahn <sebastian(a)torproject.org> Date: Tue Apr 26 05:07:37 2011 +0200 Don't leak the local hostname in relay nicknames Fixes bug 2979, reported by tagnaq. --- changes/bug2979 | 9 ++++++++ src/or/config.c | 55 ------------------------------------------------------ src/or/dirserv.h | 2 +- 3 files changed, 10 insertions(+), 56 deletions(-) diff --git a/changes/bug2979 b/changes/bug2979 new file mode 100644 index 0000000..fe1f45f --- /dev/null +++ b/changes/bug2979 @@ -0,0 +1,9 @@ + o Minor bugfixes: + - If the Nickname configuration option wasn't given, Tor used to pick + a nickname based on the local hostname as the nickname for a relay. + Because nicknames are not very important in today's Tor and the + "Unnamed" nickname has been implemented, this is now problematic + behaviour: It leaks information about the hostname without being + useful at all. Bugfix on tor-0.1.2.2-alpha, which introduced the + Unnamed nickname. Fixes bug 2979, reported by tagnaq. + diff --git a/src/or/config.c b/src/or/config.c index 3770301..9675c73 100644 --- a/src/or/config.c +++ b/src/or/config.c @@ -2500,54 +2500,6 @@ is_local_addr(const tor_addr_t *addr) return 0; } -/** Called when we don't have a nickname set. Try to guess a good nickname - * based on the hostname, and return it in a newly allocated string. If we - * can't, return NULL and let the caller warn if it wants to. */ -static char * -get_default_nickname(void) -{ - static const char * const bad_default_nicknames[] = { - "localhost", - NULL, - }; - char localhostname[256]; - char *cp, *out, *outp; - int i; - - if (gethostname(localhostname, sizeof(localhostname)) < 0) - return NULL; - - /* Put it in lowercase; stop at the first dot. */ - if ((cp = strchr(localhostname, '.'))) - *cp = '\0'; - tor_strlower(localhostname); - - /* Strip invalid characters. */ - cp = localhostname; - out = outp = tor_malloc(strlen(localhostname) + 1); - while (*cp) { - if (strchr(LEGAL_NICKNAME_CHARACTERS, *cp)) - *outp++ = *cp++; - else - cp++; - } - *outp = '\0'; - - /* Enforce length. */ - if (strlen(out) > MAX_NICKNAME_LEN) - out[MAX_NICKNAME_LEN]='\0'; - - /* Check for dumb names. */ - for (i = 0; bad_default_nicknames[i]; ++i) { - if (!strcmp(out, bad_default_nicknames[i])) { - tor_free(out); - return NULL; - } - } - - return out; -} - /** Release storage held by <b>options</b>. */ static void config_free(config_format_t *fmt, void *options) @@ -2976,14 +2928,7 @@ options_validate(or_options_t *old_options, or_options_t *options, if (options->Nickname == NULL) { if (server_mode(options)) { - if (!(options->Nickname = get_default_nickname())) { - log_notice(LD_CONFIG, "Couldn't pick a nickname based on " - "our hostname; using %s instead.", UNNAMED_ROUTER_NICKNAME); options->Nickname = tor_strdup(UNNAMED_ROUTER_NICKNAME); - } else { - log_notice(LD_CONFIG, "Choosing default nickname '%s'", - options->Nickname); - } } } else { if (!is_legal_nickname(options->Nickname)) { diff --git a/src/or/dirserv.h b/src/or/dirserv.h index 569abfc..a8a7060 100644 --- a/src/or/dirserv.h +++ b/src/or/dirserv.h @@ -52,7 +52,7 @@ MAX_V_LINE_LEN \ ) -#define UNNAMED_ROUTER_NICKNAME "Unnamed" +#define UNNAMED_ROUTER_NICKNAME "Unnamed" int connection_dirserv_flushed_some(dir_connection_t *conn);

1 0

[metrics-web/master] Add log messages to database refresh function.
by karsten＠torproject.org 26 Apr '11

26 Apr '11

commit e28c324c5e73808703970b060c7511b24f5981a2 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Tue Apr 26 15:03:57 2011 +0200 Add log messages to database refresh function. --- db/tordir.sql | 15 +++++++++++++++ 1 files changed, 15 insertions(+), 0 deletions(-) diff --git a/db/tordir.sql b/db/tordir.sql index 8b9b8ca..f01a662 100644 --- a/db/tordir.sql +++ b/db/tordir.sql @@ -848,19 +848,34 @@ CREATE TABLE gettor_stats ( -- Refresh all statistics in the database. CREATE OR REPLACE FUNCTION refresh_all() RETURNS INTEGER AS $$ BEGIN + RAISE NOTICE '% Starting refresh run.', timeofday(); + RAISE NOTICE '% Deleting old dates from updates.', timeofday(); DELETE FROM updates; + RAISE NOTICE '% Copying scheduled dates.', timeofday(); INSERT INTO updates SELECT * FROM scheduled_updates; + RAISE NOTICE '% Refreshing relay statuses per day.', timeofday(); PERFORM refresh_relay_statuses_per_day(); + RAISE NOTICE '% Refreshing network size.', timeofday(); PERFORM refresh_network_size(); + RAISE NOTICE '% Refreshing hourly network size.', timeofday(); PERFORM refresh_network_size_hour(); + RAISE NOTICE '% Refreshing relays by country.', timeofday(); PERFORM refresh_relay_countries(); + RAISE NOTICE '% Refreshing relay platforms.', timeofday(); PERFORM refresh_relay_platforms(); + RAISE NOTICE '% Refreshing relay versions.', timeofday(); PERFORM refresh_relay_versions(); + RAISE NOTICE '% Refreshing total relay bandwidth.', timeofday(); PERFORM refresh_total_bandwidth(); + RAISE NOTICE '% Refreshing relay bandwidth history.', timeofday(); PERFORM refresh_total_bwhist(); + RAISE NOTICE '% Refreshing bandwidth history by flags.', timeofday(); PERFORM refresh_bwhist_flags(); + RAISE NOTICE '% Refreshing user statistics.', timeofday(); PERFORM refresh_user_stats(); + RAISE NOTICE '% Deleting processed dates.', timeofday(); DELETE FROM scheduled_updates WHERE id IN (SELECT id FROM updates); + RAISE NOTICE '% Terminating refresh run.', timeofday(); RETURN 1; END; $$ LANGUAGE plpgsql;

1 0

[metrics-web/master] Minor fix to new bandwidth graph.
by karsten＠torproject.org 26 Apr '11

26 Apr '11

commit 62f3296f7519b0c275cb92fee33d3bd9c75037ef Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Tue Apr 26 14:58:27 2011 +0200 Minor fix to new bandwidth graph. --- db/tordir.sql | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/db/tordir.sql b/db/tordir.sql index cfe5907..8b9b8ca 100644 --- a/db/tordir.sql +++ b/db/tordir.sql @@ -604,7 +604,7 @@ $$ LANGUAGE plpgsql; CREATE OR REPLACE FUNCTION refresh_bwhist_flags() RETURNS INTEGER AS $$ BEGIN DELETE FROM bwhist_flags WHERE date IN (SELECT date FROM updates); - INSERT INTO bwhist_flags (date, isexit, isguard, read_write_avg) + INSERT INTO bwhist_flags (date, isexit, isguard, read, written) SELECT a.date, isexit, isguard, SUM(read_sum) as read, SUM(written_sum) AS written FROM

1 0