Re: [privacydir] Privacy Terminology: What are useful terms?
Nick Mathewson <nickm@torproject.org> Sat, 16 July 2011 04:14 UTC
Return-Path: <nick.a.mathewson@gmail.com>
X-Original-To: privacydir@ietfa.amsl.com
Delivered-To: privacydir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB7821F8744 for <privacydir@ietfa.amsl.com>; Fri, 15 Jul 2011 21:14:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQpaeEwv9UZh for <privacydir@ietfa.amsl.com>; Fri, 15 Jul 2011 21:14:55 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9163421F86DF for <privacydir@ietf.org>; Fri, 15 Jul 2011 21:14:55 -0700 (PDT)
Received: by wwe5 with SMTP id 5so1231013wwe.13 for <privacydir@ietf.org>; Fri, 15 Jul 2011 21:14:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BNdxWBuGVYlKJc39Hg5LUgiM0LrQYo++HMoVs7bVoIA=; b=kd+K05UCsHWNgE2rJXg95Q7V5cm57PnhlQ4EsGNFb2sUMmV/BmaGAlVLlgx7q694FZ g97r/U8hlFKKe/TIbG14JbZpZYG4jhAh/5MjrcdUfKevoHcFlIa9KwOCG+JLTAzR8Xxr Un57lFA+oBeRzTMfqvLutAuiljkATLPcGWi5c=
MIME-Version: 1.0
Received: by 10.216.205.160 with SMTP id j32mr3594522weo.36.1310789694367; Fri, 15 Jul 2011 21:14:54 -0700 (PDT)
Sender: nick.a.mathewson@gmail.com
Received: by 10.216.46.66 with HTTP; Fri, 15 Jul 2011 21:14:54 -0700 (PDT)
In-Reply-To: <E3350ABE-A2A1-42BB-B446-54A90A0A64BC@gmx.net>
References: <5821BF1F-0FEF-4C6C-89A5-3A33BDE4F843@gmx.net> <CAKDKvuy80Rg4S8Pju2LqU7ew27oN2MNN_Z+FjWFVDiF=aGV7aA@mail.gmail.com> <E3350ABE-A2A1-42BB-B446-54A90A0A64BC@gmx.net>
Date: Sat, 16 Jul 2011 00:14:54 -0400
X-Google-Sender-Auth: jlynjmkiSouwe7NvUvSN_T0EwW0
Message-ID: <CAKDKvuyGcY50RV=VNn8vR81K6mQWS7gHKXD0bvARNF5nEvmzVw@mail.gmail.com>
From: Nick Mathewson <nickm@torproject.org>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: privacydir@ietf.org
Subject: Re: [privacydir] Privacy Terminology: What are useful terms?
X-BeenThere: privacydir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Privacy Directorate to develop the concept of privacy considerations for IETF specifications and to review internet-drafts for privacy considerations." <privacydir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/privacydir>, <mailto:privacydir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/privacydir>
List-Post: <mailto:privacydir@ietf.org>
List-Help: <mailto:privacydir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/privacydir>, <mailto:privacydir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Jul 2011 04:14:56 -0000
On Wed, Jul 13, 2011 at 5:39 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote: >> We don't use "undetectability" or "unobservability". >> >> > I have seen the unobservability term being used in security protocols when the traffic characteristics shall be hidden (via padding). > Aren't you doing something similar in Tor? If you do, how do you call that property? Well, we don't actually do enough padding right now to make many interesting characteristics unobservable. When we talk about padding, we usually talk not in terms of making the real traffic volume unobservable so much as we talk about making the padded view of a traffic stream unlinkable to an unpadded view. When we're talking in general about a particular unobservable property, we tend to use the active voice. Rather than say (for example) that stream open and close events are unobservable by an attacker watching the client, we tend to say that the attacker can't tell when streams open and close. (This is my sense from skimming and grepping our recent design documentation; it may be that I'm a bit off. Also, again, I'm not suggesting that our practice is better than the proposed terminology--just that it seems to be what we're doing.) [...] >> * We talk about one kind of or item being "distinguishable" from >> another. (For example, a protocol is "indistinguishable" from HTTPS >> to the extent that an attacker can't tell instances of that protocol >> from regular HTTPS connections.) > > Could be useful. [...] >> * We use "profiling" to mean learning information about an anonymous >> subject's activities without necessarily linking them to any specific >> transaction. For example, if an attacker concludes that I play WoW, >> read reddit.com, and upload videos, then my activities have been >> profiled, even if the attacker is unable to identity which connections >> or accounts are mine. > > Profiling may be a useful term to add. > Btw, I searched through the Tor documents and couldn't really find a definition. I think the closest you'd find might be in a discussion of guard nodes. But I don't think we ever came up with a good formal definition. >> Some additional terminology that I think might be idiosyncratic: >> >> * We use "linkable session" to refer to a set of actions by a >> subject that the system makes no effort to render unlinkable from one >> another. > > Could you provide an example? Sure. Take a session on a website. The user's browser might request resources from a number of different hosts, and might do so not only for one but for several pages. Nonetheless, it might make sense to treat all the TCP connections as part of a single "session", since each is already linked to all the rest semantically. For a more trivial example, suppose a user is logging in to a service pseudonymously. Given this behavior, there's no point to try to make different logins to the same pseudonymous account unlinkable by the service: the service can already link them through their use of the same pseudonym. >> * We refer as a "linking identifier" to any parameter P that an >> attacker can observe about an IOI and use to link it to similar IOIs >> that have similar values for P. For example, the window size header >> transmitted in a typical HTTP request is a linking identifier. >> > I wasn't aware that the window size header has such a characteristic. > Is there a paper you could recommend to learn more about this aspect? I'd check out the findings from the EFF panopticlick project for recent results in identifying web browsers by header. For older results, I'll need to look around a bit. Window size alone isn't enough to split off traffic by users (since people resize windows) and isn't enough to isolate users (since lots of people can share a single window size), but it helps plenty with statistical linking. cheers, -- Nick
- [privacydir] Privacy Terminology: What are useful… Hannes Tschofenig
- Re: [privacydir] Privacy Terminology: What are us… Nick Mathewson
- Re: [privacydir] Privacy Terminology: What are us… Hannes Tschofenig
- Re: [privacydir] Privacy Terminology: What are us… Nick Mathewson