-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Guidance Text for User Consent #229
Comments
Standards for obtaining user consent vary in different contexts and in different jurisdictions. The spec should not try to define what such user consent should look like - implementations are responsible for ensuring that they obtain consent in a way they believe is appropriate and acceptable. It is reasonable for different implementations to gather consent in different ways at different times using different language. I recommend closing this issue with no changes to the spec. |
I'd expect European Union restrictions on disclosing cookies and local data should already apply anytime users persistently grant access to information. In other words, another phrasing of this question might be : Does a website invoking the payment spec need to use the same sort of legal warnings the E.U. already requires for cookies, etc.? |
Ian took action on 19 September to propose some language around consent to expose group thinking. |
PROPOSED: This specification does not recommend any practices for establishing user consent because:
|
If this is intended to cover #228 and #229, I think it's a bit on the anemic side. As I mentioned during the meeting, I think the treatment of privacy and consent in the mediacapture spec is a good example of the level of detail and guidance for this kind of feature. |
Yes. We do not want a situation where a "payment app" can be little more than a tracker that "pays" merchants with "discount coupons", but the net effect on the user is simply that they are being tracked through yet another source. It's good if show always changes the top level context, but actually not quite sufficient. In fact, I'd think security dictates that the browser's payment mediator should always make an appearance, even if the merchant only supports one payment app. Now some browsers might find ways to skip the payment mediator, but if the browser has a security settings, slider, etc. then our recommendations should be that anyone with any security contentiousness should always see the payment mediator during a payment. |
The more I consider this (including the guidance in the mediacapture spec), the less I am inclined to provide specific guidance. Here is an update that exposes a few more considerations. Guidance is limited to "please consult appropriate good practice documentation". Ian PROPOSED: Capturing user information (payment credentials, shipping address, etc.) exposes personally-identifiable information to applications. The user agent should never share user information to the web page without user consent. For a number of reasons, this specification does not recommend particular practices for establishing user consent:
|
Per my action item from today's teleconference, I have asked PING for review: Ian |
Hello, I replied to the list, but I'm happy to add my input here:
|
See this post for one idea for an edit: |
See Danny Weitzner suggestion [1]: "[P]rovide a mechanism in the protocol to indicate two facts: [1] https://lists.w3.org/Archives/Public/public-privacy/2016OctDec/0014.html |
I've missed lots here, but normally one should avoid sharing data the user might not have explicitly consented to. It's not really hard to obtain that consent, just identify all the data you plan to share, and display it in a form for when the user clicks through to the payment app. I suppose this boolean is about if the user consents to share it with the site after the payment app? I guess consent could be obtained through the form layout and the booleans could represent that layout. Is that what you mean? Or am I confused? |
We think this issue is addressed in the spec already in section 21.1:
|
That seems incredibly vague - I see nowhere near enough information to justify making it a formal 2119 requirement which in any case makes no sense in an informative section. Nor is there enough useful information to explain informatively what the privacy considerations are. |
@chaals makes a good catch on this being in an informative section. Two thoughts:
Ian |
Reopening the issue because I think that "MUST NOT" in an informative section is a bug. |
I am re-closing this issue because the reason I re-opened it has been addressed - the privacy section is now normative. |
This is a recommendation from the Security and Privacy Checklist review. See https://docs.google.com/document/d/1w7ginyzNg-xZUmITK4vzcGUKB4gbMOAvlkWWaRtX14k/edit?usp=sharing for additional detail
The privacy analysis highlights the importance for explicit user consent in providing payment or any information associated with payments to a requesting web site. We suggest including the following guidance in the spec: any mechanism that allows users to persistently grant information should take steps to inform users that doing so will allow various websites to positively identify and correlate a user, even across site owners.
The text was updated successfully, but these errors were encountered: