Re: simple, standardized privacy policy discovery

On Aug 20, 2013, at 12:48 , frederick.hirsch@nokia.com wrote:

> Some time ago the Device APIs WG explored the possibility of combining privacy choices (e.g. retention, reuse etc) into "rulesets" - a similar idea, but in a different context of web applications [1].
> 
> I think the idea has merit in general, allowing well-defined choices to limit complexity and definition ambiguity, with a possible additional step of creating bundled sets of choices to further enable usability.
> 
> The issue I remember from workshops is that lawyers generally wish to add specific and detailed exceptions and conditions etc to address risks and concerns, and this approach would not enable that.

Yes.  One choice for each category would have to be 'custom' (we write our own), and a policy that has lots of 'custom' paragraphs would then be harder to understand.  They'd probably want an 'in addition' section, as well (things not covered by the standard categories).

The problem with the approach is the amount of work needed to get going.

1) Assemble a reasonable corpus of privacy policies.
2) Chunk them up into sections, categorized by subject.
3) Find common themes, and so on, that the bulk of them are using; re-write those in 'common language', and form the set of 'standard clauses'.
4) Go back to the original corpus, and do the rewrite 'what-if': if the standard clauses exist, how could these policies be rewritten to use/refer-to them?

A lot of work.

> 
> regards, Frederick
> 
> Frederick Hirsch
> Nokia
> 
> [1] http://dev.w3.org/2009/dap/privacy-rulesets/
> 
> On Aug 20, 2013, at 12:31 PM, ext David Singer wrote:
> 
>> Thanks Nick
>> 
>> one idea that came up at a workshop was related to, and would support, Ashkan Solnati's privacys icons.  The idea was that some organization (e.g. the W3C) publish a set of sections of text that represent common statements on various aspects of privacy policy.  For example, there might be 3 alternative sections dealing with "disclosure to law-enforcement" -- Strict (we disclose only when legally mandated to do so), Moderate (we also disclose when we feel it would be best to do so), Lenient (we respond to all requests from law enforcement organizations).
>> 
>> The hope was that an organization could put together 90+% of their policy by reference.  
>> 
>> "Our choices are:
>> a) law-enforcement: W3C Strict
>> b) Third-party: W3C affiliates-only
>> c) …
>> "
>> 
>> Whether this would fly I am not sure.  Given a limited set of choices in each category, comprehensibility for the end-user would rise (and icons might become possible, if combined with a well-known-resource of some type).
>> 
>> 
>> On Aug 19, 2013, at 19:08 , Nicholas Doty <npdoty@w3.org> wrote:
>> 
>>> The difficulties in finding privacy policies for Web sites are occasionally mentioned. I've heard this raised as an issue for:
>>> * end users, who may not want to dig around for a privacy policy link on a Web page
>>> * end users on mobile devices, for whom finding and following links can be particularly difficult
>>> * researchers, who might be crawling or analyzing privacy policies to study en masse
>>> * civil society, who may want to provide automated comparison, versioning or analysis of privacy policies
>>> 
>>> While discovery of a human-readable privacy policy is a very limited part of the general problems our industry has encountered with long-form privacy policies on the Web, standardized discovery protocols would contribute to a variety of use cases and could facilitate some larger scale solutions (short notices, privacy icons, registries, etc.).
>>> 
>>> I don't claim to know every proposal in this area, but here are a few that address the very specific question of discovery of human-readable privacy policies that apply to a particular Web page. (Apologies if I'm repeating an incomplete collection that has already been gathered somewhere else.)
>>> 
>>> 1. P3P discuri attribute  
>>> http://www.w3.org/TR/P3P/#POLICY
>>> A mandatory discuri on every <policy> element in an XML P3P policy gave a full URI for a human-readable version of the privacy policy. This is implemented now, for example, by Yahoo! and Microsoft. P3P policies are discoverable in a defined way (well-known URI, Link header, link tag) and then the <policy> element can be parsed to find the human-readable version.
>>> 
>>> 2. DNT Tracking Status Resource   
>>> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#status-resource
>>> An optional element of a site-wide tracking status resource (itself discovered through a well-known URI or response header) is a JSON policy field which points to a human-readable policy, though this is suggested to be specific to the kind of tracking relevant to a DNT preference. That document is currently a draft and I don't know offhand of any in-the-wild implementations of this section.
>>> 
>>> 3. A "privacy-policy" or "terms-of-service" Link relation    
>>> http://tools.ietf.org/html/rfc6903
>>> RFC 6903 defines privacy-policy and terms-of-service as relations of links, to be used either inline in HTML or as a Link HTTP header. The RFC was published (Informational) just this March. (I also see some earlier suggestions, not widely pursued, for rel="privacy", but I don't see any problem with the longer form.)
>>> 
>>> 4. policies.txt     
>>> https://www.sixlines.org/2013/08/19/policiestxt.html
>>> Most recently, I saw this brought up by Aaron Massey, who suggests a policies.txt file in a well-known location, similar to the widely used robots.txt protocol and the informal humans.txt analog.
>>> 
>>> Personally, I think the Link relation (#3) is both flexible and very easy to implement. IETF published the documentation as an informational draft, and I'm not sure the history there or why it wasn't pursued on the standards track. Sites that have different privacy policies for different URLs can implement it through different link tags in the heads of documents. Very small sites can just add rel="privacy-policy" to a plain old anchor tag. And hey, it works for terms-of-service too.
>>> 
>>> Questions for you all:
>>> * Would you find standardization/use of this valuable?
>>> * Is there any standardization necessary beyond the informational Link relation definition? If so, what features would you want to see?
>>> * Would you be willing to implement it, or what would be needed to encourage implementation?
>>> 
>>> Thanks,
>>> Nick
>>> 
>>> CC Aaron Massey, who brought this up on Twitter/his blog, Jason Snell who authored the Link relation proposal. I'm also sharing this with the Open Notice group who have been talking about related standardization efforts.
>> 
>> David Singer
>> Multimedia and Software Standards, Apple Inc.
>> 
>> 
> 
> 

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Tuesday, 20 August 2013 19:59:08 UTC