Re: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.txt

Ted Hardie <> Tue, 08 March 2011 04:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C1453A68DB for <>; Mon, 7 Mar 2011 20:13:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.521
X-Spam-Status: No, score=-3.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EZWwDa2s6+vl for <>; Mon, 7 Mar 2011 20:13:33 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 77C053A68BA for <>; Mon, 7 Mar 2011 20:13:33 -0800 (PST)
Received: by qwh6 with SMTP id 6so4255074qwh.31 for <>; Mon, 07 Mar 2011 20:14:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BygJ1P9lUGtkpYilcYwSKdZQ3ddVv5E+AqBSeanMPVM=; b=k19oUk4byoIuCYLZTz1/+VcVfJRKDamiKYJ3O1bnuXOC2uYP9kB8CNP2krhGNx2KVQ y7DDIJLIOUsYbqapfjPSdXU0wJRClG1OPjjspRuW7wXUE7ApcMQ0n+q0dZf1xds5Zc8+ +2DlqG7G3UIS5UDhnqMMsvabcwbc7/jwvslrU=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GFjtS402DmSF5IZRXz+J+DqlduQb/1BHikJ3KkF8s4/p7RHN7LAfKSz561VcCzUSLo kTOlulHLeF7lntoygXFH2wKRefoJfGCwmqmUIN7IXvPqZY6WS2M3bIrLr0hVaIy6Q308 H04aghH5mpsadknMtsT49ExQ+PfF+CdbbPZFk=
MIME-Version: 1.0
Received: by with SMTP id hb18mr3516800qcb.176.1299557687406; Mon, 07 Mar 2011 20:14:47 -0800 (PST)
Received: by with HTTP; Mon, 7 Mar 2011 20:14:47 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Mon, 7 Mar 2011 20:14:47 -0800
Message-ID: <>
From: Ted Hardie <>
To: Sean Turner <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Privacy Directorate to develop the concept of privacy considerations for IETF specifications and to review internet-drafts for privacy considerations." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Mar 2011 04:13:34 -0000

I've read this draft, and I think it warrants discussion.

The most basic question for me is whether a single bit of information
about user preferences is sufficient in this case.  Having additional
bits which describe user preferences around tracking by first parties
seems to me necessary.

In particular, the document appears to assume that 1st party tracking
and 3rd party tracking done on behalf of a 1st party (see Exception 2)
are permitted even if DNT is set to "do not track".  That is, DNT is
really "No third party tracking" and it expects that there is a simple
mechanism by which third parties are distinguished from first parties.
 I personally have my doubts.  If I get content used to construct a
web page from source X and source Y are both X and Y first parties?
The single-pixel image may look like an obvious 3rd party, but the
protocol mechanics by which I distinguish that from and embedded RSS
feed are not clearly described in the document.  I can infer that I
use the public suffix list and the FQDN of either the link or the
browser bar, but this really needs to be spelled out.

The description of interaction with proxies needs to explain whether
the header has any impact on whether the response should be cached
and, if so, whether returns from the cache should be limited to
requests with the same DNT state.

I also find the exception for data which is "not linkable to a
specific user or user agent" somewhat hard to work through.  As the
two Narayanan papers cited show, anonymized data has been shown to
allow later identification.  How can we be certain that advertising
frequency capping or sequencing data has no similar issue without
specifying their format? Even if this is not intended as a loophole,
it seems likely to be exploited as one.

I have the haunting feeling that starting from this position is
inherently weak.  If we are truly interested in user control here, the
opposite tack, a "Know This" header which explicitly states the
information the user is willing to reveal seems to give far more real
control.  This seems to ask the browser to  set a "Don't be evil" bit
on its requests, but to leave the real control over what that means so
underspecified that reasonable people could conclude wildly different


Ted Hardie

On Mon, Mar 7, 2011 at 6:33 PM, Sean Turner <> wrote:
> -------- Original Message --------
> Subject: I-D ACTION:draft-mayer-do-not-track-00.txt
> Date: Mon, 07 Mar 2011 17:45:01 -0800
> From:
> Reply-To:
> To:
> A new Internet-Draft is available from the on-line Internet-Drafts
> directories.
>    Title         : Do Not Track: A Universal Third-Party Web Tracking Opt
> Out
>    Author(s)     : J. Mayer, et al
>    Filename      : draft-mayer-do-not-track-00.txt
>    Pages         : 6
>    Date          : 2011-03-07
> This document defines the syntax and semantics of Do Not Track, an
>   HTTP header-based mechanism that enables users to express preferences
>   about third-party web tracking.  It also provides a standard for how
>   web services should comply with such user preferences.
> A URL for this Internet-Draft is:
> Internet-Drafts are also available by anonymous FTP at:
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> _______________________________________________
> privacydir mailing list