Add Guidance Text for User Consent

[adamroach]

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.

[adrianba]

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.

[burdges]

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.?

[ianbjacobs]

Ian took action on 19 September to propose some language around consent to expose group thinking.

[ianbjacobs]

PROPOSED:

This specification does not recommend any practices for establishing user consent because:

• Regulatory requirements may vary by jurisdiction.
• Beyond that, one may establish user consent in a variety of ways, including contractual agreements (that require user interaction just once), one-time click-through agreements, and persistent user agent settings.

[adamroach]

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.

[burdges]

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.

[ianbjacobs]

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:

• What constitutes user consent from a regulatory perspective may vary by jurisdiction.
• Users provide consent through a variety of mechanisms, both case-by-case (e.g., one-time click-through agreement) and persistent (e.g., contractual agreements that involve a single user interaction,
  user agent settings, and operating system settings).
• There are numerous good practices for establishing consent, such as clear notice to the user about implications of an action, usability of configuration interfaces to view and change user decisions, and
  avoiding unnecessary prompts. Developers should therefore consult up-to-date good practice documentation, which may vary by region, browser, operating system, and payment system.

[ianbjacobs]

Per my action item from today's teleconference, I have asked PING for review:
https://lists.w3.org/Archives/Public/public-privacy/2016OctDec/0003.html

Ian

[lknik]

Hello,

I replied to the list, but I'm happy to add my input here:

During the payment, this API provides personal information (such as payment credentials, shipping address, etc.) to applications.

The user agent MUST NOT share user information without user consent or awareness.

The UA MUST inform about the past and current uses of the API

[ianbjacobs]

See this post for one idea for an edit:
https://lists.w3.org/Archives/Public/public-privacy/2016OctDec/0016.html

[ianbjacobs]

See Danny Weitzner suggestion [1]:

"[P]rovide a mechanism in the protocol to indicate two facts:
(a) was user consent provided? (could be a boolean or a JSON object)
(b) under what policy (specified by a URI)"
Ian

[1] https://lists.w3.org/Archives/Public/public-privacy/2016OctDec/0014.html

[burdges]

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?

[zkoch]

We think this issue is addressed in the spec already in section 21.1:

The user agent must not share information about the user to the web page (such as the shipping address) without user consent.

[chaals]

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.

[ianbjacobs]

@chaals makes a good catch on this being in an informative section.

Two thoughts:

• Be more specific that what is meant. For example: Data collected through PaymentOptions are not shared with the payee except with user consent.
• Elevate the statement to a normative statement.

Ian

[ianbjacobs]

Reopening the issue because I think that "MUST NOT" in an informative section is a bug.

[ianbjacobs]

I am re-closing this issue because the reason I re-opened it has been addressed - the privacy section is now normative.