- 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