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
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
>> 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.