From turners@ieca.com Mon Mar 7 10:29:04 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 143B33A6836 for ; Mon, 7 Mar 2011 10:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.363 X-Spam-Level: X-Spam-Status: No, score=-102.363 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZT9K7Oy0d-Ro for ; Mon, 7 Mar 2011 10:29:02 -0800 (PST) Received: from nm3.bullet.mail.sp2.yahoo.com (nm3.bullet.mail.sp2.yahoo.com [98.139.91.73]) by core3.amsl.com (Postfix) with SMTP id 32C663A67F3 for ; Mon, 7 Mar 2011 10:28:37 -0800 (PST) Received: from [98.139.91.62] by nm3.bullet.mail.sp2.yahoo.com with NNFMP; 07 Mar 2011 18:29:32 -0000 Received: from [98.139.91.21] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 07 Mar 2011 18:29:32 -0000 Received: from [127.0.0.1] by omp1021.mail.sp2.yahoo.com with NNFMP; 07 Mar 2011 18:29:32 -0000 X-Yahoo-Newman-Id: 319170.38241.bm@omp1021.mail.sp2.yahoo.com Received: (qmail 53421 invoked from network); 7 Mar 2011 18:29:32 -0000 Received: from thunderfish.local (turners@96.231.121.153 with plain) by smtp112.biz.mail.sp1.yahoo.com with SMTP; 07 Mar 2011 10:29:31 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: RdYjoYAVM1kMerp3JN0.YN780L0zre6ZHeYvuJ2dEg9.8PV kOGBidyhw1XXsKib.9cWYgiUeaxTmMlCnqnoVl..JvoW8kqIX1Z.PEd08iEO XSrKJSte3.2FhNKi.vklvvttHDCxAAo3dfRUL_Oaluizuax.oFSKjShqQp7H 4s5IkwVPLinZcP2FK.4eLYm8zYUljzKakorsi8qh3cWaqzal3dTm3v9syIA7 _bNNtoBF4uQigN7MmOAG.CKtTsc_didswNZS4vUoAeNXPVQmDQQRSepnkU.6 PwBKLi1ddp89SQofyFSKN5ZTTuwxHDMqNtQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D75240A.6000603@ieca.com> Date: Mon, 07 Mar 2011 13:29:30 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: privacydir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [privacydir] Fwd: Fwd: Call for a Jasmine Revolution in the IETF: Privacy, Integrity, Obscurity X-BeenThere: privacydir@ietf.org 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: Mon, 07 Mar 2011 18:29:04 -0000 FYI Begin forwarded message: > From: Dean Willis > Date: March 4, 2011 11:06:16 PM EST > To: ietf@ietf.org > Subject: Call for a Jasmine Revolution in the IETF: Privacy, Integrity, Obscurity > > > I just came across what may be old news to many of you. The July 2007 issue of IEEE Spectrum included an article entitled "The Athens Affair", subtitled "How Some Extremely Smart Hackers Pulled Off The Most Audacious Cell-Network Break-in Ever". In short, perpetrators appear to have accessed the lawful-intercept component of mobile switches in-use, and were able to tap a lot of phones, including that of the Prime Minister of the host nation. Apparently this was made easier by the fact that the user-interface for the LI component had not yet been installed, making it possible for the interceptions to go undetected for some time. > > This is just an example of a maxim: if we build nefarious mechanisms into systems, SOMEBODY is going to abuse them. Otherwise said: If you build in a back-door, don't be surprised when somebody sticks something in it. Sure, any meathead can slap a microphone on a window, order the withdrawal of a bunch of BGP routes, or cut the power to a switching center. There's not a lot we can do about that. But we can do a lot about a wide variety of "man in the middle" attacks, if we're willing to step up and confront the bullies out there, along with the misguided who don't understand why security back-doors are a two-edged sword, as dangerous to themselves as to their opposition. Sure, everybody wants their systems to be "secure" and their opposition's systems less so, but in the real world, everybody is somebody's opposition. The only way to be safe is to have universal protections. Start by locking yourself out. If that works, then it MAY stop the bad guys too. > > So what can we do about it? > > Every document we now produce has a "Security Considerations". I hereby propose the following extensions to that section, such that each specification requiring a meaningful Security Considerations section MUST address the following: > > 1) Privacy and Integrity: We believe that intermediaries should be neither able to understand nor alter the transmitted material without the explicit consent and awareness of the users. How are the principles of end-to-end privacy and integrity provided by the specification? Reasonable solutions might include any of our well-documented encryption and signature systems coupled with applicable key management mechanisms. Analysis within the specification should also describe the known limitations of the specification, such as susceptibility to hostile certificate authorities. Further, forthcoming IETF specifications MUST not allow plain-text transmission of anything within any protocol. Sign or cipher (or both, as appropriate) everything, all the time. > > 2) Privacy and Obscurity: We believe that observation of a traffic flow pr sequence of traffic flows should reveal as little information about the application or user of the application as possible to an intermediary who observes the traffic without the explicit consent and awareness of the user. In principle, "deep packet inspection" should be completely useless, as should attempts by an intermediary to trace the end-user(s) to a specific physical location. How does the specification provide for obscuring the content of the application and the identity and location of users involved in the sequence? Reasonable solutions might include things like TOR combined with TLS. Analysis within the specification should also describe known limitations of the specification, such as frequency and time domain analysis at a network-adjacent node, or dependency on interceptible dereferencing mechanisms like the DNS. > > > Currently we have millions of people using our protocols to defend themselves from aggressors, who typically have more reach "into the infrastructure" than the end users do. I know the utilization on my TOR exit relay has been 100% for several months now, so there are clearly people who understand enough of the problem to be attempting some sort of defense. And we have persons in authority who find open communication threatening and frequently "shutting down" access to parts of the net, such as LinkedIn, Facebook, Skype, Blackberry Messenger, or whatever they deem threatening on any given day. We can't keep them from turning off the whole Internet, but if we design protocols correctly, we can force them to choose between participating in the civilization of the Internet, ALL OF IT, or being completely isolated. > > If we do NOT act on this proposal, then our misguided leaders, censors, tyrants, and fools will continue to be able to piecemeal select which parts of the Internet they will allow, thereby manufacturing their own self-serving subsets of "the truth". At the same time, criminals will continue to exploit protocol weaknesses to spam, spoof, steal, and subvert. And the Internet will not be the mechanism for peaceful economic expansion, prosperity, and interpersonal communication that it could be. > > > Much, I think, can be judged about respondents to this manifesto by the nature of their response. Many will quite reasonably say "This is hard to do". I agree; we can't expect immediate perfect answers, just as we know we've never been able to get perfect answers to most any security question, we know we will never produce perfect solutions for these issues. Others will say that these goals are undesirable. I suspect that these individuals are either proprietors of deep-packet-inspection tools, thieves, or accessories to the overbearing governments who employ and enable the afore-mentioned classes of miscreant. Others may agree wholeheartedly, but flinch at the political repercussions. To them, I say: Step up. No good deed goes unpunished, but at least the goal is worthwhile. And it's probably safer than standing in front of a tank or a camel-cavalry charge, although less likely to get you remembered. Yet others may ask why this proposal is made now, rather than the first of > next month. To them, I say that timing is everything. > > -- > Dean Willis > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From llynch@civil-tongue.net Mon Mar 7 13:35:25 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E92F3A682C for ; Mon, 7 Mar 2011 13:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.026 X-Spam-Level: X-Spam-Status: No, score=-102.026 tagged_above=-999 required=5 tests=[AWL=0.573, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJFemKll8aFg for ; Mon, 7 Mar 2011 13:35:23 -0800 (PST) Received: from hiroshima.bogus.com (hiroshima.bogus.com [IPv6:2001:418:1::80]) by core3.amsl.com (Postfix) with ESMTP id DC3103A6819 for ; Mon, 7 Mar 2011 13:35:22 -0800 (PST) Received: from hiroshima.bogus.com (localhost [127.0.0.1]) by hiroshima.bogus.com (8.14.3/8.14.3) with ESMTP id p27LaaMD049097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 7 Mar 2011 13:36:36 -0800 (PST) (envelope-from llynch@civil-tongue.net) Received: from localhost (llynch@localhost) by hiroshima.bogus.com (8.14.3/8.14.3/Submit) with ESMTP id p27LaZvP049093 for ; Mon, 7 Mar 2011 13:36:35 -0800 (PST) (envelope-from llynch@civil-tongue.net) Date: Mon, 7 Mar 2011 13:36:35 -0800 (PST) From: Lucy Lynch X-X-Sender: llynch@hiroshima.bogus.com To: privacydir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [privacydir] [abfab] A proposal for dealing with EU data protection & identifiers (fwd) X-BeenThere: privacydir@ietf.org 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: Mon, 07 Mar 2011 21:35:25 -0000 forwarded for your information - Lucy ---------- Forwarded message ---------- Date: Mon, 7 Mar 2011 21:15:51 +0000 From: Josh Howlett To: "abfab@ietf.org" Cc: Josh Howlett Subject: [abfab] A proposal for dealing with EU data protection & identifiers I admit that this is likely to be something of a minority interest. It's hard to get people excited about privacy and data protection law and identifiers. However, I claim that it this an important problem to solve. Unfortunately, understanding this requirement requires some knowledge of the implications of EU data protection law on federated identity before. I provide a brief summary below, before setting out my proposal. ** Problem description ** Very frequently, a relying party will want a unique identifier for a user. Such identifiers are very useful for recognition (knowing that a user is the same as one seen previously) and accountability (so that abuse, etc, can be tracked). Within federations today, it is common for identity providers to release these identifiers to relying parties. These identifiers may name a user explicitly (e.g. taking a value of an email address), but other identifiers can name a user pseudonymously (e.g. by taking an opaque value) to improve privacy. The release of these identifiers often have legal implications. The EU data protection regime treats all such identifiers as 'personally identifiable information', because it can be linked directly or indirectly to a person. One of the practical consequences of this (within the EU) is that it is highly desirable to have a legal contract between the issuer and consumer of an identifier. By default the IdP will be responsible for all misuse of the identifier by the RP, with civil and/or criminal implications depending on the EU member state in question. A contract is not an onerous requirement if -- for example -- the RP is formally providing some kind of service or content to the IdP organisation; there will generally be a contract to control that business relationship regardless. However, increasingly a user may want access to an RP that his IdP has no relationship with; and often that RP will want an identifier. Unfortunately, addressing the general case (pairwise contracts between all IdPs and all SPs in federation) creates a legal scalability problem that people involved in EU federation policy and governance get fairly exercised about. User consent is sometimes invoked as a mechanism for addressing identifier release to 'unknown' RPs, but in general it's not a useful strategy within the EU (though it might be fine in other jurisdictions). There are other approaches that use umbrella legal structures to control the risk, but EU member states take different views on the appropriateness of these structures, and so they are not generally universally applicable. In summary it would be ideal if the RP could be provisioned with an identifier without invoking the EU data protection regime, at all. ** Proposal ** It turns out that the EU data protection regime does not have any opinions about an IdP either confirming or denying if an identifier is associated with a user. Thus, it appears that it is possible to entirely sidestep the data protection regime by having the RP pose the question "please confirm that it is reasonable for this user to claim the identifier FOO", rather than the more conventional request "please provide an identifier for this user". I don't know if this is true for other jurisdictions other than the EU. If anyone else also has access to lawyers with DP knowledge of other jurisdictions, it would be wonderful if you could bounce this approach off them. I'm currently working on the assumption that, because the EU DP regime is one of the more difficult (or so I understand), it should work elsewhere, but that's purely an assumption. The more educated opinions, the better. Therefore, my proposal is that we should seek to model identifier assignment using a 'confirmation' model, rather than the conventional 'release' model. I believe the semantics of the identifier confirmation model should be: Acceptor: "Is the identifier FOO associated with a user that you know about?". IdP: "Confirm", "Deny", "Neither Confirm Nor Deny". The value of FOO would be asserted by the initiator to the acceptor. It would take an opaque value that the IdP can verify is only likely to have been generated by a user that it knows about. The value should generally be permanent, but it should also be possible to change it on a per-acceptor basis if necessary. We have some existing components in the ABFAB toolbox that I believe we can re-use to avoid creating significant work. Sam and I bounced around a few ideas earlier this morning, but as a first step we thought it would be useful to know what the WG thinks of this as a general strategy. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG _______________________________________________ abfab mailing list abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab From acooper@cdt.org Mon Mar 7 14:13:43 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A176A3A68C0 for ; Mon, 7 Mar 2011 14:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZTAHk0Ojr+Y for ; Mon, 7 Mar 2011 14:13:42 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id B49243A67B4 for ; Mon, 7 Mar 2011 14:13:42 -0800 (PST) Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for privacydir@ietf.org; Mon, 7 Mar 2011 17:14:53 -0500 Message-Id: <8C2B7D4F-8C7A-4E0D-B451-E4638556E28E@cdt.org> From: Alissa Cooper To: privacydir@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 7 Mar 2011 22:14:52 +0000 References: <20110307220505.5752828C0F0@core3.amsl.com> X-Mailer: Apple Mail (2.936) Subject: [privacydir] Fwd: New Version Notification for draft-cooper-web-tracking-opt-outs-00 X-BeenThere: privacydir@ietf.org 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: Mon, 07 Mar 2011 22:13:43 -0000 FYI Begin forwarded message: > From: IETF I-D Submission Tool > Date: March 7, 2011 10:05:05 PM GMT > To: acooper@cdt.org > Cc: hannes.tschofenig@nsn.com > Subject: New Version Notification for draft-cooper-web-tracking-opt- > outs-00 > > > A new version of I-D, draft-cooper-web-tracking-opt-outs-00.txt has > been successfully submitted by Alissa Cooper and posted to the IETF > repository. > > Filename: draft-cooper-web-tracking-opt-outs > Revision: 00 > Title: Overview of Universal Opt-Out Mechanisms for Web Tracking > Creation_date: 2011-03-07 > WG ID: Independent Submission > Number_of_pages: 20 > > Abstract: > Web servers and the entities that operate them have long had the > ability to track user agents as they access resources hosted across > different web domains. Concern over the privacy implications of such > tracking has prompted recent work on a number of solutions that aim > to provide a universal opt-out mechanism for web tracking that can be > effectuated through a simple binary choice presented to users. > > This document provides an overview of the following mechanisms: > permanent opt-out cookies, cookie blocking, domain blocking, a "Do > Not Track" (DNT) HTTP header, and a Do Not Track Document Object > Model (DOM) property. The aim of this document is to describe each > approach, the pros and cons of each, and areas where standardization > may be necessary should each approach be further pursued, without > making recommendations about which approach or approaches should be > adopted. > > > > The IETF Secretariat. > > > -- ---------------------------------------------------- Alissa Cooper Chief Computer Scientist Center for Democracy and Technology +44 (0)785 916 0031 Skype: alissacooper From turners@ieca.com Mon Mar 7 18:32:51 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 385763A68D0 for ; Mon, 7 Mar 2011 18:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLx031LOjYbM for ; Mon, 7 Mar 2011 18:32:48 -0800 (PST) Received: from nm12-vm0.bullet.mail.sp2.yahoo.com (nm12-vm0.bullet.mail.sp2.yahoo.com [98.139.91.242]) by core3.amsl.com (Postfix) with SMTP id 637103A68B8 for ; Mon, 7 Mar 2011 18:32:48 -0800 (PST) Received: from [98.139.91.63] by nm12.bullet.mail.sp2.yahoo.com with NNFMP; 08 Mar 2011 02:34:00 -0000 Received: from [98.139.91.25] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 08 Mar 2011 02:33:59 -0000 Received: from [127.0.0.1] by omp1025.mail.sp2.yahoo.com with NNFMP; 08 Mar 2011 02:33:59 -0000 X-Yahoo-Newman-Id: 970514.31834.bm@omp1025.mail.sp2.yahoo.com Received: (qmail 42790 invoked from network); 8 Mar 2011 02:33:59 -0000 Received: from thunderfish.local (turners@96.241.7.112 with plain) by smtp111.biz.mail.sp1.yahoo.com with SMTP; 07 Mar 2011 18:33:59 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: N2Hd5z4VM1kchTJ7fRyhYAXwLrC45dr8Y6bGIlTsJIUdTAk mRM14apaAOHVaRNJLzpOL3YTyryJk7V7W0AVEVCBOorJYwyeTVwe6raulidj 7IW_OxYMKjZogmTu.PAKXKpXUaeq5TlAbzSlV9RfMToIWnbahXM5wyb79umz a4MLthXxLgk3RQAQn5EvOGdTZxHyUv4bE4BKhpPwZRT_jB0qKbdZfDtjaxve i0CVyn7S88v7DHSgbt2iKxh83bCwKcSsOrgZaDbZrctY16ar4rIbm2afL3iM urPMkvcZDTfYyVCYOjsJbQTbWDphKbj_ZDQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D759595.60809@ieca.com> Date: Mon, 07 Mar 2011 21:33:57 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: privacydir@ietf.org Content-Type: multipart/mixed; boundary="------------030800090307090409090600" Subject: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.txt X-BeenThere: privacydir@ietf.org 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 02:32:51 -0000 This is a multi-part message in MIME format. --------------030800090307090409090600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI -------- Original Message -------- Subject: I-D ACTION:draft-mayer-do-not-track-00.txt Date: Mon, 07 Mar 2011 17:45:01 -0800 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org 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: http://www.ietf.org/internet-drafts/draft-mayer-do-not-track-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------030800090307090409090600 Content-Type: Message/External-body; name="draft-mayer-do-not-track-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-mayer-do-not-track-00.txt" Content-Type: text/plain Content-ID: <2011-03-07173333.I-D@ietf.org> --------------030800090307090409090600 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------030800090307090409090600-- From ted.ietf@gmail.com Mon Mar 7 20:13:34 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C1453A68DB for ; Mon, 7 Mar 2011 20:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.521 X-Spam-Level: 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZWwDa2s6+vl for ; Mon, 7 Mar 2011 20:13:33 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (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; d=gmail.com; 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; d=gmail.com; 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 10.229.214.210 with SMTP id hb18mr3516800qcb.176.1299557687406; Mon, 07 Mar 2011 20:14:47 -0800 (PST) Received: by 10.229.11.74 with HTTP; Mon, 7 Mar 2011 20:14:47 -0800 (PST) In-Reply-To: <4D759595.60809@ieca.com> References: <4D759595.60809@ieca.com> 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 Cc: privacydir@ietf.org Subject: Re: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.txt X-BeenThere: privacydir@ietf.org 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 things. regards, Ted Hardie On Mon, Mar 7, 2011 at 6:33 PM, Sean Turner wrote: > FYI > > -------- Original Message -------- > Subject: I-D ACTION:draft-mayer-do-not-track-00.txt > Date: Mon, 07 Mar 2011 17:45:01 -0800 > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > A new Internet-Draft is available from the on-line Internet-Drafts > directories. > > > =A0 =A0Title =A0 =A0 =A0 =A0 : Do Not Track: A Universal Third-Party Web = Tracking Opt > Out > =A0 =A0Author(s) =A0 =A0 : J. Mayer, et al > =A0 =A0Filename =A0 =A0 =A0: draft-mayer-do-not-track-00.txt > =A0 =A0Pages =A0 =A0 =A0 =A0 : 6 > =A0 =A0Date =A0 =A0 =A0 =A0 =A0: 2011-03-07 > > This document defines the syntax and semantics of Do Not Track, an > =A0 HTTP header-based mechanism that enables users to express preferences > =A0 about third-party web tracking. =A0It also provides a standard for ho= w > =A0 web services should comply with such user preferences. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mayer-do-not-track-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > 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 > privacydir@ietf.org > https://www.ietf.org/mailman/listinfo/privacydir > > From Kasey.Chappelle@vodafone.com Tue Mar 8 05:13:01 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A73D3A6821 for ; Tue, 8 Mar 2011 05:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WUHG+M53Nlk for ; Tue, 8 Mar 2011 05:13:00 -0800 (PST) Received: from mailout04.vodafone.com (mailout04.vodafone.com [195.232.224.73]) by core3.amsl.com (Postfix) with ESMTP id D30993A6839 for ; Tue, 8 Mar 2011 05:12:59 -0800 (PST) Received: from mailint04 (localhost [127.0.0.1]) by mailout04 (Postfix) with ESMTP id D017B132B49 for ; Tue, 8 Mar 2011 14:14:09 +0100 (CET) Received: from avoexs02.internal.vodafone.com (unknown [145.230.4.135]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailint04 (Postfix) with ESMTPS id BBBDF13244F; Tue, 8 Mar 2011 14:14:09 +0100 (CET) Received: from VF-MBX19.internal.vodafone.com ([145.230.5.36]) by avoexs02.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Mar 2011 14:14:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Mar 2011 14:14:05 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.txt Thread-Index: AcvdR1/dQ/nYFi6YQ1SBmJDhArMDaAASW9mA References: <4D759595.60809@ieca.com> From: "Chappelle, Kasey, VF-Group" To: "Ted Hardie" , "Sean Turner" X-OriginalArrivalTime: 08 Mar 2011 13:14:08.0984 (UTC) FILETIME=[B57A3580:01CBDD92] Cc: privacydir@ietf.org Subject: Re: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.txt X-BeenThere: privacydir@ietf.org 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 13:13:01 -0000 Think of all the basic web functions you'd be breaking if first-party = tracking weren't allowed. Also consider the very different privacy = implications between a party you've actively engaged with knowing what = you're doing while you interact with them, vs. the third party you have = no relationship with. There's a very real privacy threat here we need to = address, but lumping all tracking together may not be the way to do it. = Emerging regulatory structures around this, even in the most restrictive = regimes, have acknowledged the difference.=20 Also, anonymous data linked to an individual should and would still be = covered. But what about data collection that occurs without any unique = identifiers at all. The Narayanan papers talk about deanonymization of = individually identifiable data sets. Let's make sure we understand the = full privacy implications in either case before we jump to conclusions - = is frequency-capping actually a privacy-impacting process? I'd say no.=20 One of the problems of data protection law is that it treats all data = collection similarly, without acknowledging degrees of harm. Let's not = fall into the same trap.=20 -----Original Message----- From: privacydir-bounces@ietf.org [mailto:privacydir-bounces@ietf.org] = On Behalf Of Ted Hardie Sent: 08 March 2011 04:15 To: Sean Turner Cc: privacydir@ietf.org Subject: Re: [privacydir] Fwd: I-D = ACTION:draft-mayer-do-not-track-00.txt 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 things. regards, Ted Hardie On Mon, Mar 7, 2011 at 6:33 PM, Sean Turner wrote: > FYI > > -------- Original Message -------- > Subject: I-D ACTION:draft-mayer-do-not-track-00.txt > Date: Mon, 07 Mar 2011 17:45:01 -0800 > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > A new Internet-Draft is available from the on-line Internet-Drafts > directories. > > > =A0 =A0Title =A0 =A0 =A0 =A0 : Do Not Track: A Universal Third-Party = Web Tracking Opt > Out > =A0 =A0Author(s) =A0 =A0 : J. Mayer, et al > =A0 =A0Filename =A0 =A0 =A0: draft-mayer-do-not-track-00.txt > =A0 =A0Pages =A0 =A0 =A0 =A0 : 6 > =A0 =A0Date =A0 =A0 =A0 =A0 =A0: 2011-03-07 > > This document defines the syntax and semantics of Do Not Track, an > =A0 HTTP header-based mechanism that enables users to express = preferences > =A0 about third-party web tracking. =A0It also provides a standard for = how > =A0 web services should comply with such user preferences. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mayer-do-not-track-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > 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 > privacydir@ietf.org > https://www.ietf.org/mailman/listinfo/privacydir > > _______________________________________________ privacydir mailing list privacydir@ietf.org https://www.ietf.org/mailman/listinfo/privacydir From stephen.farrell@cs.tcd.ie Tue Mar 8 05:18:36 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82E2A3A6839 for ; Tue, 8 Mar 2011 05:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.462 X-Spam-Level: X-Spam-Status: No, score=-103.462 tagged_above=-999 required=5 tests=[AWL=-0.863, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XrZxnLLXhwt for ; Tue, 8 Mar 2011 05:18:35 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id 15BF23A6821 for ; Tue, 8 Mar 2011 05:18:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 1247E3E4090; Tue, 8 Mar 2011 13:19:47 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1299590386; bh=XuNUanoI/LHj+2 3AaFxwbUTRDVFoDdMe96BF4jLG9Mk=; b=fbf8be4GkRsIkrwDgMhwV84L9wBLi/ KdJniE3/1nUxo/q2uvj75HHErOW8BgVtkEyiFmvzeFFUa7/xXzrNUOnHSiit+Du2 X5AZrXdZXSoyub1Eg6mvIo8ovNDvCzwsdA/NXlaCoRfTxkxfHy0Sd8qc/x2H/z1G fg7msYrOWUu4AfyC0C2CiPoeamoN+/qjZ/OwYQKXtchO0A/G8RhAAQaRhW7syojX /7m+Yc9mfZh+1stBg+HosROyPrzCtM5prSCJYgC+sxlbMIXAQD7NNIexn4j8a/jc YjB94mQxQQETyFyT4YvSxRr5DvYiW6Lbp/gXSAVC8LqBjqpxiwR1HYJA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id HjtT15ndyhFQ; Tue, 8 Mar 2011 13:19:46 +0000 (GMT) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 163AE3E408C; Tue, 8 Mar 2011 13:19:45 +0000 (GMT) Message-ID: <4D762CF1.2040609@cs.tcd.ie> Date: Tue, 08 Mar 2011 13:19:45 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: "Chappelle, Kasey, VF-Group" References: <4D759595.60809@ieca.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: privacydir@ietf.org Subject: Re: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.txt X-BeenThere: privacydir@ietf.org 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 13:18:36 -0000 On 08/03/11 13:14, Chappelle, Kasey, VF-Group wrote: > Think of all the basic web functions you'd be breaking if first-party tracking weren't allowed. Just wondering. Do we have a good list of those somewhere? S. > Also consider the very different privacy implications between a party you've actively engaged with knowing what you're doing while you interact with them, vs. the third party you have no relationship with. There's a very real privacy threat here we need to address, but lumping all tracking together may not be the way to do it. Emerging regulatory structures around this, even in the most restrictive regimes, have acknowledged the difference. > > Also, anonymous data linked to an individual should and would still be covered. But what about data collection that occurs without any unique identifiers at all. The Narayanan papers talk about deanonymization of individually identifiable data sets. Let's make sure we understand the full privacy implications in either case before we jump to conclusions - is frequency-capping actually a privacy-impacting process? I'd say no. > > One of the problems of data protection law is that it treats all data collection similarly, without acknowledging degrees of harm. Let's not fall into the same trap. > > -----Original Message----- > From: privacydir-bounces@ietf.org [mailto:privacydir-bounces@ietf.org] On Behalf Of Ted Hardie > Sent: 08 March 2011 04:15 > To: Sean Turner > Cc: privacydir@ietf.org > Subject: Re: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.txt > > 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 > things. > > regards, > > Ted Hardie > > > On Mon, Mar 7, 2011 at 6:33 PM, Sean Turner wrote: >> FYI >> >> -------- Original Message -------- >> Subject: I-D ACTION:draft-mayer-do-not-track-00.txt >> Date: Mon, 07 Mar 2011 17:45:01 -0800 >> From: Internet-Drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> 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: >> http://www.ietf.org/internet-drafts/draft-mayer-do-not-track-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> 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 >> privacydir@ietf.org >> https://www.ietf.org/mailman/listinfo/privacydir >> >> > _______________________________________________ > privacydir mailing list > privacydir@ietf.org > https://www.ietf.org/mailman/listinfo/privacydir > _______________________________________________ > privacydir mailing list > privacydir@ietf.org > https://www.ietf.org/mailman/listinfo/privacydir > From Kasey.Chappelle@vodafone.com Tue Mar 8 05:30:32 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB8453A684F for ; Tue, 8 Mar 2011 05:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wo5dYHg-NSO4 for ; Tue, 8 Mar 2011 05:30:21 -0800 (PST) Received: from mailout06.vodafone.com (mailout06.vodafone.com [195.232.224.75]) by core3.amsl.com (Postfix) with ESMTP id 8F11E3A687A for ; Tue, 8 Mar 2011 05:30:17 -0800 (PST) Received: from mailint06 (localhost [127.0.0.1]) by mailout06 (Postfix) with ESMTP id 2069F84EC6 for ; Tue, 8 Mar 2011 14:31:31 +0100 (CET) Received: from avoexs02.internal.vodafone.com (unknown [145.230.4.135]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailint06 (Postfix) with ESMTPS id 0AB6684E96; Tue, 8 Mar 2011 14:31:31 +0100 (CET) Received: from VF-MBX19.internal.vodafone.com ([145.230.5.36]) by avoexs02.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Mar 2011 14:31:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Mar 2011 14:31:28 +0100 Message-ID: In-Reply-To: <4D762CF1.2040609@cs.tcd.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.txt Thread-Index: Acvdk4ADW4vPn0OiR2imjkQ0YHNvPQAABmXA References: <4D759595.60809@ieca.com> <4D762CF1.2040609@cs.tcd.ie> From: "Chappelle, Kasey, VF-Group" To: "Stephen Farrell" X-OriginalArrivalTime: 08 Mar 2011 13:31:30.0921 (UTC) FILETIME=[22852D90:01CBDD95] Cc: privacydir@ietf.org Subject: Re: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.txt X-BeenThere: privacydir@ietf.org 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 13:30:32 -0000 Good question - perhaps someone with more technical expertise than I have can help. But there are lots of reasons why site owners would need to track their own visitors. Just off the top of my head, where would we put things like state management? Maintaining shopping carts from page to page or on subsequent visits, for example, requires you to track a visitor to your site across pages and sessions.=20 -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=20 Sent: 08 March 2011 13:20 To: Chappelle, Kasey, VF-Group Cc: Ted Hardie; Sean Turner; privacydir@ietf.org Subject: Re: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.txt On 08/03/11 13:14, Chappelle, Kasey, VF-Group wrote: > Think of all the basic web functions you'd be breaking if first-party tracking weren't allowed.=20 Just wondering. Do we have a good list of those somewhere? S. > Also consider the very different privacy implications between a party you've actively engaged with knowing what you're doing while you interact with them, vs. the third party you have no relationship with. There's a very real privacy threat here we need to address, but lumping all tracking together may not be the way to do it. Emerging regulatory structures around this, even in the most restrictive regimes, have acknowledged the difference.=20 >=20 > Also, anonymous data linked to an individual should and would still be covered. But what about data collection that occurs without any unique identifiers at all. The Narayanan papers talk about deanonymization of individually identifiable data sets. Let's make sure we understand the full privacy implications in either case before we jump to conclusions - is frequency-capping actually a privacy-impacting process? I'd say no.=20 >=20 > One of the problems of data protection law is that it treats all data collection similarly, without acknowledging degrees of harm. Let's not fall into the same trap.=20 >=20 > -----Original Message----- > From: privacydir-bounces@ietf.org [mailto:privacydir-bounces@ietf.org] On Behalf Of Ted Hardie > Sent: 08 March 2011 04:15 > To: Sean Turner > Cc: privacydir@ietf.org > Subject: Re: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.txt >=20 > I've read this draft, and I think it warrants discussion. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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 > things. >=20 > regards, >=20 > Ted Hardie >=20 >=20 > On Mon, Mar 7, 2011 at 6:33 PM, Sean Turner wrote: >> FYI >> >> -------- Original Message -------- >> Subject: I-D ACTION:draft-mayer-do-not-track-00.txt >> Date: Mon, 07 Mar 2011 17:45:01 -0800 >> From: Internet-Drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> 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: >> http://www.ietf.org/internet-drafts/draft-mayer-do-not-track-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> 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 >> privacydir@ietf.org >> https://www.ietf.org/mailman/listinfo/privacydir >> >> > _______________________________________________ > privacydir mailing list > privacydir@ietf.org > https://www.ietf.org/mailman/listinfo/privacydir > _______________________________________________ > privacydir mailing list > privacydir@ietf.org > https://www.ietf.org/mailman/listinfo/privacydir >=20 From stephen.farrell@cs.tcd.ie Tue Mar 8 05:53:23 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C6A33A689E for ; Tue, 8 Mar 2011 05:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.289 X-Spam-Level: X-Spam-Status: No, score=-103.289 tagged_above=-999 required=5 tests=[AWL=-0.690, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Mtzlnjm8cpK for ; Tue, 8 Mar 2011 05:53:21 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id 77CE53A6874 for ; Tue, 8 Mar 2011 05:53:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id EB0883E4079; Tue, 8 Mar 2011 13:54:32 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1299592472; bh=pAwsFkJiOqkqR1 HXS/hKnh1iFvmrzFJ+FRVAZJERCkA=; b=2GgPlUXLB/0hj01EItDoqNnEP4tnbN PJYt//DoGCmKtGY8hxONeD4JGSLmkOWbaDCKnhSx/KcsBfUyUYiB7TR/UIdnuocG zSKsvEqBH2FZIl7+ZeAlH3TG/EUf1F749vOotoU6Hima8tTga+hrRWXqDr1jwT01 LDI/Nl7cazFOYrmO6TCCEjvC+9zUKqtuv7puI/LpEn0x4dxg2el/SdKDB8Qk4cSK oSb0M40hinyRaJAxaqbMFAPh9dhJAF0jqN37t7cjvZz0FQ8ULHXlUJZVpH5ENfrq ajxF3Tlr/IdbKT8hfxQnAMtLdLw/uXrlQy6WCm2Gero7/RiriLYIuIyg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id d-iuT09JvrxE; Tue, 8 Mar 2011 13:54:32 +0000 (GMT) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 23F683E406D; Tue, 8 Mar 2011 13:54:32 +0000 (GMT) Message-ID: <4D763517.3090700@cs.tcd.ie> Date: Tue, 08 Mar 2011 13:54:31 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: "Chappelle, Kasey, VF-Group" References: <4D759595.60809@ieca.com> <4D762CF1.2040609@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: privacydir@ietf.org Subject: Re: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.txt X-BeenThere: privacydir@ietf.org 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 13:53:23 -0000 On 08/03/11 13:31, Chappelle, Kasey, VF-Group wrote: > Good question - perhaps someone with more technical expertise than I > have can help. That'd be good. > But there are lots of reasons why site owners would need > to track their own visitors. Just off the top of my head, where would we > put things like state management? Maintaining shopping carts from page > to page or on subsequent visits, for example, requires you to track a > visitor to your site across pages and sessions. Fair enough. However, I suspect that site owners, (like all of us really) perhaps didn't pay so much attention to privacy in the past, so it could well be that some of those 1st party tracking practices are also privacy-invasive and perhaps not as necessary as they're assumed to be. However, I don't know, so that's why I asked. S. > > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: 08 March 2011 13:20 > To: Chappelle, Kasey, VF-Group > Cc: Ted Hardie; Sean Turner; privacydir@ietf.org > Subject: Re: [privacydir] Fwd: I-D > ACTION:draft-mayer-do-not-track-00.txt > > > > On 08/03/11 13:14, Chappelle, Kasey, VF-Group wrote: >> Think of all the basic web functions you'd be breaking if first-party > tracking weren't allowed. > > Just wondering. Do we have a good list of those somewhere? > > S. > >> Also consider the very different privacy implications between a party > you've actively engaged with knowing what you're doing while you > interact with them, vs. the third party you have no relationship with. > There's a very real privacy threat here we need to address, but lumping > all tracking together may not be the way to do it. Emerging regulatory > structures around this, even in the most restrictive regimes, have > acknowledged the difference. >> >> Also, anonymous data linked to an individual should and would still be > covered. But what about data collection that occurs without any unique > identifiers at all. The Narayanan papers talk about deanonymization of > individually identifiable data sets. Let's make sure we understand the > full privacy implications in either case before we jump to conclusions - > is frequency-capping actually a privacy-impacting process? I'd say no. >> >> One of the problems of data protection law is that it treats all data > collection similarly, without acknowledging degrees of harm. Let's not > fall into the same trap. >> >> -----Original Message----- >> From: privacydir-bounces@ietf.org [mailto:privacydir-bounces@ietf.org] > On Behalf Of Ted Hardie >> Sent: 08 March 2011 04:15 >> To: Sean Turner >> Cc: privacydir@ietf.org >> Subject: Re: [privacydir] Fwd: I-D > ACTION:draft-mayer-do-not-track-00.txt >> >> 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 >> things. >> >> regards, >> >> Ted Hardie >> >> >> On Mon, Mar 7, 2011 at 6:33 PM, Sean Turner wrote: >>> FYI >>> >>> -------- Original Message -------- >>> Subject: I-D ACTION:draft-mayer-do-not-track-00.txt >>> Date: Mon, 07 Mar 2011 17:45:01 -0800 >>> From: Internet-Drafts@ietf.org >>> Reply-To: internet-drafts@ietf.org >>> To: i-d-announce@ietf.org >>> >>> 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: >>> http://www.ietf.org/internet-drafts/draft-mayer-do-not-track-00.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> 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 >>> privacydir@ietf.org >>> https://www.ietf.org/mailman/listinfo/privacydir >>> >>> >> _______________________________________________ >> privacydir mailing list >> privacydir@ietf.org >> https://www.ietf.org/mailman/listinfo/privacydir >> _______________________________________________ >> privacydir mailing list >> privacydir@ietf.org >> https://www.ietf.org/mailman/listinfo/privacydir >> > From Kasey.Chappelle@vodafone.com Tue Mar 8 06:08:20 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 202343A6843 for ; Tue, 8 Mar 2011 06:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDdVLjS9nOwr for ; Tue, 8 Mar 2011 06:08:18 -0800 (PST) Received: from mailout03.vodafone.com (mailout03.vodafone.com [195.232.224.72]) by core3.amsl.com (Postfix) with ESMTP id 92BD83A63CB for ; Tue, 8 Mar 2011 06:08:18 -0800 (PST) Received: from mailint03 (localhost [127.0.0.1]) by mailout03 (Postfix) with ESMTP id 32754116AB7 for ; Tue, 8 Mar 2011 15:09:32 +0100 (CET) Received: from avoexs04.internal.vodafone.com (avoexs04.dc-ratingen.de [145.230.4.198]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailint03 (Postfix) with ESMTPS id 19224116AB6; Tue, 8 Mar 2011 15:09:32 +0100 (CET) Received: from VF-MBX19.internal.vodafone.com ([145.230.5.36]) by avoexs04.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Mar 2011 15:09:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Mar 2011 15:09:28 +0100 Message-ID: In-Reply-To: <4D763517.3090700@cs.tcd.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.txt Thread-Index: AcvdmGFPdRUQ+IQVRcuUTgZVmtPGpAAAaavw References: <4D759595.60809@ieca.com> <4D762CF1.2040609@cs.tcd.ie> <4D763517.3090700@cs.tcd.ie> From: "Chappelle, Kasey, VF-Group" To: "Stephen Farrell" X-OriginalArrivalTime: 08 Mar 2011 14:09:31.0818 (UTC) FILETIME=[720A70A0:01CBDD9A] Cc: privacydir@ietf.org Subject: Re: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.txt X-BeenThere: privacydir@ietf.org 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 14:08:20 -0000 That could be true - for example, certain third-party cookies can masquerade as first-party. But privacy is going to be about intent a lot of times, and there will always be those who attempt to circumvent protections. That's why the enforcement piece is so important (as Lorrie has been pointing out).=20 -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=20 Sent: 08 March 2011 13:55 To: Chappelle, Kasey, VF-Group Cc: Ted Hardie; Sean Turner; privacydir@ietf.org Subject: Re: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.txt On 08/03/11 13:31, Chappelle, Kasey, VF-Group wrote: > Good question - perhaps someone with more technical expertise than I > have can help.=20 That'd be good. > But there are lots of reasons why site owners would need > to track their own visitors. Just off the top of my head, where would we > put things like state management? Maintaining shopping carts from page > to page or on subsequent visits, for example, requires you to track a > visitor to your site across pages and sessions.=20 Fair enough. However, I suspect that site owners, (like all of us really) perhaps didn't pay so much attention to privacy in the past, so it could well be that some of those 1st party tracking practices are also privacy-invasive and perhaps not as necessary as they're assumed to be. However, I don't know, so that's why I asked. S. >=20 > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=20 > Sent: 08 March 2011 13:20 > To: Chappelle, Kasey, VF-Group > Cc: Ted Hardie; Sean Turner; privacydir@ietf.org > Subject: Re: [privacydir] Fwd: I-D > ACTION:draft-mayer-do-not-track-00.txt >=20 >=20 >=20 > On 08/03/11 13:14, Chappelle, Kasey, VF-Group wrote: >> Think of all the basic web functions you'd be breaking if first-party > tracking weren't allowed.=20 >=20 > Just wondering. Do we have a good list of those somewhere? >=20 > S. >=20 >> Also consider the very different privacy implications between a party > you've actively engaged with knowing what you're doing while you > interact with them, vs. the third party you have no relationship with. > There's a very real privacy threat here we need to address, but lumping > all tracking together may not be the way to do it. Emerging regulatory > structures around this, even in the most restrictive regimes, have > acknowledged the difference.=20 >> >> Also, anonymous data linked to an individual should and would still be > covered. But what about data collection that occurs without any unique > identifiers at all. The Narayanan papers talk about deanonymization of > individually identifiable data sets. Let's make sure we understand the > full privacy implications in either case before we jump to conclusions - > is frequency-capping actually a privacy-impacting process? I'd say no. >> >> One of the problems of data protection law is that it treats all data > collection similarly, without acknowledging degrees of harm. Let's not > fall into the same trap.=20 >> >> -----Original Message----- >> From: privacydir-bounces@ietf.org [mailto:privacydir-bounces@ietf.org] > On Behalf Of Ted Hardie >> Sent: 08 March 2011 04:15 >> To: Sean Turner >> Cc: privacydir@ietf.org >> Subject: Re: [privacydir] Fwd: I-D > ACTION:draft-mayer-do-not-track-00.txt >> >> 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 >> things. >> >> regards, >> >> Ted Hardie >> >> >> On Mon, Mar 7, 2011 at 6:33 PM, Sean Turner wrote: >>> FYI >>> >>> -------- Original Message -------- >>> Subject: I-D ACTION:draft-mayer-do-not-track-00.txt >>> Date: Mon, 07 Mar 2011 17:45:01 -0800 >>> From: Internet-Drafts@ietf.org >>> Reply-To: internet-drafts@ietf.org >>> To: i-d-announce@ietf.org >>> >>> 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: >>> http://www.ietf.org/internet-drafts/draft-mayer-do-not-track-00.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> 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 >>> privacydir@ietf.org >>> https://www.ietf.org/mailman/listinfo/privacydir >>> >>> >> _______________________________________________ >> privacydir mailing list >> privacydir@ietf.org >> https://www.ietf.org/mailman/listinfo/privacydir >> _______________________________________________ >> privacydir mailing list >> privacydir@ietf.org >> https://www.ietf.org/mailman/listinfo/privacydir >> >=20 From llynch@civil-tongue.net Tue Mar 8 06:59:34 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB6853A68B3 for ; Tue, 8 Mar 2011 06:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.141 X-Spam-Level: X-Spam-Status: No, score=-102.141 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uioVqLb15bAp for ; Tue, 8 Mar 2011 06:59:33 -0800 (PST) Received: from hiroshima.bogus.com (hiroshima.bogus.com [IPv6:2001:418:1::80]) by core3.amsl.com (Postfix) with ESMTP id BA1063A689A for ; Tue, 8 Mar 2011 06:59:32 -0800 (PST) Received: from hiroshima.bogus.com (localhost [127.0.0.1]) by hiroshima.bogus.com (8.14.3/8.14.3) with ESMTP id p28F0kiS039154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 8 Mar 2011 07:00:46 -0800 (PST) (envelope-from llynch@civil-tongue.net) Received: from localhost (llynch@localhost) by hiroshima.bogus.com (8.14.3/8.14.3/Submit) with ESMTP id p28F0khL039151 for ; Tue, 8 Mar 2011 07:00:46 -0800 (PST) (envelope-from llynch@civil-tongue.net) Date: Tue, 8 Mar 2011 07:00:46 -0800 (PST) From: Lucy Lynch X-X-Sender: llynch@hiroshima.bogus.com To: privacydir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.tx X-BeenThere: privacydir@ietf.org 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 14:59:34 -0000 On Tue, 8 Mar 2011, Stephen Farrell wrote: > > > On 08/03/11 13:31, Chappelle, Kasey, VF-Group wrote: >> Good question - perhaps someone with more technical expertise than I >> have can help. > > That'd be good. > >> But there are lots of reasons why site owners would need >> to track their own visitors. Just off the top of my head, where would we >> put things like state management? Maintaining shopping carts from page >> to page or on subsequent visits, for example, requires you to track a >> visitor to your site across pages and sessions. > > Fair enough. However, I suspect that site owners, (like all of > us really) perhaps didn't pay so much attention to privacy in the > past, so it could well be that some of those 1st party tracking > practices are also privacy-invasive and perhaps not as necessary > as they're assumed to be. One of the key arguments I've heard advanced re: first party tracking of authenticated users has to do with fraud prevention. At the recent RSA in San Francisco several panels dealt with user profiling for security, see for example: https://cm.rsaconference.com/US11/catalog/modifySession.do?SESSION_ID=3210&back=true It isn't clear to me how much users know/understand about this kind of data collection and how they would feel about it if they did. It also isn't clear to me if these organizations are out-sourcing the analysis of customer data. This is shaping up as one of the possible counter arguements to do-not-track. - Lucy > However, I don't know, so that's why I asked. > > S. > >> >> -----Original Message----- >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >> Sent: 08 March 2011 13:20 >> To: Chappelle, Kasey, VF-Group >> Cc: Ted Hardie; Sean Turner; privacydir@ietf.org >> Subject: Re: [privacydir] Fwd: I-D >> ACTION:draft-mayer-do-not-track-00.txt >> >> >> >> On 08/03/11 13:14, Chappelle, Kasey, VF-Group wrote: >>> Think of all the basic web functions you'd be breaking if first-party >> tracking weren't allowed. >> >> Just wondering. Do we have a good list of those somewhere? >> >> S. >> >>> Also consider the very different privacy implications between a party >> you've actively engaged with knowing what you're doing while you >> interact with them, vs. the third party you have no relationship with. >> There's a very real privacy threat here we need to address, but lumping >> all tracking together may not be the way to do it. Emerging regulatory >> structures around this, even in the most restrictive regimes, have >> acknowledged the difference. >>> >>> Also, anonymous data linked to an individual should and would still be >> covered. But what about data collection that occurs without any unique >> identifiers at all. The Narayanan papers talk about deanonymization of >> individually identifiable data sets. Let's make sure we understand the >> full privacy implications in either case before we jump to conclusions - >> is frequency-capping actually a privacy-impacting process? I'd say no. >>> >>> One of the problems of data protection law is that it treats all data >> collection similarly, without acknowledging degrees of harm. Let's not >> fall into the same trap. >>> >>> -----Original Message----- >>> From: privacydir-bounces@ietf.org [mailto:privacydir-bounces@ietf.org] >> On Behalf Of Ted Hardie >>> Sent: 08 March 2011 04:15 >>> To: Sean Turner >>> Cc: privacydir@ietf.org >>> Subject: Re: [privacydir] Fwd: I-D >> ACTION:draft-mayer-do-not-track-00.txt >>> >>> 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 >>> things. >>> >>> regards, >>> >>> Ted Hardie >>> >>> >>> On Mon, Mar 7, 2011 at 6:33 PM, Sean Turner wrote: >>>> FYI >>>> >>>> -------- Original Message -------- >>>> Subject: I-D ACTION:draft-mayer-do-not-track-00.txt >>>> Date: Mon, 07 Mar 2011 17:45:01 -0800 >>>> From: Internet-Drafts@ietf.org >>>> Reply-To: internet-drafts@ietf.org >>>> To: i-d-announce@ietf.org >>>> >>>> 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: >>>> http://www.ietf.org/internet-drafts/draft-mayer-do-not-track-00.txt >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> 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 >>>> privacydir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/privacydir >>>> >>>> >>> _______________________________________________ >>> privacydir mailing list >>> privacydir@ietf.org >>> https://www.ietf.org/mailman/listinfo/privacydir >>> _______________________________________________ >>> privacydir mailing list >>> privacydir@ietf.org >>> https://www.ietf.org/mailman/listinfo/privacydir >>> >> > _______________________________________________ > privacydir mailing list > privacydir@ietf.org > https://www.ietf.org/mailman/listinfo/privacydir > From Kasey.Chappelle@vodafone.com Tue Mar 8 07:21:08 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 833F43A68CB for ; Tue, 8 Mar 2011 07:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9g3bALdHiM4 for ; Tue, 8 Mar 2011 07:21:06 -0800 (PST) Received: from mailout01.vodafone.com (mailout01.vodafone.com [195.232.224.70]) by core3.amsl.com (Postfix) with ESMTP id 3AC523A689A for ; Tue, 8 Mar 2011 07:21:06 -0800 (PST) Received: from mailint01 (localhost [127.0.0.1]) by mailout01 (Postfix) with ESMTP id D72814A3D for ; Tue, 8 Mar 2011 16:22:19 +0100 (CET) Received: from avoexs04.internal.vodafone.com (avoexs04.dc-ratingen.de [145.230.4.198]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailint01 (Postfix) with ESMTPS id BB9FD49DA; Tue, 8 Mar 2011 16:22:19 +0100 (CET) Received: from VF-MBX19.internal.vodafone.com ([145.230.5.36]) by avoexs04.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Mar 2011 16:22:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Mar 2011 16:22:18 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.tx Thread-Index: AcvdoaNE0X94E9YBTZ66sRAeMeBLkQAAnFFw References: From: "Chappelle, Kasey, VF-Group" To: "Lucy Lynch" , X-OriginalArrivalTime: 08 Mar 2011 15:22:19.0353 (UTC) FILETIME=[9D4B6490:01CBDDA4] Subject: Re: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.tx X-BeenThere: privacydir@ietf.org 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 15:21:08 -0000 One of the things we've identified a few times in these workstreams as a necessary step is reaching a conclusion about what is and should be "business as usual" online and what has privacy implications. Fraud prevention, content control obligations (like meeting child safety requirements) state management and other basic functions should be outside the scope, but where to draw the lines is key.=20 Several organisations are doing research right now into consumer attitudes, which should definitely drive decisions - what is perceived by the general public as a privacy threat (which it may be important to keep in mind we are not exactly representative of)? -----Original Message----- From: privacydir-bounces@ietf.org [mailto:privacydir-bounces@ietf.org] On Behalf Of Lucy Lynch Sent: 08 March 2011 15:01 To: privacydir@ietf.org Subject: Re: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.tx On Tue, 8 Mar 2011, Stephen Farrell wrote: >=20 >=20 > On 08/03/11 13:31, Chappelle, Kasey, VF-Group wrote: >> Good question - perhaps someone with more technical expertise than I >> have can help. >=20 > That'd be good. >=20 >> But there are lots of reasons why site owners would need >> to track their own visitors. Just off the top of my head, where would we >> put things like state management? Maintaining shopping carts from page >> to page or on subsequent visits, for example, requires you to track a >> visitor to your site across pages and sessions. >=20 > Fair enough. However, I suspect that site owners, (like all of > us really) perhaps didn't pay so much attention to privacy in the > past, so it could well be that some of those 1st party tracking > practices are also privacy-invasive and perhaps not as necessary > as they're assumed to be. One of the key arguments I've heard advanced re: first party tracking of authenticated users has to do with fraud prevention. At the recent RSA in San Francisco several panels dealt with user profiling for security, see for example: https://cm.rsaconference.com/US11/catalog/modifySession.do?SESSION_ID=3D3= 2 10&back=3Dtrue It isn't clear to me how much users know/understand about this kind of data=20 collection and how they would feel about it if they did. It also isn't clear to=20 me if these organizations are out-sourcing the analysis of customer data. This is shaping up as one of the possible counter arguements to do-not-track. - Lucy > However, I don't know, so that's why I asked. >=20 > S. >=20 >>=20 >> -----Original Message----- >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >> Sent: 08 March 2011 13:20 >> To: Chappelle, Kasey, VF-Group >> Cc: Ted Hardie; Sean Turner; privacydir@ietf.org >> Subject: Re: [privacydir] Fwd: I-D >> ACTION:draft-mayer-do-not-track-00.txt >>=20 >>=20 >>=20 >> On 08/03/11 13:14, Chappelle, Kasey, VF-Group wrote: >>> Think of all the basic web functions you'd be breaking if first-party >> tracking weren't allowed. >>=20 >> Just wondering. Do we have a good list of those somewhere? >>=20 >> S. >>=20 >>> Also consider the very different privacy implications between a party >> you've actively engaged with knowing what you're doing while you >> interact with them, vs. the third party you have no relationship with. >> There's a very real privacy threat here we need to address, but lumping >> all tracking together may not be the way to do it. Emerging regulatory >> structures around this, even in the most restrictive regimes, have >> acknowledged the difference. >>>=20 >>> Also, anonymous data linked to an individual should and would still be >> covered. But what about data collection that occurs without any unique >> identifiers at all. The Narayanan papers talk about deanonymization of >> individually identifiable data sets. Let's make sure we understand the >> full privacy implications in either case before we jump to conclusions - >> is frequency-capping actually a privacy-impacting process? I'd say no. >>>=20 >>> One of the problems of data protection law is that it treats all data >> collection similarly, without acknowledging degrees of harm. Let's not >> fall into the same trap. >>>=20 >>> -----Original Message----- >>> From: privacydir-bounces@ietf.org [mailto:privacydir-bounces@ietf.org] >> On Behalf Of Ted Hardie >>> Sent: 08 March 2011 04:15 >>> To: Sean Turner >>> Cc: privacydir@ietf.org >>> Subject: Re: [privacydir] Fwd: I-D >> ACTION:draft-mayer-do-not-track-00.txt >>>=20 >>> I've read this draft, and I think it warrants discussion. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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 >>> things. >>>=20 >>> regards, >>>=20 >>> Ted Hardie >>>=20 >>>=20 >>> On Mon, Mar 7, 2011 at 6:33 PM, Sean Turner wrote: >>>> FYI >>>>=20 >>>> -------- Original Message -------- >>>> Subject: I-D ACTION:draft-mayer-do-not-track-00.txt >>>> Date: Mon, 07 Mar 2011 17:45:01 -0800 >>>> From: Internet-Drafts@ietf.org >>>> Reply-To: internet-drafts@ietf.org >>>> To: i-d-announce@ietf.org >>>>=20 >>>> A new Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>>=20 >>>> >>>> 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 >>>>=20 >>>> 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. >>>>=20 >>>>=20 >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-mayer-do-not-track-00.txt >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> privacydir mailing list >>>> privacydir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/privacydir >>>>=20 >>>>=20 >>> _______________________________________________ >>> privacydir mailing list >>> privacydir@ietf.org >>> https://www.ietf.org/mailman/listinfo/privacydir >>> _______________________________________________ >>> privacydir mailing list >>> privacydir@ietf.org >>> https://www.ietf.org/mailman/listinfo/privacydir >>>=20 >>=20 > _______________________________________________ > privacydir mailing list > privacydir@ietf.org > https://www.ietf.org/mailman/listinfo/privacydir > _______________________________________________ privacydir mailing list privacydir@ietf.org https://www.ietf.org/mailman/listinfo/privacydir From fluffy@cisco.com Tue Mar 8 07:26:27 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EC8E3A687A for ; Tue, 8 Mar 2011 07:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.311 X-Spam-Level: X-Spam-Status: No, score=-110.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-1kVbeVVJZC for ; Tue, 8 Mar 2011 07:26:26 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 789E53A67B7 for ; Tue, 8 Mar 2011 07:26:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1598; q=dns/txt; s=iport; t=1299598061; x=1300807661; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=2OxtdJE/1pkruTOnrsIbFTLkm3Z1GqXSJtZe4DDMNkE=; b=Js7jqASMu+fSBIBbDzCHsWdKpug8+N8FyGeE13ySs6qTv/0hHB1i7iO3 69Ez8rDlvN28OqLhJTfVQSZwB7wOTAYQb1Onni2/QW5Q8uBIsrXwmsi+Q jh3wi9p8qoe7LOicM2J1oAH4F84a2xmu1LOcSmQDotoXe7eVb3ot6rpAO 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABrZdU2rR7Hu/2dsb2JhbACmQHSiapw5hWMEhR2HFYNH X-IronPort-AV: E=Sophos;i="4.62,284,1297036800"; d="scan'208";a="317980795" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 08 Mar 2011 15:27:41 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p28FReSt005740; Tue, 8 Mar 2011 15:27:40 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4D759595.60809@ieca.com> Date: Tue, 8 Mar 2011 08:30:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <77A0C5FA-3F64-40FA-AA7A-23A9CD376685@cisco.com> References: <4D759595.60809@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1082) Cc: privacydir@ietf.org Subject: Re: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.txt X-BeenThere: privacydir@ietf.org 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 15:26:27 -0000 We should probably have this discussion on some open list.=20 On Mar 7, 2011, at 7:33 PM, Sean Turner wrote: > FYI >=20 > -------- Original Message -------- > Subject: I-D ACTION:draft-mayer-do-not-track-00.txt > Date: Mon, 07 Mar 2011 17:45:01 -0800 > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org >=20 > A new Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > 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 >=20 > 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. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mayer-do-not-track-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 > _______________________________________________ > privacydir mailing list > privacydir@ietf.org > https://www.ietf.org/mailman/listinfo/privacydir From ted.ietf@gmail.com Tue Mar 8 07:35:30 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D74663A67A8 for ; Tue, 8 Mar 2011 07:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.525 X-Spam-Level: X-Spam-Status: No, score=-3.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWLIYPLikvsu for ; Tue, 8 Mar 2011 07:35:29 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 29E933A63CB for ; Tue, 8 Mar 2011 07:35:29 -0800 (PST) Received: by qyk29 with SMTP id 29so2750081qyk.10 for ; Tue, 08 Mar 2011 07:36:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QLsTIdswGDVvBv/MnPyXp80SRbUz56UXHe9622O8IxA=; b=VGQ9rdbLfWyDPcjMHqCz4F9uggMfoFzJarN3cChLQNboQeUAFQSVOCwRzHdorIRBym gtLL17pbpdXdkXp6B6MjTralXb0ZEO7iuVFh3XdcKONNhntgdCOyhDABFGB6YxnfYqs0 2b97A9EXUqNkCQJr2e5rqcx4Q9urln9mRkFJg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KOBl0dRg7v3RXoGT5bmdeWEd0fhGJU5w12u17XoaZ8SfYQc2xOtK08M17+hplprw62 QcAFOaJrU3XiiIGlClciHn+Wbf9okDGeAWnnepzbCI1GTlSZexVglIN/5NpnSV6Kw/i3 NXNnI720/pWYnABlChZs4WowvFxUkSkq82rKw= MIME-Version: 1.0 Received: by 10.229.41.70 with SMTP id n6mr2944408qce.252.1299598603623; Tue, 08 Mar 2011 07:36:43 -0800 (PST) Received: by 10.229.11.74 with HTTP; Tue, 8 Mar 2011 07:36:43 -0800 (PST) In-Reply-To: References: <4D759595.60809@ieca.com> Date: Tue, 8 Mar 2011 07:36:43 -0800 Message-ID: From: Ted Hardie To: "Chappelle, Kasey, VF-Group" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: privacydir@ietf.org Subject: Re: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.txt X-BeenThere: privacydir@ietf.org 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 15:35:31 -0000 On Tue, Mar 8, 2011 at 5:14 AM, Chappelle, Kasey, VF-Group wrote: > Think of all the basic web functions you'd be breaking if first-party tra= cking weren't allowed. Also consider the very different privacy implication= s between a party you've actively engaged with knowing what you're doing wh= ile you interact with them, vs. the third party you have no relationship wi= th. There's a very real privacy threat here we need to address, but lumping= all tracking together may not be the way to do it. Emerging regulatory str= uctures around this, even in the most restrictive regimes, have acknowledge= d the difference. > I think your post highlights something important: the line between tracking and maintaining state is very blurred, because the tracking mechanics reuse the mechanics for maintaining state across multiple HTTP requests/responses. A technical user could express this pretty easily: maintain state on my session for no more than N hours. That same technical user could likely say: do not share data on my requests/responses with anyone I have not explicitly listed (with a default list of the fqdn in the link/browser bar). Going from that to useful defaults for the average user is going to be tough, in my opinion, but it starts from user preference rather than site behavior. There are some clear advantages there. > Also, anonymous data linked to an individual should and would still be co= vered. But what about data collection that occurs without any unique identi= fiers at all. The Narayanan papers talk about deanonymization of individual= ly identifiable data sets. Let's make sure we understand the full privacy i= mplications in either case before we jump to conclusions - is frequency-cap= ping actually a privacy-impacting process? I'd say no. > > One of the problems of data protection law is that it treats all data col= lection similarly, without acknowledging degrees of harm. Let's not fall in= to the same trap. > A single bit of information seems to me to force us into that trap; that's one of the reasons I suggested richer semantics are needed. regards, Ted > -----Original Message----- > From: privacydir-bounces@ietf.org [mailto:privacydir-bounces@ietf.org] On= Behalf Of Ted Hardie > Sent: 08 March 2011 04:15 > To: Sean Turner > Cc: privacydir@ietf.org > Subject: Re: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.txt > > 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. =A0Having 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". =A0That 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. > =A0I personally have my doubts. =A0If 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. =A0I 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. =A0As the > two Narayanan papers cited show, anonymized data has been shown to > allow later identification. =A0How 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. =A0If 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. =A0This seems to ask the browser to =A0set 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 > things. > > regards, > > Ted Hardie > > > On Mon, Mar 7, 2011 at 6:33 PM, Sean Turner wrote: >> FYI >> >> -------- Original Message -------- >> Subject: I-D ACTION:draft-mayer-do-not-track-00.txt >> Date: Mon, 07 Mar 2011 17:45:01 -0800 >> From: Internet-Drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> A new Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> =A0 =A0Title =A0 =A0 =A0 =A0 : Do Not Track: A Universal Third-Party Web= Tracking Opt >> Out >> =A0 =A0Author(s) =A0 =A0 : J. Mayer, et al >> =A0 =A0Filename =A0 =A0 =A0: draft-mayer-do-not-track-00.txt >> =A0 =A0Pages =A0 =A0 =A0 =A0 : 6 >> =A0 =A0Date =A0 =A0 =A0 =A0 =A0: 2011-03-07 >> >> This document defines the syntax and semantics of Do Not Track, an >> =A0 HTTP header-based mechanism that enables users to express preference= s >> =A0 about third-party web tracking. =A0It also provides a standard for h= ow >> =A0 web services should comply with such user preferences. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-mayer-do-not-track-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> 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 >> privacydir@ietf.org >> https://www.ietf.org/mailman/listinfo/privacydir >> >> > _______________________________________________ > privacydir mailing list > privacydir@ietf.org > https://www.ietf.org/mailman/listinfo/privacydir > From ted.ietf@gmail.com Tue Mar 8 08:36:14 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00FE33A6923 for ; Tue, 8 Mar 2011 08:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.528 X-Spam-Level: X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcvIqlbPYyWh for ; Tue, 8 Mar 2011 08:36:06 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id AFA513A68F5 for ; Tue, 8 Mar 2011 08:36:05 -0800 (PST) Received: by qyk29 with SMTP id 29so2804688qyk.10 for ; Tue, 08 Mar 2011 08:37:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qQjRNnZoE12Dauv6994kIsOxj11+6qdQ2hzdDQDoQcw=; b=o1PtKipX6kEgUVeUndpgOmGPUnm5k8gnZwk1YRpvM5gWM/xelU1hW9MqJIVf3wDOSo W7iF4ykfWS0cCAa25eM/156Yo4t7bq+OSQjvI7Onlih2TOeV5dsU2GTma0jSTshOOesE DYLp8pNIv/u18IRinpghA9y6Ke6kiwDaliu3E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GFzJeP2X0Pc815YjRqbReaySF+wsmuBAT4b6zeTp4RwAzXTE1E3LnKrtrNDDkkjY91 d9znYMtQ9LJVrvn4SdbqhKL20ikwY5TYfJd01MuGxNTmJqX8s4w3+qSS/R+UKQ6HLMvy DBXdkJCeFYJ9oRBeD4AYk7+a3jsCJ9j63ymlQ= MIME-Version: 1.0 Received: by 10.229.62.198 with SMTP id y6mr4079910qch.290.1299602239363; Tue, 08 Mar 2011 08:37:19 -0800 (PST) Received: by 10.229.11.74 with HTTP; Tue, 8 Mar 2011 08:37:19 -0800 (PST) In-Reply-To: <77A0C5FA-3F64-40FA-AA7A-23A9CD376685@cisco.com> References: <4D759595.60809@ieca.com> <77A0C5FA-3F64-40FA-AA7A-23A9CD376685@cisco.com> Date: Tue, 8 Mar 2011 08:37:19 -0800 Message-ID: From: Ted Hardie To: Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "privacydir@ietf.org" Subject: Re: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.txt X-BeenThere: privacydir@ietf.org 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 16:36:15 -0000 On Tuesday, March 8, 2011, Cullen Jennings wrote: > > We should probably have this discussion on some open list. Fair enough. Which one? Regards, Ted > On Mar 7, 2011, at 7:33 PM, Sean Turner wrote: > >> FYI >> >> -------- Original Message -------- >> Subject: I-D ACTION:draft-mayer-do-not-track-00.txt >> Date: Mon, 07 Mar 2011 17:45:01 -0800 >> From: Internet-Drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> A new Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> >> >> =A0 =A0Title =A0 =A0 =A0 =A0 : Do Not Track: A Universal Third-Party Web= Tracking Opt Out >> =A0 =A0Author(s) =A0 =A0 : J. Mayer, et al >> =A0 =A0Filename =A0 =A0 =A0: draft-mayer-do-not-track-00.txt >> =A0 =A0Pages =A0 =A0 =A0 =A0 : 6 >> =A0 =A0Date =A0 =A0 =A0 =A0 =A0: 2011-03-07 >> >> This document defines the syntax and semantics of Do Not Track, an >> =A0 HTTP header-based mechanism that enables users to express preference= s >> =A0 about third-party web tracking. =A0It also provides a standard for h= ow >> =A0 web services should comply with such user preferences. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-mayer-do-not-track-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> 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 >> privacydir@ietf.org >> https://www.ietf.org/mailman/listinfo/privacydir > > _______________________________________________ > privacydir mailing list > privacydir@ietf.org > https://www.ietf.org/mailman/listinfo/privacydir > From turners@ieca.com Tue Mar 8 08:51:50 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D1D3A6923 for ; Tue, 8 Mar 2011 08:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8m6YultVf9-b for ; Tue, 8 Mar 2011 08:51:48 -0800 (PST) Received: from nm15-vm0.bullet.mail.ne1.yahoo.com (nm15-vm0.bullet.mail.ne1.yahoo.com [98.138.91.70]) by core3.amsl.com (Postfix) with SMTP id 8B6483A68AF for ; Tue, 8 Mar 2011 08:51:48 -0800 (PST) Received: from [98.138.90.53] by nm15.bullet.mail.ne1.yahoo.com with NNFMP; 08 Mar 2011 16:53:00 -0000 Received: from [98.138.88.237] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 08 Mar 2011 16:53:00 -0000 Received: from [127.0.0.1] by omp1037.mail.ne1.yahoo.com with NNFMP; 08 Mar 2011 16:53:00 -0000 X-Yahoo-Newman-Id: 791331.30825.bm@omp1037.mail.ne1.yahoo.com Received: (qmail 66496 invoked from network); 8 Mar 2011 16:53:00 -0000 Received: from thunderfish.local (turners@96.231.129.124 with plain) by smtp113.biz.mail.mud.yahoo.com with SMTP; 08 Mar 2011 08:53:00 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: W5mZs9EVM1nc90atbyVYsT3FCgVzQ0cnlm1g53tD.IcDeLO LobMOjGlo9_TvH4jJ.F6twVc2gplHknCwKuBe0CGtP4IBaXhTplgHJJxGi_H yXISAkb4FvYrea.HM1cIveY6HoTs7B0_oU.rOMPP_GFdxwU926WRi96WLuUA .429PGKCB_j4sP.LVirbbo4tqnOyxcRIzhWgqHXnjxcXpR2miPJlezDW9RUJ aRjhw46LYoxiQPqeU8.gd17HmyF62F2IFQbv0CIZsgpkpC2eDAk2cxQ.Ess. 3xTUDz6NsQlZEaax0JnLr3C3G1QSHSk4pJz1VHoJ7T9wp X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D765EEA.5070901@ieca.com> Date: Tue, 08 Mar 2011 11:52:58 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Ted Hardie References: <4D759595.60809@ieca.com> <77A0C5FA-3F64-40FA-AA7A-23A9CD376685@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "privacydir@ietf.org" Subject: Re: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.txt X-BeenThere: privacydir@ietf.org 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 16:51:50 -0000 How about websec? spt On 3/8/11 11:37 AM, Ted Hardie wrote: > On Tuesday, March 8, 2011, Cullen Jennings wrote: >> >> We should probably have this discussion on some open list. > > > Fair enough. Which one? > > > Regards, > > Ted >> On Mar 7, 2011, at 7:33 PM, Sean Turner wrote: >> >>> FYI >>> >>> -------- Original Message -------- >>> Subject: I-D ACTION:draft-mayer-do-not-track-00.txt >>> Date: Mon, 07 Mar 2011 17:45:01 -0800 >>> From: Internet-Drafts@ietf.org >>> Reply-To: internet-drafts@ietf.org >>> To: i-d-announce@ietf.org >>> >>> 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: >>> http://www.ietf.org/internet-drafts/draft-mayer-do-not-track-00.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> 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 >>> privacydir@ietf.org >>> https://www.ietf.org/mailman/listinfo/privacydir >> >> _______________________________________________ >> privacydir mailing list >> privacydir@ietf.org >> https://www.ietf.org/mailman/listinfo/privacydir >> > From acooper@cdt.org Wed Mar 9 02:00:30 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8350C3A68EB for ; Wed, 9 Mar 2011 02:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0rSq97i+aOa for ; Wed, 9 Mar 2011 02:00:29 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id 6695D3A67F1 for ; Wed, 9 Mar 2011 02:00:29 -0800 (PST) Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Wed, 9 Mar 2011 05:01:33 -0500 Message-Id: <142738D3-B12D-41AC-A3E4-CD19D47C89F9@cdt.org> From: Alissa Cooper To: Sean Turner In-Reply-To: <4D765EEA.5070901@ieca.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 9 Mar 2011 05:01:18 -0500 References: <4D759595.60809@ieca.com> <77A0C5FA-3F64-40FA-AA7A-23A9CD376685@cisco.com> <4D765EEA.5070901@ieca.com> X-Mailer: Apple Mail (2.936) Cc: "privacydir@ietf.org" Subject: Re: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.txt X-BeenThere: privacydir@ietf.org 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: Wed, 09 Mar 2011 10:00:30 -0000 Or maybe ietf-privacy? Not sure which is better, but there may be some folks new to the IETF who are primarily interested in this draft and not the rest of what is going on in websec. On Mar 8, 2011, at 11:52 AM, Sean Turner wrote: > How about websec? > > spt > > On 3/8/11 11:37 AM, Ted Hardie wrote: >> On Tuesday, March 8, 2011, Cullen Jennings wrote: >>> >>> We should probably have this discussion on some open list. >> >> >> Fair enough. Which one? >> >> >> Regards, >> >> Ted >>> On Mar 7, 2011, at 7:33 PM, Sean Turner wrote: >>> >>>> FYI >>>> >>>> -------- Original Message -------- >>>> Subject: I-D ACTION:draft-mayer-do-not-track-00.txt >>>> Date: Mon, 07 Mar 2011 17:45:01 -0800 >>>> From: Internet-Drafts@ietf.org >>>> Reply-To: internet-drafts@ietf.org >>>> To: i-d-announce@ietf.org >>>> >>>> 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: >>>> http://www.ietf.org/internet-drafts/draft-mayer-do-not-track-00.txt >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>>> >>>> >>> Part.txt>_______________________________________________ >>>> privacydir mailing list >>>> privacydir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/privacydir >>> >>> _______________________________________________ >>> privacydir mailing list >>> privacydir@ietf.org >>> https://www.ietf.org/mailman/listinfo/privacydir >>> >> > _______________________________________________ > privacydir mailing list > privacydir@ietf.org > https://www.ietf.org/mailman/listinfo/privacydir > From acooper@cdt.org Thu Mar 10 12:54:16 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12EA93A699C; Thu, 10 Mar 2011 12:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTrnyuZcPLoU; Thu, 10 Mar 2011 12:54:15 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id 9E47E3A67F8; Thu, 10 Mar 2011 12:54:14 -0800 (PST) Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Thu, 10 Mar 2011 15:55:26 -0500 Message-Id: From: Alissa Cooper To: Ted Hardie In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 10 Mar 2011 15:55:15 -0500 References: <4D759595.60809@ieca.com> X-Mailer: Apple Mail (2.936) Cc: privacydir@ietf.org, ietf-privacy@ietf.org Subject: Re: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.txt X-BeenThere: privacydir@ietf.org 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: Thu, 10 Mar 2011 20:54:16 -0000 (Moving this to ietf-privacy@ietf.org. I suggest future responses drop privacydir@ietf.org .) Hi Ted, couple responses inline -- On Mar 7, 2011, at 11:14 PM, Ted Hardie wrote: > 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. I would suggest that the proposal in this draft be viewed as an attempt at incremental change. We start with one bit, which has the potential to be an improvement over the status quo. It doesn't foreclose having additional bits in the future. But even standardizing the one bit and getting people to honor it would be a significant improvement IMO. > > 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. I don't think the draft expects that there is a simple line to draw between first and third parties. Indeed, section 9.1 reveals some of the complexity involved in making this distinction. But just because it's hard doesn't mean that it's impossible. One way that CDT has thought about tackling this one is by branding: entities with common branding are considered to be the same party, whereas entities with different branding are different parties [1]. This makes the distinction subjective and not based on public suffix/ FQDN/anything else observable by a UA, but it tries to match user expectation. > > 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 would again be thinking about this incrementally -- right now some opting out of tracking for some services doesn't even result in any de- identification. If this proposal can serve to reduce the identifiability of opted out users, even if it does not eliminate all identifiable data stored about them, I think that would be a positive step. > > 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 > things. I would hope that one of the benefits of standardization here would be to build out the specificity of the semantic. Alissa > > regards, > > Ted Hardie > > > On Mon, Mar 7, 2011 at 6:33 PM, Sean Turner wrote: >> FYI >> >> -------- Original Message -------- >> Subject: I-D ACTION:draft-mayer-do-not-track-00.txt >> Date: Mon, 07 Mar 2011 17:45:01 -0800 >> From: Internet-Drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> 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: >> http://www.ietf.org/internet-drafts/draft-mayer-do-not-track-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> 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 >> privacydir@ietf.org >> https://www.ietf.org/mailman/listinfo/privacydir >> >> > _______________________________________________ > privacydir mailing list > privacydir@ietf.org > https://www.ietf.org/mailman/listinfo/privacydir > From ted.ietf@gmail.com Thu Mar 10 14:08:33 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 614E23A6A79; Thu, 10 Mar 2011 14:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.536 X-Spam-Level: X-Spam-Status: No, score=-3.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiidJXvIr7I5; Thu, 10 Mar 2011 14:08:32 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id B24843A6AD4; Thu, 10 Mar 2011 14:08:31 -0800 (PST) Received: by qyk7 with SMTP id 7so1823836qyk.10 for ; Thu, 10 Mar 2011 14:09:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CUythx61ogtIBXaK3oCCksyGug7vkXONBZCBPwEvv6M=; b=xTNkfB8ouKt1sWkjpox9IIQ0mvfYWn79hfciWkJkm0b4wH5gy5fKecPRyCsLpuUKzS jQlDeQgLCSnVqXEyxBnuQxF+mLaoqFLZjP6I9uGIpGpelbe7ILYwqgfq42e5LiAPtyn5 ChTTW0tpsG39bdKDbsGrf6LoCgeZFmhZgdiDU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=sZ0V8zq9mjsStAtJueLXTIucAJDQ24ZFZc6yy+yMzOMhkFhWHU4Jaz7XwUhO8jy8Kh l63MSPoIk3go/qr4PD1Zqn+AE8SLEa7/hQOdnVMxwpXTdHejKt/sMrp350NxNXNjI1zB 0aUCOqDtX1wSOL0fh38+RFtSAdjZbdu3qQdcM= MIME-Version: 1.0 Received: by 10.229.62.198 with SMTP id y6mr6784652qch.290.1299794989613; Thu, 10 Mar 2011 14:09:49 -0800 (PST) Received: by 10.229.11.74 with HTTP; Thu, 10 Mar 2011 14:09:49 -0800 (PST) In-Reply-To: References: <4D759595.60809@ieca.com> Date: Thu, 10 Mar 2011 14:09:49 -0800 Message-ID: From: Ted Hardie To: Alissa Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: privacydir@ietf.org, ietf-privacy@ietf.org Subject: Re: [privacydir] Fwd: I-D ACTION:draft-mayer-do-not-track-00.txt X-BeenThere: privacydir@ietf.org 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: Thu, 10 Mar 2011 22:08:33 -0000 Hi Alissa, Dropping privacydir, as requested. Some further discussion in-line. On Thu, Mar 10, 2011 at 12:55 PM, Alissa Cooper wrote: > (Moving this to ietf-privacy@ietf.org. I suggest future responses drop > privacydir@ietf.org.) > > Hi Ted, couple responses inline -- > > On Mar 7, 2011, at 11:14 PM, Ted Hardie wrote: > >> 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. =A0Having additional >> bits which describe user preferences around tracking by first parties >> seems to me necessary. > > I would suggest that the proposal in this draft be viewed as an attempt a= t > incremental change. We start with one bit, which has the potential to be = an > improvement over the status quo. It doesn't foreclose having additional b= its > in the future. But even standardizing the one bit and getting people to > honor it would be a significant improvement IMO. > First, web headers tend to be chatty ascii things, and using an opaque single bit rather than a semantically useful statement seems to me a poor optimization choice. Second, if you are expecting extensibility, you need to be really sure that the initial choices don't seem to exclude it; these, at least to me, do. >> >> 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". =A0That 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. =A0If 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. =A0I 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. > > I don't think the draft expects that there is a simple line to draw betwe= en > first and third parties. Indeed, section 9.1 reveals some of the complexi= ty > involved in making this distinction. But just because it's hard doesn't m= ean > that it's impossible. > But this is absolutely critical. If someone including a single pixel image gets to be treated as a first party, *any* mechanism based on third party tracking is toothless. > One way that CDT has thought about tackling this one is by branding: > entities with common branding are considered to be the same party, wherea= s > entities with different branding are different parties [1]. This makes th= e > distinction subjective and not based on public suffix/FQDN/anything else > observable by a UA, but it tries to match user expectation. > How does the protocol detect the brand? cnn.caching-cdn.com is branded in a way to allow it to share cookies with .cnn.com? >> >> I also find the exception for data which is "not linkable to a >> specific user or user agent" somewhat hard to work through. =A0As the >> two Narayanan papers cited show, anonymized data has been shown to >> allow later identification. =A0How 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 would again be thinking about this incrementally -- right now some opti= ng > out of tracking for some services doesn't even result in any > de-identification. If this proposal can serve to reduce the identifiabili= ty > of opted out users, even if it does not eliminate all identifiable data > stored about them, I think that would be a positive step. > >> >> I have the haunting feeling that starting from this position is >> inherently weak. =A0If 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. =A0This seems to ask the browser to =A0set a "Don't be evil" bi= t >> on its requests, but to leave the real control over what that means so >> underspecified that reasonable people could conclude wildly different >> things. > > I would hope that one of the benefits of standardization here would be to > build out the specificity of the semantic. I think this argues for a much richer semantic than a single bit then, especially when third and first party entities are hard to tease apart. It is much easier to know what is desired if you say: know this: I want a maximally private interaction--don't store, share, or analyze this interaction except as needed to maintain state know this: I'm okay with you doing anything with the data I provide you know this: I'm okay with you keeping my data "live" for up to 24 hours so I can pick up where I left off; I'm okay with you sharing data I gave you with a financial institution I name in purchases; I'm okay with you sharing my data as part of your analysis of purchase patterns, provided my name, address, customer number, and financial identifiers are removed; I'm okay with you sharing my data with other parties you own, but not with other parties you pay for services. The effect of a 3rd party "Do not track" clearly isn't the first in your draft, but where it falls between the 2nd and the 3rd is not yet clear, because the server has to infer to much from a single bit. If the server's organization as a first party does all the work, they can do *anything* according to this proposal. Somehow I doubt that's what the naive user will think happens when there UI asks them whether to turn on "Do not Track". regards, Ted Hardie > > Alissa > >> >> regards, >> >> Ted Hardie >> >> >> On Mon, Mar 7, 2011 at 6:33 PM, Sean Turner wrote: >>> >>> FYI >>> >>> -------- Original Message -------- >>> Subject: I-D ACTION:draft-mayer-do-not-track-00.txt >>> Date: Mon, 07 Mar 2011 17:45:01 -0800 >>> From: Internet-Drafts@ietf.org >>> Reply-To: internet-drafts@ietf.org >>> To: i-d-announce@ietf.org >>> >>> A new Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> =A0 Title =A0 =A0 =A0 =A0 : Do Not Track: A Universal Third-Party Web T= racking Opt >>> Out >>> =A0 Author(s) =A0 =A0 : J. Mayer, et al >>> =A0 Filename =A0 =A0 =A0: draft-mayer-do-not-track-00.txt >>> =A0 Pages =A0 =A0 =A0 =A0 : 6 >>> =A0 Date =A0 =A0 =A0 =A0 =A0: 2011-03-07 >>> >>> This document defines the syntax and semantics of Do Not Track, an >>> =A0HTTP header-based mechanism that enables users to express preference= s >>> =A0about third-party web tracking. =A0It also provides a standard for h= ow >>> =A0web services should comply with such user preferences. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-mayer-do-not-track-00.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> 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 >>> privacydir@ietf.org >>> https://www.ietf.org/mailman/listinfo/privacydir >>> >>> >> _______________________________________________ >> privacydir mailing list >> privacydir@ietf.org >> https://www.ietf.org/mailman/listinfo/privacydir >> > > > From rbarnes@bbn.com Mon Mar 14 07:59:43 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 431E83A6DB5 for ; Mon, 14 Mar 2011 07:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqpKamoHsZp7 for ; Mon, 14 Mar 2011 07:59:41 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 8AD2C3A6905 for ; Mon, 14 Mar 2011 07:59:41 -0700 (PDT) Received: from ros-dhcp192-1-51-74.bbn.com ([192.1.51.74]:63029) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Pz9Ga-000LbN-O0 for privacydir@ietf.org; Mon, 14 Mar 2011 11:01:04 -0400 From: "Richard L. Barnes" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Mar 2011 11:01:02 -0400 References: <20110314140714.27464.79616.idtracker@localhost> To: privacydir@ietf.org Message-Id: <7A16A5B2-18FE-49CE-B2D7-E7CDBEFFDC56@bbn.com> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [privacydir] Fwd: Document Action: 'IP Flow Anonymization Support' to Experimental RFC (draft-ietf-ipfix-anon-06.txt) X-BeenThere: privacydir@ietf.org 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: Mon, 14 Mar 2011 14:59:43 -0000 FYI Begin forwarded message: > From: The IESG > Date: March 14, 2011 10:07:14 AM EDT > To: IETF-Announce > Cc: Internet Architecture Board , ipfix chair = , ipfix mailing list , RFC = Editor > Subject: Document Action: 'IP Flow Anonymization Support' to = Experimental RFC (draft-ietf-ipfix-anon-06.txt) >=20 > The IESG has approved the following document: > - 'IP Flow Anonymization Support' > (draft-ietf-ipfix-anon-06.txt) as an Experimental RFC >=20 > This document is the product of the IP Flow Information Export Working > Group. >=20 > The IESG contact persons are Dan Romascanu and Ron Bonica. >=20 > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-ipfix-anon/ >=20 >=20 >=20 >=20 > Technical Summary >=20 > This document describes anonymisation techniques for IP flow data = and > the export of anonymised data using the IPFIX protocol. It > categorizes common anonymisation schemes and defines the parameters > needed to describe them. It provides guidelines for the > implementation of anonymised data export and storage over IPFIX, and > describes an information model and Options-based method for > anonymisation metadata export within the IPFIX protocol or storage = in > IPFIX Files >=20 > Working Group Summary >=20 > This draft was initiated by WG members from ETH Zurich, and > reviewed by other members, mostly European, who have similar = research > interests. Although this seems a somewhat complicated way to = transmit > and store anonymised data, it is believed to be a significant step = towards > a common way to carry metadata about how the > anonymisation was done along with the data itself. Although there = was > considerable discussion within the working group, consensus was > reached without any problems. >=20 > Document Quality >=20 > This is an Experimental document, intended for the Network Research = and > Network Security communities. It is submitted as an Experimental > document as a way of encouraging multiple implementations, > in order to gain experience with it. When sufficient experience = will be gained > with this, it mahy be brought back to the Working Group to be = considered > as a new Standards Track work item. >=20 > Personnel >=20 > Nevil Brownlee is the Document Shepherd. Dan Romascanu is the=20 > Responsible Area Director. > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From turners@ieca.com Mon Mar 14 11:47:21 2011 Return-Path: X-Original-To: privacydir@core3.amsl.com Delivered-To: privacydir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E62C3A6A31 for ; Mon, 14 Mar 2011 11:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pz2ABzaxjCin for ; Mon, 14 Mar 2011 11:47:20 -0700 (PDT) Received: from nm25.bullet.mail.ne1.yahoo.com (nm25.bullet.mail.ne1.yahoo.com [98.138.90.88]) by core3.amsl.com (Postfix) with SMTP id DF70A3A6E24 for ; Mon, 14 Mar 2011 11:47:08 -0700 (PDT) Received: from [98.138.90.52] by nm25.bullet.mail.ne1.yahoo.com with NNFMP; 14 Mar 2011 18:48:32 -0000 Received: from [98.138.89.240] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 14 Mar 2011 18:48:32 -0000 Received: from [127.0.0.1] by omp1013.mail.ne1.yahoo.com with NNFMP; 14 Mar 2011 18:48:32 -0000 X-Yahoo-Newman-Id: 698085.22272.bm@omp1013.mail.ne1.yahoo.com Received: (qmail 23122 invoked from network); 14 Mar 2011 18:48:32 -0000 Received: from thunderfish.local (turners@96.231.119.32 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 14 Mar 2011 11:48:32 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: NoQibc4VM1nNDGRi2sR15nhca5BQHNdDB4h2BcX.0c7sv1z rH8sC1BDxDamKrgjK.CiQz3iaNAhmuBifRqq6gRyCLlUQTHZJVH1nWACmxEU FNewb.Yc_7P_gVsk2kBoJ1SqzeJWGLWF8cdLlsTJTVkHBAdKmQjM5iwn1LFk MXITWBIIuRS5.HPXzVTTUcNQpuLVLiFfTq.VvsNXs7cE_HDgWz0ikEuLVUx6 BTvhWdaGoN_3mh2igPt6xZ_XzRUh06pmop3fU2LlOwJEvPxGiDXmAXC1qOIS Qcqy5c6Bqgr5h6Y4eb0363GbnpyJfe8P.aw33ljdU_UUIBAzHWFPeRD0J1dY waTzH42fVOuFsJdW7wVVRQwV2d4WcFiuZNdCU66cAOg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D7E62FF.3030807@ieca.com> Date: Mon, 14 Mar 2011 14:48:31 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: privacydir@ietf.org References: <20110314140714.27464.79616.idtracker@localhost> <7A16A5B2-18FE-49CE-B2D7-E7CDBEFFDC56@bbn.com> In-Reply-To: <7A16A5B2-18FE-49CE-B2D7-E7CDBEFFDC56@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [privacydir] Fwd: Document Action: 'IP Flow Anonymization Support' to Experimental RFC (draft-ietf-ipfix-anon-06.txt) X-BeenThere: privacydir@ietf.org 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: Mon, 14 Mar 2011 18:47:21 -0000 So they made extensive changes based on comments I passed through from this list. It's an experimental protocol so if they come back around again we'll get another hack at them. I didn't want to hold them up from starting their experiment ;) spt On 3/14/11 11:01 AM, Richard L. Barnes wrote: > FYI > > Begin forwarded message: > >> From: The IESG >> Date: March 14, 2011 10:07:14 AM EDT >> To: IETF-Announce >> Cc: Internet Architecture Board, ipfix chair, ipfix mailing list, RFC Editor >> Subject: Document Action: 'IP Flow Anonymization Support' to Experimental RFC (draft-ietf-ipfix-anon-06.txt) >> >> The IESG has approved the following document: >> - 'IP Flow Anonymization Support' >> (draft-ietf-ipfix-anon-06.txt) as an Experimental RFC >> >> This document is the product of the IP Flow Information Export Working >> Group. >> >> The IESG contact persons are Dan Romascanu and Ron Bonica. >> >> A URL of this Internet Draft is: >> http://datatracker.ietf.org/doc/draft-ietf-ipfix-anon/ >> >> >> >> >> Technical Summary >> >> This document describes anonymisation techniques for IP flow data and >> the export of anonymised data using the IPFIX protocol. It >> categorizes common anonymisation schemes and defines the parameters >> needed to describe them. It provides guidelines for the >> implementation of anonymised data export and storage over IPFIX, and >> describes an information model and Options-based method for >> anonymisation metadata export within the IPFIX protocol or storage in >> IPFIX Files >> >> Working Group Summary >> >> This draft was initiated by WG members from ETH Zurich, and >> reviewed by other members, mostly European, who have similar research >> interests. Although this seems a somewhat complicated way to transmit >> and store anonymised data, it is believed to be a significant step towards >> a common way to carry metadata about how the >> anonymisation was done along with the data itself. Although there was >> considerable discussion within the working group, consensus was >> reached without any problems. >> >> Document Quality >> >> This is an Experimental document, intended for the Network Research and >> Network Security communities. It is submitted as an Experimental >> document as a way of encouraging multiple implementations, >> in order to gain experience with it. When sufficient experience will be gained >> with this, it mahy be brought back to the Working Group to be considered >> as a new Standards Track work item. >> >> Personnel >> >> Nevil Brownlee is the Document Shepherd. Dan Romascanu is the >> Responsible Area Director. >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce > > _______________________________________________ > privacydir mailing list > privacydir@ietf.org > https://www.ietf.org/mailman/listinfo/privacydir >