April 2011 - tor-commits - lists.torproject.org

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

[metrics-web/master] Add graph on bandwidth by Exit and/or Guard flags.
by karsten＠torproject.org 26 Apr '11

26 Apr '11

commit 0189c896586e67e994cb0774b51515e115f8e8f2 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Tue Apr 26 14:14:09 2011 +0200 Add graph on bandwidth by Exit and/or Guard flags. --- db/tordir.sql | 36 ++++++++++++++++ etc/web.xml | 4 ++ rserve/csv.R | 14 ++++++ rserve/graphs.R | 44 ++++++++++++++++++++ src/org/torproject/ernie/web/CsvServlet.java | 1 + .../ernie/web/GraphParameterChecker.java | 1 + web/WEB-INF/network.jsp | 31 ++++++++++++++ 7 files changed, 131 insertions(+), 0 deletions(-) diff --git a/db/tordir.sql b/db/tordir.sql index 8efba09..cfe5907 100644 --- a/db/tordir.sql +++ b/db/tordir.sql @@ -196,6 +196,16 @@ CREATE TABLE total_bwhist ( CONSTRAINT total_bwhist_pkey PRIMARY KEY(date) ); +-- TABLE bwhist_flags +CREATE TABLE bwhist_flags ( + date DATE NOT NULL, + isexit BOOLEAN NOT NULL, + isguard BOOLEAN NOT NULL, + read BIGINT, + written BIGINT, + CONSTRAINT bwhist_flags_pkey PRIMARY KEY(date, isexit, isguard) +); + -- TABLE user_stats -- Aggregate statistics on directory requests and byte histories that we -- use to estimate user numbers. @@ -591,6 +601,31 @@ CREATE OR REPLACE FUNCTION refresh_total_bwhist() RETURNS INTEGER AS $$ END; $$ 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) + SELECT a.date, isexit, isguard, SUM(read_sum) as read, + SUM(written_sum) AS written + FROM + (SELECT DATE(validafter) AS date, + fingerprint, + BOOL_OR(isexit) AS isexit, + BOOL_OR(isguard) AS isguard + FROM statusentry + WHERE isrunning = TRUE + AND DATE(validafter) >= (SELECT MIN(date) FROM updates) + AND DATE(validafter) <= (SELECT MAX(date) FROM updates) + AND DATE(validafter) IN (SELECT date FROM updates) + GROUP BY 1, 2) a + JOIN bwhist + ON a.date = bwhist.date + AND a.fingerprint = bwhist.fingerprint + GROUP BY 1, 2, 3; + RETURN 1; + END; +$$ LANGUAGE plpgsql; + -- FUNCTION refresh_user_stats() -- This function refreshes our user statistics by weighting reported -- directory request statistics of directory mirrors with bandwidth @@ -823,6 +858,7 @@ CREATE OR REPLACE FUNCTION refresh_all() RETURNS INTEGER AS $$ PERFORM refresh_relay_versions(); PERFORM refresh_total_bandwidth(); PERFORM refresh_total_bwhist(); + PERFORM refresh_bwhist_flags(); PERFORM refresh_user_stats(); DELETE FROM scheduled_updates WHERE id IN (SELECT id FROM updates); RETURN 1; diff --git a/etc/web.xml b/etc/web.xml index a9b36bc..688e6f3 100644 --- a/etc/web.xml +++ b/etc/web.xml @@ -197,6 +197,10 @@ </servlet-mapping> <servlet-mapping> <servlet-name>GraphImage</servlet-name> + <url-pattern>/bwhist-flags.png</url-pattern> + </servlet-mapping> + <servlet-mapping> + <servlet-name>GraphImage</servlet-name> <url-pattern>/dirbytes.png</url-pattern> </servlet-mapping> <servlet-mapping> diff --git a/rserve/csv.R b/rserve/csv.R index 37a0856..17a59c2 100644 --- a/rserve/csv.R +++ b/rserve/csv.R @@ -90,6 +90,20 @@ export_bandwidth <- function(path) { write.csv(bandwidth, path, quote = FALSE, row.names = FALSE) } +export_bwhist_flags <- function(path) { + drv <- dbDriver("PostgreSQL") + con <- dbConnect(drv, user = dbuser, password = dbpassword, dbname = db) + q <- paste("SELECT date, isexit, isguard, read, written", + "FROM bwhist_flags", + "WHERE date < (SELECT MAX(date) FROM bwhist_flags) - 1", + "ORDER BY date, isexit, isguard") + rs <- dbSendQuery(con, q) + bw <- fetch(rs, n = -1) + dbDisconnect(con) + dbUnloadDriver(drv) + write.csv(bw, path, quote = FALSE, row.names = FALSE) +} + export_dirbytes <- function(path) { drv <- dbDriver("PostgreSQL") con <- dbConnect(drv, user = dbuser, password = dbpassword, dbname = db) diff --git a/rserve/graphs.R b/rserve/graphs.R index 15daf02..f268a34 100644 --- a/rserve/graphs.R +++ b/rserve/graphs.R @@ -443,6 +443,50 @@ plot_bandwidth <- function(start, end, path, dpi) { ggsave(filename = path, width = 8, height = 5, dpi = as.numeric(dpi)) } +plot_bwhist_flags <- function(start, end, path, dpi) { + drv <- dbDriver("PostgreSQL") + con <- dbConnect(drv, user = dbuser, password = dbpassword, dbname = db) + q <- paste("SELECT date, isexit, isguard, read, written ", + "FROM bwhist_flags WHERE date >= '", start, "' AND date <= '", end, + "' AND date < (SELECT MAX(date) FROM bwhist_flags) - 1 ", sep = "") + rs <- dbSendQuery(con, q) + bw <- fetch(rs, n = -1) + dbDisconnect(con) + dbUnloadDriver(drv) + dates <- seq(from = as.Date(start, "%Y-%m-%d"), + to = as.Date(end, "%Y-%m-%d"), by = "1 day") + missing <- setdiff(dates, as.Date(bw$date, origin = "1970-01-01")) + if (length(missing) > 0) + bw <- rbind(bw, + data.frame(date = as.Date(missing, origin = "1970-01-01"), + isexit = FALSE, isguard = FALSE, read = NA, written = NA), + data.frame(date = as.Date(missing, origin = "1970-01-01"), + isexit = FALSE, isguard = TRUE, read = NA, written = NA), + data.frame(date = as.Date(missing, origin = "1970-01-01"), + isexit = TRUE, isguard = FALSE, read = NA, written = NA), + data.frame(date = as.Date(missing, origin = "1970-01-01"), + isexit = TRUE, isguard = TRUE, read = NA, written = NA)) + bw <- data.frame(date = bw$date, variable = ifelse(bw$isexit, + ifelse(bw$isguard, "Guard & Exit", "Exit only"), + ifelse(bw$isguard, "Guard only", "Middle only")), + value = (bw$read + bw$written) / 2) + ggplot(bw, aes(x = as.Date(date, "%Y-%m-%d"), y = value / 2^20 / 86400, + colour = variable)) + + geom_line(size = 1) + + scale_x_date(name = paste("\nThe Tor Project - ", + "https://metrics.torproject.org/", sep = ""), format = + c("%d-%b", "%d-%b", "%b-%Y", "%b-%Y", "%Y", "%Y")[ + cut(as.numeric(max(as.Date(bw$date, "%Y-%m-%d")) - + min(as.Date(bw$date, "%Y-%m-%d"))), + c(0, 10, 56, 365, 730, 5000, Inf), labels=FALSE)]) + + scale_y_continuous(name="Bandwidth (MiB/s)", + limits = c(0, max(bw$value, na.rm = TRUE) / 2^20 / 86400)) + + scale_colour_hue(name = "") + + opts(title = "Bandwidth history by relay flags", + legend.position = "top") + ggsave(filename = path, width = 8, height = 5, dpi = as.numeric(dpi)) +} + plot_dirbytes <- function(start, end, path, dpi) { drv <- dbDriver("PostgreSQL") con <- dbConnect(drv, user = dbuser, password = dbpassword, dbname = db) diff --git a/src/org/torproject/ernie/web/CsvServlet.java b/src/org/torproject/ernie/web/CsvServlet.java index 0997f31..0140fa9 100644 --- a/src/org/torproject/ernie/web/CsvServlet.java +++ b/src/org/torproject/ernie/web/CsvServlet.java @@ -31,6 +31,7 @@ public class CsvServlet extends HttpServlet { this.availableCsvFiles = new HashSet<String>(); this.availableCsvFiles.add("bandwidth"); this.availableCsvFiles.add("bridge-users"); + this.availableCsvFiles.add("bwhist-flags"); this.availableCsvFiles.add("connbidirect"); this.availableCsvFiles.add("current-platform-strings"); this.availableCsvFiles.add("direct-users"); diff --git a/src/org/torproject/ernie/web/GraphParameterChecker.java b/src/org/torproject/ernie/web/GraphParameterChecker.java index 308afe5..95e4cf0 100644 --- a/src/org/torproject/ernie/web/GraphParameterChecker.java +++ b/src/org/torproject/ernie/web/GraphParameterChecker.java @@ -47,6 +47,7 @@ public class GraphParameterChecker { this.availableGraphs.put("versions", "start,end,filename,dpi"); this.availableGraphs.put("platforms", "start,end,filename,dpi"); this.availableGraphs.put("bandwidth", "start,end,filename,dpi"); + this.availableGraphs.put("bwhist-flags", "start,end,filename,dpi"); this.availableGraphs.put("dirbytes", "start,end,filename,dpi"); this.availableGraphs.put("direct-users", "start,end,country,filename,dpi"); diff --git a/web/WEB-INF/network.jsp b/web/WEB-INF/network.jsp index a1a5efe..7906789 100644 --- a/web/WEB-INF/network.jsp +++ b/web/WEB-INF/network.jsp @@ -227,6 +227,37 @@ in the network.</p> <p><a href="csv/bandwidth.csv">CSV</a> file containing all data.</p> <br> +<h3>Relay bandwidth by Exit and/or Guard flags</h3> +<br> +<p>The following graph shows the relay bandwidth of all relays with the +Exit and/or Guard flags assigned by the directory authorities.</p> +<a name="bwhist-flags"></a> +<img src="bwhist-flags.png${bwhist_flags_url}" + width="576" height="360" alt="Relay bandwidth by flags graph"> +<form action="network.html#bwhist-flags"> + <div class="formrow"> + <input type="hidden" name="graph" value="bwhist-flags"> + <p> + <label>Start date (yyyy-mm-dd):</label> + <input type="text" name="start" size="10" + value="<c:choose><c:when test="${fn:length(bwhist_flags_start) == 0}">${default_start_date}</c:when><c:otherwise>${bwhist_flags_start[0]}</c:otherwise></c:choose>"> + <label>End date (yyyy-mm-dd):</label> + <input type="text" name="end" size="10" + value="<c:choose><c:when test="${fn:length(bwhist_flags_end) == 0}">${default_end_date}</c:when><c:otherwise>${bwhist_flags_end[0]}</c:otherwise></c:choose>"> + </p><p> + Resolution: <select name="dpi"> + <option value="72"<c:if test="${bwhist_flags_dpi[0] eq '72'}"> selected</c:if>>Screen - 576x360</option> + <option value="150"<c:if test="${bwhist_flags_dpi[0] eq '150'}"> selected</c:if>>Print low - 1200x750</option> + <option value="300"<c:if test="${bwhist_flags_dpi[0] eq '300'}"> selected</c:if>>Print high - 2400x1500</option> + </select> + </p><p> + <input class="submit" type="submit" value="Update graph"> + </p> + </div> +</form> +<p><a href="csv/bwhist-flags.csv">CSV</a> file containing all data.</p> +<br> + <h3>Number of bytes spent on answering directory requests</h3> <br> <p>Relays running on 0.2.2.15-alpha or higher report the number of bytes

1 0

r24671: {projects} Ah, Torbutton. It's almost as if you never existed. (projects/articles/browser-privacy)
by Mike Perry 26 Apr '11

26 Apr '11

Author: mikeperry Date: 2011-04-26 11:18:08 +0000 (Tue, 26 Apr 2011) New Revision: 24671 Modified: projects/articles/browser-privacy/W3CIdentity.tex Log: Ah, Torbutton. It's almost as if you never existed. Modified: projects/articles/browser-privacy/W3CIdentity.tex =================================================================== --- projects/articles/browser-privacy/W3CIdentity.tex 2011-04-26 09:35:52 UTC (rev 24670) +++ projects/articles/browser-privacy/W3CIdentity.tex 2011-04-26 11:18:08 UTC (rev 24671) @@ -263,8 +263,8 @@ make user interaction with content elements more explicitly tied to the current site. -Similarly, one could imagine this two-level origin isolation being deployed to -improve similar issues with DOM Storage and cryptographic tokens. +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 @@ -309,45 +309,14 @@ improvements, as it does not require extensive compatibility testing or standards coordination. -% XXX: Do we need to even mention torbutton? -One of the earliest examples of an identity-based approach is our own work on -Torbutton\cite{torbutton}, Torbutton deserves poor marks for both simplicity -and usability\cite{not-to-toggle}. Torbutton attempts to isolate the user's -non-Tor activity from their Tor activity, effectively providing the user with -a blank slate for their Tor activity, but optionally allowing them to toggle -between these two identities. +Of the major private browsing modes, Google Chrome's Incognito Mode comes the +closest to conveying the idea of ``identity'' to the user, and the +implementation is also simple as a result. The Incognito Mode window is a +separate, stylized window that clearly conveys an alternate identity is in use +for this window, which can be used concurrent to the non-private identity. +The better UI appears to lead to less mode error (where the user forgets their +private browsing state) compared to other browsers\cite{private-browsing}. -Firefox Private Browsing Mode is very similar, in that it allows users to -switch between their normal browsing and a ``private'' clean slate. - -% FIXME: This paragraph can go if we need space: -Both Firefox PBM and Torbutton suffer from usability issues, primarily because -this concept of separate browsing identities is not properly conveyed to the -user. In Firefox's case, this usability issue is apparent through the quantity -of mode error observed in the review of Private Browsing Modes by Dan Boneh et -al\cite{private-browsing}. In Torbutton's case, the issues appear more severe. -We've informally observed that users have tremendous difficulties remembering -which tabs were Tor-related and which were non-Tor related, and we've also -observed issues with mode error. - -Both of these approaches are exceedingly complex: they deal with every aspect -of browser state individually. This development effort however does enable -Firefox and Torbutton to provide the user with great fine-grained control. - -Google Chrome's Incognito Mode comes the closest to conveying this idea of -``Incognito identity'' to the user, and the implementation is also simpler as a -result. The Incognito Mode window is a separate, stylized window that clearly -conveys an alternate identity is in use for this window, which can be used -concurrent to the non-private identity. This appears to lead to less mode -error (where the user forgets their private browsing state) compared to other -browsers. - -% FIXME: This paragraph can go if we need space: -The implementation of Incognito is as a virtualized in-memory profile, which -allows them to achieve protection against history storage issues for very low -effort. It also allows them to tweak browser properties and permissions -specifically for this profile. - The Mozilla Weave project appears to be proposing an identity-oriented method of managing, syncing, and storing authentication tokens, and also has use cases described for multiple users of a single browser\cite{weave-manager}. It

1 0

r24670: {projects} Rework draft based on Nick's suggestions: improve abstract, (projects/articles/browser-privacy)
by Mike Perry 26 Apr '11

26 Apr '11

Author: mikeperry Date: 2011-04-26 09:35:52 +0000 (Tue, 26 Apr 2011) New Revision: 24670 Modified: projects/articles/browser-privacy/W3CIdentity.bib projects/articles/browser-privacy/W3CIdentity.tex Log: Rework draft based on Nick's suggestions: improve abstract, tone down use of identity, introduce ideas better. Problem is, we've now bled into 6 pages. We need to trim some fat. Modified: projects/articles/browser-privacy/W3CIdentity.bib =================================================================== --- projects/articles/browser-privacy/W3CIdentity.bib 2011-04-26 01:37:07 UTC (rev 24669) +++ projects/articles/browser-privacy/W3CIdentity.bib 2011-04-26 09:35:52 UTC (rev 24670) @@ -95,3 +95,13 @@ author= {Mozilla}, note = {\url{https://mozillalabs.com/personas/}} } + +@Misc{rfc2965, + author = {D. Kristol and L. Montulli}, + title = {HTTP State Management Mechanism}, + howpublished = {IETF RFC 2965}, + month = {October}, + year = {2000}, + note = {\url{http://www.rfc-editor.org/rfc/rfc2965.txt}}, +} + Modified: projects/articles/browser-privacy/W3CIdentity.tex =================================================================== --- projects/articles/browser-privacy/W3CIdentity.tex 2011-04-26 01:37:07 UTC (rev 24669) +++ projects/articles/browser-privacy/W3CIdentity.tex 2011-04-26 09:35:52 UTC (rev 24670) @@ -17,7 +17,7 @@ \begin{document} -\title{Bridging the Disconnect Between Web Identity and User Perception} +\title{Bridging the Disconnect Between Web Privacy and User Perception} \author{Mike Perry \\ The Internet \\ mikeperry(a)torproject.org} @@ -32,10 +32,13 @@ and the reality of their relationship with the websites they visit. This position paper explores this disconnect and provides some recommendations for making the technical reality of the web match user perception, through both -technical improvements as well as user interface cues. By looking at all of -the elements of tracking as though they collectively comprise "User Identity", -we can make better decisions about improvements to both the technical and the -interface aspects of authentication and privacy. +technical improvements as well as user interface cues. We frame the core +technical problem as one of ``linkability'' -- the level of correlation +between various online activities that the user naturally expects to be +independent. We look to address the issue of unexpected linkability through +both improvements to the web's origin model, as well as through user interface +cues about the set of accumulated identifiers that can be said to comprise +a user's online identity. \end{abstract} @@ -44,8 +47,8 @@ The prevailing revenue model of the web is an appealing one. Web users receive unfettered, frictionless access to an extensive variety of information sources in exchange for viewing advertising. This advertising is more valuable if each -advertisement is more relevant to the current activity, and if possible, more -relevant to the current user. +advertisement is relevant to the current activity, and if possible, relevant +to the current user. The cost of this is that user privacy on the web is a nightmare. There is ubiquitous tracking, unseen partnership agreements and data exchange, and @@ -56,7 +59,7 @@ The problem is that the revenue model of the web has incentivized companies to find ways to continue to track users against their will, even if those users are attempting to protect themselves through currently available methods. -Starting with the infamous "Flash cookies", we have progressed through a +Starting with the infamous ``Flash cookies'', we have progressed through a seemingly endless arms race of secondary identifiers and tracking information: visited history, cache, font and system data, desktop resolution, keystroke timing, and so on and so forth\cite{wsj-fingerprinting}. @@ -71,46 +74,61 @@ To understand and evaluate potential solutions and improvements to this status quo, we must explore the disconnect between user experience and the way the -web actually functions with respect to tracking and identity. +web actually functions with respect to user tracking. -% FIXME: Do we need this paragraph? -%To this end, the rest of this document is structured as follows: First, we -%examine user identity on the web, comparing the average user's perspective to -%what actually is happening technically behind the scenes, and noting the major -%disconnects. We then examine solutions attempting to bridge this disconnect -%from two different directions. +% +% 20:16 < nickm> Not "identity-based", though. identity-separation, +% identity-isolation. "nym" and "pseudonym" are also fine words +% 20:18 < armadev> i'm still not entirely clear on what you mean by the +% identity model. i am guessing it's "the user thinks of his web +% experience in terms of whether the website can recognize +% him", but i think that's not it. i want clearer +% definitions up front, and then i can help with terms. :) -We only consider implementations that involve privacy-by-design. -Privacy-by-policy approaches such as Do Not Track will not be discussed. -\section{User Identity on the Web} +To this end, the rest of this document is structured as follows: First, we +examine how the user perceives their privacy on the web, comparing the average +user's perspective to what actually is happening technically behind the +scenes, and noting the major disconnects. We then examine solutions attempting +to bridge this disconnect from two different directions, corresponding to the +two major sources of disconnect\footnotemark. The first direction is improving +the linkability issues inherent with the multi-origin model of the web itself. +The second direction is improving user cues and browser interface to suggest a +coherent concept of identity to the user, which more accurately reflects the +set of unique identifiers they have accumulated. Both of these directions can +be pursued independently. -To properly examine this privacy problem, we must probe into the details of -both what a User's perception of their identity is, as well as the technical -realities of what goes into web authentication and tracking. +\footnotetext{We only consider implementations that involve privacy-by-design. +Privacy-by-policy approaches such as Do Not Track will not be discussed.} -\subsection{User Perception of Identity} +\section{User Privacy on the Web} -Instinctively, users define their privacy in terms of their identity, in terms +To properly examine the privacy problem, we must probe both the average user's +perception of what their ``web identity'' is, as well as the technical +realities of web authentication and tracking. + +\subsection{User Perception of Privacy} + +Instinctively, users define their privacy in terms of their identity: in terms of how they have interacted with a site in order to inform it of who they are. Typically, the user's perception of their identity on the web is usually a direct -function of the mechanisms used for strong authentication for particular sites. +function of the identifiers used for strong authentication for particular sites. For example, users expect that logging in to Facebook creates a relationship in their browsers when facebook.com is present in the URL bar, but they are -likely not aware that this also extends to their activity on other, arbitrary -sites that happen to include "Like this on Facebook" buttons or +typically not aware that this also extends to their activity on other, arbitrary +sites that happen to include ``Like this on Facebook'' buttons or Facebook-sourced advertising content. -Many, if not most, users expect that when they log out of a site their -relationship ends and that any associated tracking should be over. Even -users who are aware of cookies can be prone to believing that clearing the -cookies and private browsing data related to a particular site is sufficient -to end their relationship with that site. +Many, if not most, users expect that when they log out of a site, their +relationship ends and that any associated tracking should be over. Even users +who are aware of cookies can be prone to believing that clearing the cookies +related to a particular site is sufficient to end their relationship with that +site. Neither of these beliefs has any relation to reality. -\subsection{Technical Reality of Identity} +\subsection{The Technical Reality of Privacy} The technical reality of the web today is that users are usually wrong about their authentication status with respect to a particular site, and are almost @@ -118,31 +136,44 @@ pages. The default experience is such that all of this data exchange is concealed from the user. -So then what is identity? In terms of authentication, it would at first appear -to be cookies, HTTP Auth tokens, and client TLS certificates. However, even this -begins to break down. High-security websites are already using fingerprinting -as an auxiliary second factor of authentication\cite{security-fingerprinting}, -and online data aggregators utilize everything they can to build complete -portraits of users' identities\cite{tracking-identity}. +So then what comprises the user's web identity for tracking purposes? In terms +of authentication, it would at first appear to be limited to cookies, HTTP +Auth tokens, and client TLS certificates. However, this identifier-based +approach breaks down quickly on the modern web. High-security websites are +already using fingerprinting as an auxiliary second factor of +authentication\cite{security-fingerprinting}, and online data aggregators +utilize everything they can to build complete portraits of users' +identities\cite{tracking-identity}. -Identity then is a superset of all the authentication tokens used by the +Despite what the user may believe, their actual web identity then is a +superset of all the stored identifiers and authentication tokens used by the browser. It is the ability to link a user's activity in one instance to their activity in another instance, be it across time, or even on the very same page due to multiple content origins. -\subsection{Identity as Linkability} +Therefore, instead of viewing the user's identity as the sum of their +identifiers, or as their relationship to individual websites, it is best to +view it as the ability to link activity from one website to activity in +another website. We will call this property ``user linkability''. -When expanded to cover all items that enable or substantially contribute to -Linkability, a lot more components of the browser are now in scope. We will -briefly enumerate these components. +\subsection{User Privacy as Linkability} +In terms of what the user actually expects, user privacy is more accurately +modeled as the level of linkability between subsequent actions on the web, as +opposed to the mere sum of their unique identifiers and authentication tokens. + +When privacy is expanded to cover all items that enable or substantially +contribute to linkability, a lot more components of the browser are now in +scope. We will briefly enumerate these components. + First, the obvious properties are found in the state of the browser: cookies, DOM storage, cache, cryptographic tokens and cryptographic state, and -location. These are what technical people tend to think of first when it comes -to private browsing and identity, but they are not the whole story. +location. These identifiers are what technical people tend to think of first +when it comes to user identity and private browsing, but they are not the +whole story. Next, we have long-term properties of the browser itself. These include the -User Agent String, the list of installed plugins, rendering capabilities, +User Agent string, the list of installed plugins, rendering capabilities, window decoration size, and browser widget size. Then, we have properties of the computer. These include desktop size, IP @@ -156,7 +187,7 @@ \subsection{Developing a Threat Model} Unfortunately, just about every browser property and functionality is a -potential fingerprinting target. In order to properly address the network +potential linkability target. In order to properly address the network adversary on a technical level, we need a metric to measure linkability of the various browser properties that extend beyond any stored origin-related state. @@ -172,102 +203,114 @@ \footnotetext{In particular, the test does not take in all aspects of resolution information. It did not calculate the size of widgets, window -decoration, or toolbar size. We believe this may add high amounts of entropy -to the screen field. It also did not measure clock offset and other time-based -fingerprints. Furthermore, as new browser features are added, this experiment -should be repeated to include them.} +decoration, or toolbar size. We believe these resolution-related properties +may add high amounts of entropy to the resolution component. They also did not +measure clock offset and other time-based fingerprints. Furthermore, as new +browser features are added, the experiment should be repeated to include +them.} This metric also indicates that it is beneficial to standardize on implementations of fingerprinting resistance where possible. More implementations using the same defenses means more users with similar -fingerprints, which means less entropy in the metric. +fingerprints, which means less entropy in the metric. Similarly, uniform +feature deployment leads to less entropy in the metric. \section{Matching User Perception with Reality} -When the concept of user identity is expanded to cover all aspects of -linkability, addressing the problem of the disconnect between user perception -and reality becomes clearer. For users to have privacy, and for private -browsing modes to function, the relationship between a user and a site must be -understood by that user. +For users to have privacy, and for private browsing modes to function, the +relationship between a user and a site must be understood by that user. It is apparent that the user experiences disconnect with the technical realities of the web on two major fronts: the average user does not grasp the privacy implications of the multi-origin model, nor are they given a clear -concept of identity to grasp the privacy implications of the union of the -trackable components of their browsers. +concept of browser identity to grasp the privacy implications of the union +of the linkable components of their browsers. We will now examine examples of attempts at reducing this disconnect on each -of these two fronts. +of these two fronts. Note that these to fronts are orthogonal. Approaches from +them may be combined, or used independently. -Note that identity-based approaches and the origin-based approaches are -orthogonal. They may be combined, or used independently. +\subsection{Improving the Origin Model} -\subsection{Origin-Based Approaches} +The current identifier origin model used by the web is fundamentally flawed +when viewed from the perspective of meeting the expectations of the user. +Unique, globally linkable identifiers can be transmitted for arbitrary content +elements on any page, which can be sourced from anywhere without user +interaction or awareness. -Origin-based approaches seek to improve the technical behavior of the browser -to make linkability less implicit and more consent-driven. In short, these -approaches seek to make the web behave more like users currently assume it -behaves by anchoring browser state to top-level origins as opposed to -associating it with arbitrary content elements. +However, the behavior of identifiers and linkable attributes can be improved +to make linkability less implicit and more consent-driven without the need for +cumbersome interventionist user interface. Where explicit identifiers exist, +they should be tied to the pair of the top-level origin and the third-party +content origin. Where linkability attributes exist, they should be obfuscated +on a per-origin basis. -The earliest relevant example of this work is SafeCache\cite{safecache}. +An early relevant example of this idea is SafeCache\cite{safecache}. SafeCache seeks to reduce the ability for 3rd party content elements to use the cache to store identifiers. It does this by limiting the scope of the -cache to the 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. +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. -Mozilla has a wonderful example of an origin-based improvement written by Dan -Witte and buried on their wiki\cite{thirdparty}. It 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 their -creation. This approach would go a long way towards preventing implicit -tracking across multiple websites. +The Mozilla development wiki describes an origin model cookie transmission +improvement 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 +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. Similarly, one could imagine this two-level origin isolation being deployed to improve similar issues with DOM Storage and cryptographic tokens. -Making the origin model for browser identifiers more closely match the user +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, 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 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. +distinction between 3rd 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 +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-based approaches is that individually, they do not -fully address the entire 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 through any -aspect of browser state that is not properly compartmentalized to the top -level origin and bound to the same rules. +The problem with origin model improvement approaches is that individually, +they do not fully address the entire 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 +through any linkable aspect of browser state that is not properly +compartmentalized to the top level origin and bound to the same rules as all +other linkable state. -However, linkability based on browser properties is very amenable to this -model. In particular, one can imagine per-origin plugin permissions, -per-origin limits on the number of fonts that can be used, and randomized -window-specific time offsets. +However, linkability based on fingerprintable browser properties is also +amenable to improvement under this model. In particular, one can imagine +per-origin plugin loading permissions, per-origin limits on the number of +fonts that can be used, and randomized window-specific time offsets. So, while these approaches are in fact useful for bringing the technical realities of the web closer to what the user assumes is happening, they must be deployed uniformly, with a consistent top-level origin restriction model. -This may take significant coordination and standardization efforts. +This may take significant coordination and standardization efforts. Without +this, it is necessary to fill the remaining linkability gaps by presenting +the user with a visual representation of their overall web identity. -\subsection{Identity-Based Approaches} +\subsection{Conveying Identity to the User} -We will now discuss what we call the identity-based approaches to privacy. -These approaches, whether explicitly or implicitly, all model the user's web -identity as the entirety of the user's state for all origins. +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 +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. -The key advantage of identity-based approaches is that they can be simpler -than origin-based approaches when used to improve the privacy problem on their -own. +Providing this concept of identity to the user is also simpler than origin +improvements, as it does not require extensive compatibility testing or +standards coordination. -While the earliest example of an identity-based approach is our own work on +% XXX: Do we need to even mention torbutton? +One of the earliest examples of an identity-based approach is our own work on Torbutton\cite{torbutton}, Torbutton deserves poor marks for both simplicity and usability\cite{not-to-toggle}. Torbutton attempts to isolate the user's non-Tor activity from their Tor activity, effectively providing the user with @@ -275,7 +318,7 @@ between these two identities. Firefox Private Browsing Mode is very similar, in that it allows users to -switch between their normal browsing and a "private" clean slate. +switch between their normal browsing and a ``private'' clean slate. % FIXME: This paragraph can go if we need space: Both Firefox PBM and Torbutton suffer from usability issues, primarily because @@ -292,7 +335,7 @@ Firefox and Torbutton to provide the user with great fine-grained control. Google Chrome's Incognito Mode comes the closest to conveying this idea of -"Incognito identity" to the user, and the implementation is also simpler as a +``Incognito identity'' to the user, and the implementation is also simpler as a result. The Incognito Mode window is a separate, stylized window that clearly conveys an alternate identity is in use for this window, which can be used concurrent to the non-private identity. This appears to lead to less mode @@ -305,10 +348,10 @@ effort. It also allows them to tweak browser properties and permissions specifically for this profile. -The Mozilla Weave project appears to be proposing an identity-based method of -managing, syncing, and storing authentication tokens, and also has use cases -described for multiple users of a single browser\cite{weave-manager}. It is -the closest idea on paper to what we envision as the way to bridge user +The Mozilla Weave project appears to be proposing an identity-oriented method +of managing, syncing, and storing authentication tokens, and also has use +cases described for multiple users of a single browser\cite{weave-manager}. It +is the closest idea on paper to what we envision as the way to bridge user assumptions with reality. We believe that the user interface of the browser should convey a sense of @@ -342,28 +385,36 @@ This is especially true of cellular IP networks.} Linkability solutions within the identity framework would be similar to the -origin-based solutions, except they would be properties of the entire browser +origin model solutions, except they would be properties of the entire browser or browser profile, and would be obfuscated only once per identity switch. -% FIXME: Elaborate? - \section{Conclusions} -There is a demand for private browsing, and we believe that solid private -browsing modes can be created. In order to do this, we need solid analysis of -the threat models involved, and we need standardization for many aspects of -defense. +The appeal of the prevailing revenue model of the web and the difficulties +associated with altering browser behavior have lulled us into accepting user +deception as the norm for web use. The average user completely lacks the +understanding needed to grasp how web tracking is carried out. This disconnect +in understanding is extreme to the point where moral issues arise about the +level of consent actually involved in web use and associated tracking. -However, there is currently a huge disconnect between user privacy and -identity due to both the multi-origin nature of the web, and the failure of -browsers to adequately convey a sense of identity to the user. It is possible -to bridge this disconnect both by addressing the issues with the multi-origin -model, as well as providing the user with an explicit representation of their -web identity, and with control over this identity. +In fact, standardization efforts seemed to realize this problem early on but +failed to create a feasible recommendations for improving the situation. RFC +2965 governing HTTP State Management mandated in section 3.3.6 that +third-party origins must not cause the browser to transmit cookies unless the +interaction is ``verifiable'' and readily apparent to the user\cite{rfc2965}. +In section 6, it also strongly suggested that informed consent and user +control should govern the interaction of users to tracking identifiers. -% XXX: The dangers of adblockers and filters + the long-term imperative of -% improving privacy for the continued use of the advertising revenue model. +Without changes to browser behavior, browser interface, or both, such informed +consent is simply not possible on today's web. Several examples from academia +and practice show that it is possible to bridge this disconnect by addressing +the linkability issues with the web's origin model with minimal breakage. +Additionally, the first steps towards providing the user with an explicit +representation of their web identity have been taken. +The pieces are in place to build robust private browsing modes based on these +two approaches, and metrics exist to measure their success. + \bibliographystyle{plain} \bibliography{W3CIdentity} \clearpage

1 0

[arm/master] PID resolution fallbacks by ps and lsof
by atagar＠torproject.org 26 Apr '11

26 Apr '11

commit c62e15023f3f6fe791a5f6fc21f070c6e8f857fb Author: Damian Johnson <atagar(a)torproject.org> Date: Mon Apr 25 19:52:07 2011 -0700 PID resolution fallbacks by ps and lsof On Macs all of the current pid resolution tactics fails, so adding a couple more that work on that platform. --- src/util/torTools.py | 28 ++++++++++++++++++++++++++++ 1 files changed, 28 insertions(+), 0 deletions(-) diff --git a/src/util/torTools.py b/src/util/torTools.py index 0eebd20..08b04c0 100644 --- a/src/util/torTools.py +++ b/src/util/torTools.py @@ -122,6 +122,8 @@ def getPid(controlPort=9051, pidFilePath=None): 4. "netstat -npl | grep 127.0.0.1:%s" % <tor control port> 5. "ps -o pid -C tor" 6. "sockstat -4l -P tcp -p %i | grep tor" % <tor control port> + 7. "ps axc | egrep \" tor$\"" + 8. "lsof -wnPi | egrep \"^tor.*:%i\"" % <tor control port> If pidof or ps provide multiple tor instances then their results are discarded (since only netstat can differentiate using the control port). This @@ -201,6 +203,32 @@ def getPid(controlPort=9051, pidFilePath=None): if pid.isdigit(): return pid except IOError: pass + # attempts to resolve via a ps command that works on the mac (this and lsof + # are the only resolvers to work on that platform). This fails if: + # - tor's running under a different name + # - there's multiple instances of tor + + try: + results = sysTools.call("ps axc | egrep \" tor$\"") + if len(results) == 1 and len(results[0].split()) > 0: + pid = results[0].split()[0] + if pid.isdigit(): return pid + except IOError: pass + + # attempts to resolve via lsof - this should work on linux, mac, and bsd - + # this fails if: + # - tor's running under a different name + # - tor's being run as a different user due to permissions + # - there are multiple instances of Tor, using the + # same control port on different addresses. + + try: + results = sysTools.call("lsof -wnPi | egrep \"^tor.*:%i\"" % controlPort) + if len(results) == 1 and len(results[0].split()) > 1: + pid = results[0].split()[1] + if pid.isdigit(): return pid + except IOError: pass + return None def getBsdJailId():

1 0