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

Other options to consider: we could identify privacy policy notification as a best practice, rather than a MUST requirement. We could also have it as a SHOULD requirement, with a note that we understand this may not work for all groups in all jurisdictions and the implementers should consult a lawyer if they need legal advice.

[To be clear, I'm not suggesting any of these, I am just reminding the group that we have more leeway and flexibility in how we express things.]

	Aleecia

On Oct 26, 2011, at 11:26 AM, Matthias Schunter wrote:

> Hi Justin/David,
> 
> 
> I personally  believe that posting privacy policies is current best
> practices and I like to see all companies doing so.
> 
> Nevertheless, I believe that it is not our mission to mandate this.
> 
> Consequences:
> - We may define a mechanism where a URL to a human-readable
> text/policy that
>   describes the practices  MAY be transmitted.
> - This may support transparency if so desired by a site.
> - I agree with David that we should not mandate that enterprises provide
>  such a URL
> - Whether to have  a privacy policy and how to transmit it is part of
> their
>   business design/decisions and may be covered by existing or
>   upcoming legislation.
> 
> 
> Regards,
> matthias
> 
> 
> -------- Original Message --------
> Subject: 	Re: Propose to drop from the strawman: requirement for
> privacy policy disclosure
> Resent-Date: 	Wed, 26 Oct 2011 17:50:28 +0000
> Resent-From: 	public-tracking@w3.org
> Date: 	Wed, 26 Oct 2011 13:49:46 -0400
> From: 	David Wainberg <dwainberg@appnexus.com>
> To: 	Justin Brookman <justin@cdt.org>
> CC: 	public-tracking@w3.org <public-tracking@w3.org>
> 
> 
> 
> A statement in a privacy policy is per se a legal statement. It is a
> legal and political issue, the effects of which may vary from
> jurisdiction to jurisdiction. I'm not sure we can say whether it
> creates any additional liability for a network, much less what that
> liability might be.
> 
> More important to me is a bigger picture conceptual issue about what
> this group and standard can accomplish. In my view this is not the
> right venue for making legal or other requirements with regard to a
> company's business practices beyond the technical implementation of
> the standard and the collection and use of relevant data. I think it
> should be enough for this group to provide the framework and leave
> these other issues to other entities, probably on a jurisdiction by
> jurisdiction basis.
> 
> On 10/26/11 11:53 AM, Justin Brookman wrote:
>> 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.
> 
>

Received on Wednesday, 26 October 2011 22:40:29 UTC