RE: Propose to drop from the strawman: requirement for privacy policy disclosure

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