- From: Shane Wiley <wileys@yahoo-inc.com>
- Date: Wed, 26 Oct 2011 09:35:03 -0700
- To: Ninja Marnau <nmarnau@datenschutzzentrum.de>, "public-tracking@w3.org" <public-tracking@w3.org>
Agreed - I mean to state the URI should be sent with all responses. -----Original Message----- From: public-tracking-request@w3.org [mailto:public-tracking-request@w3.org] On Behalf Of Ninja Marnau Sent: Wednesday, October 26, 2011 9:19 AM To: public-tracking@w3.org Subject: Re: Propose to drop from the strawman: requirement for privacy policy disclosure I support the simplification of a mandatory response. I just want to add that response no. 2 might also need the option to learn more for the user. The exceptions we define seem to be quite various. Am 26.10.2011 18:03, schrieb Shane Wiley: > I believe it is in the best interest of > consumers/users/citizens/visitors/data subjects that a human-readable > explanation be provided to "learn more" about what and how an > organization honors DNT - AND I believe this would allow us to greatly > simplify the response options to the few I previously outlined. > > *Basic Response:* > > 0 - Server did not receive DNT header > > 1 - Server received DNT header and will honor it > > 2 - Server received DNT header and will not honor it due to previous > exception > > 3 - Server received DNT header and will not honor it due to some other > reason (see URI) > > *URI: *Learn More** > > - Shane > > *From:*public-tracking-request@w3.org > [mailto:public-tracking-request@w3.org] *On Behalf Of *Justin Brookman > *Sent:* Wednesday, October 26, 2011 8:53 AM > *To:* public-tracking@w3.org > *Subject:* Re: Propose to drop from the strawman: requirement for > privacy policy disclosure > > Given that you acknowledge that a response header and/or > machine-readable file also create an actionable hook for enforcement, I > don't understand the resistance to a human-readable statement that does > not rely on a user agent to interpret (apart from rendering the web > page). It does not create any additional liability on the part of the > network. As I said, I suppose I could live with an acknowledgement > elsewhere as long as there was some sort of mandated response SOMEWHERE, > but it's better from a user perspective if there's also a place to go to > find out in plain English if the company is complaint with this spec, > and I don't see why this is a heavy lift. > > Justin Brookman > > Director, Consumer Privacy Project > > Center for Democracy& Technology > > 1634 I Street NW, Suite 1100 > > Washington, DC 20006 > > tel 202.407.8812 > > fax 202.637.0969 > > justin@cdt.org <mailto:justin@cdt.org> > > http://www.cdt.org > > @CenDemTech > > @JustinBrookman > > > On 10/26/2011 11:23 AM, David Wainberg wrote: > > I totally support verifiability and accountability. However, I do not > think this standard has to accomplish both, but rather can provide the > tools to do so. > The standard will be released into a larger context. It is not this > group's or the W3C's role, in my opinion, to create a regulatory regime > for online advertising. It is out of scope to create legal requirements > as part of the standard. A flag in the header, or a machine readable > file in a well-known location are logical technical additions to the > spec, that would provide useful feedback to users/clients, and would > support the efforts of relevant authorities to do enforcement. > > One other thing I want to clarify. You said, "the spec needs to lay out > how to communicate to consumers that the header is being respected." I > disagree. The spec can lay out a technical means to communicate that an > entity intends to respect the header. There is no way to communicate > whether it is actually respected. (This is an important distinction, in > my view, because it goes to evaluating proposals for responses.) > > On 10/25/11 5:50 PM, Justin Brookman wrote: > > A lot of this effort is dedicated to verifiability --- isn't that why > we've spent so much time discussing the sending of compliance headers? > Having an accountable statement of compliance is another effort at that. > > I suppose you could make an argument that it should be in the > technical spec instead of the compliance spec (though I would > disagree), but especially if third-party header responses are deemed > optional or a Bad Idea, the spec needs to lay out how to communicate > to consumers that the header is being respected. > > If the header just flies into the blue with no standardized way to > disclose compliance, this process seems destined to fail; if nothing > else, privacy policy disclosure should be considered as an > alternative to automated header responses. > > Justin Brookman > > Director, Consumer Privacy Project > > Center for Democracy& Technology > > 1634 I Street NW, Suite 1100 > > Washington, DC 20006 > > tel 202.407.8812 > > fax 202.637.0969 > > justin@cdt.org <mailto:justin@cdt.org> > > http://www.cdt.org > > @CenDemTech > > @JustinBrookman > > > On 10/25/2011 5:16 PM, David Wainberg wrote: > > Section 6.4 of the Compliance and Scope document states, "In order > to be compliant with this specification, an operator of a > third-party domain must clearly and unambiguously assert in the > privacy policy governing that domain that it is in compliance with > this specification." Such a requirement is out of scope of this > standard and should not be included in the strawman. While it may be > in scope to create tools that facilitate auditing and enforcement by > other entities, it is not the role of this technical standard to > impose legal requirements for compliance. Any such requirements will > come from entities with relevant authority, e.g. Congress or the FTC > in the US. > -- Ninja Marnau mail: NMarnau@datenschutzzentrum.de - http://www.datenschutzzentrum.de Telefon: +49 431/988-1285, Fax +49 431/988-1223 Unabhaengiges Landeszentrum fuer Datenschutz Schleswig-Holstein Independent Centre for Privacy Protection Schleswig-Holstein
Received on Wednesday, 26 October 2011 16:35:42 UTC