- From: Aleecia M. McDonald <aleecia@aleecia.com>
- Date: Sun, 26 Mar 2017 08:18:45 -0700
- To: "public-tracking@w3.org (public-tracking@w3.org) (public-tracking@w3.org)" <public-tracking@w3.org>
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
>
Received on Sunday, 26 March 2017 15:19:17 UTC