Re: TRS policy property (ISSUE 2, ISSUE 22, ISSUE 23)

Mike,
That was not the initial goal of the TSRO so I'd rather we not overload the API with that perspective at this time.  While loosely structured there was never a goal that this information be parsed in an understandable manner for User Agent interrogation such as P3P.
- Shane Shane Wiley
VP, Privacy Policy
Yahoo

      From: Mike O'Neill <michael.oneill@baycloud.com>
 To: 'Aleecia M. McDonald' <aleecia@aleecia.com>; public-tracking@w3.org 
 Sent: Sunday, March 26, 2017 8:45 AM
 Subject: RE: TRS policy property (ISSUE 2, ISSUE 22, ISSUE 23)
   
The idea is that the information should be machine-readable, i.e. by user
agents (which includes extensions like PB) or by website scanners run by
privacy researchers etc.

Information in anchor tags could be parsed but how would the machine know if
it was a link to a privacy policy or something else?




> -----Original Message-----
> From: Aleecia M. McDonald [mailto:aleecia@aleecia.com]
> Sent: 26 March 2017 16:19
> To: public-tracking@w3.org (public-tracking@w3.org)
(public-tracking@w3.org)
> <public-tracking@w3.org>
> Subject: Re: TRS policy property (ISSUE 2, ISSUE 22, ISSUE 23)
> 
> Presumably sites with all information in one html file can just use anchor
tags, so
> this is not a request for any specific structure, just that the
information be extant
> (as required by various laws.)
> 
>     Aleecia
> 
> > On Mar 26, 2017, at 4:06 AM, Rob van Eijk <rob@blaeu.com> wrote:
> >
> > For the discussion that @mschunte2 staged:
> >
> > I see a need for multiple policy attributes. For instance, reference to
a
> resource's (a) cookie policy, (b) privacy statement, (c) security policy,
e.g., a
> responsible disclosure policy, (d) terms and conditions, or (e) a DNT
policy as
> required by AB370. There is no straight forward way to distinguish at the
> moment whereas for consent this information should be easily available. I
> propose to add metadata such that UI's can use these hooks when providing
> information to the user, when needed.
> >
> > There are multiple ways of dealing with this need. I propose three
alternatives:
> >
> > A: extending the policy attribute to an array of strings. For example:
> >
> > "policy": ["https://webresource.com/cookies",
> "https://webresource.com/privacy", "https://webresource.com/security",
> "https://webresource.com/terms_and_conditions"]
> >
> > B: instead of having one policy property, extending to multiple policy
> properties. For example:
> >
> > "cookies_policy": "https://webresource.com/cookies"
> > "privacy_policy": "https://webresource.com/privacy"
> > "security_policy": "https://webresource.com/security"
> > "terms_and_conditions": "https://webresource.com/terms_and_conditions"
> >
> > C: extending the policy attribute to an array of key-values. For
example:
> >
> > "policy": [("cookie_policy", "https://webresource.com/cookies") ,
> ("privacy_policy", "https://webresource.com/privacy"),
> ("responsible_disclosure_policy", "https://webresource.com/security"),
> ("terms_and_conditions", "https://webresource.com/terms_and_conditions")]
> >
> >
> >
> > Option C is my preferred proposal, since the array of key/values is easy
to
> extend.
> >
> > Regards,
> > Rob
> >
>