Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Suggested emphasis of privacy protections #628

Closed
wants to merge 1 commit into from
Closed

Suggested emphasis of privacy protections #628

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3320,6 +3320,11 @@ <h2>
The <a>user agent</a> MUST NOT share information about the user with
a developer (e.g., the shipping address) without user consent.
</p>
<p>
The <a>user agent</a> MUST NOT share sales information beyond the payment
Copy link
Member

@marcoscaceres marcoscaceres Sep 20, 2017 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about:

The <a>user agent</a> MUST NOT share the values of the <a>displayItems</a> member 
or <a>additionalDisplayItems</a> member with a third-party <a>payment handler</a> 
without user consent.

We could go one better, and actually put this requirement inline for each of the above members.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @marcoscaceres and @markalanrichards,

I'm ok with Marco's proposed text, which is consistent with discussions in the payment apps task force (thus, previous discussions) and also Google's implementation. However, I don't support extending this for all of the above members until we've had further discussion. So I suggest we limit the change to displayItems and additionalDisplayItems for now.

Thank you,

Ian

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree. I think the other members are quite well covered by the previous paragraph in the spec.

Copy link
Author

@markalanrichards markalanrichards Sep 20, 2017 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marcoscaceres
Sorry, but the word consent hasn't worked in protecting privacy. It's been a total failure. For example cookies and tracking.

There should be no need for the payment request api to ever include this information in the requests for payment. If a payment processor is also a shipping provider or a marketplace, then separate apis should be used for those to avoid the catchall privacy risk.

Expanding on the example I gave on Twitter...

If I'm a father buying HIV meds for my daughter, only my pharmacy should ever know I bought those meds: the payment provider needs to know to pay the pharmacist and the shipper needs to know where to send the box. Neither needs to know about the product and the payment processor doesn't need to know where my daughter lives... I may not even have the right to give that information to the payment provider.

Copy link
Member

@marcoscaceres marcoscaceres Sep 21, 2017 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, but the word consent hasn't worked in protecting privacy. It's been a total failure. For example cookies and tracking.

There, absolutely. But here it's fairly well guarded because all implementations have good UIs in place.

There should be no need for the payment request api to ever include this information in the requests for payment.

This may not necessarily be true. I could have a "budget app" that I actually want to pass this kind of information into. If I, as a user, trust the budget app, then I should be able give my consent for the display items to be passed along, no?

Here is a real world example. I buy a lot stuff from eBay, and pay with PayPal... I (perhaps foolishly?) trust PayPal with the display items, and those show up in my receipt:

screenshot 2017-09-21 15 24 32

Here is another one... I got a message while on vacation, and paid with Square. I again (perhaps foolishly?) trust Square wit the display item ... though I never agreed to them having that information:

screenshot 2017-09-21 15 26 06

What we are proposing for this spec is better - because it puts the user in control: by requiring consent, the user can say via the browser "never send my displayItems to X". And I think that's pretty awesome, from a privacy perspective (much better than PayPal and Square getting that stuff by default).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Especially as you stated the data would never be sent

Yay! twitter :) Would never be sent without user permission.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@markalanrichards thanks for the details. Will respond more fully tomorrow... just heading home, but lots to think about here.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@markalanrichards,

I think you made a lot of good points. However, if you split off budgeting into its own API, who will call it? It's orthogonal to what the merchant is trying to do (get payment) -- so the incentives don't seem properly aligned to get someone to call the API there. If you have the payment provider call the API -- then you haven't solved the issue of this feature being unduly coupled to the payment provider.

It could be designed such that a user provides consent on a budget provider website so that whenever a payment is completed that website's Service Worker will receive an event with the budget information. However, I'm not sure that addresses your privacy concerns. It may be particularly difficult for a user to manage turning such a feature off/on -- accidentally forever sending information to some budgeting website they meant to stop using long ago. I suppose those options could be on the UI where payment request happens... but that still implies, at a minimum, some integration points. But maybe that's ok since the APIs are separable.

Copy link
Author

@markalanrichards markalanrichards Sep 21, 2017 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great, I think we're starting to talk in terms of two separate (sub-)products here: payments and budget tracking.

Payments should protect the privacy of the user by only knowing about payment details.

Budget tracking only about budget tracking data (with it's own budget tracking handlers and service workers). They could both be driven from the same UI (budget tracking is likely a user agent service)

Fundamentally, though it seems like you want to enrich user agents with not just payment features, but standard POS/till features, so the sales experience is more secure, but also enriched:
So perhaps look at how till systems work and how it isolates the domains of data each third party service gets for their separate modules:

  • inventory module (notified during processing if items unavailable)
  • payment module (this api)
  • order details module (shipping, corporate/personal purchase)
  • points/discount/voucher module (hook into third party giftcard and voucher systems)
  • insurance module (for jewelry, travel, hire cars, etc)

Because it's a personalised till you have opportunities to hook in:

  • budget tracking (add next?)
  • shipping tracking (why not have FedEx notify you in the browser that the delivery is 2 hours away
  • credit search (car loans?)
  • ...

Each has it's own security and privacy concern, none need to know everything, but all need to know a subset of the data in the checkout, use a similar flow guided by the transaction status:

  • started
  • finished
  • reconciled success
  • reconciled failure

So, if you model the domains of what each wants and minimise them, then its great for users and for the service providers and mitigates the need for unnecessary consent.
The user only has the modules they want.

It might involved adopting some software and information systems patterns to have a component view that then flows the restricted subsets of data to the appropriate modules, but not only should it be an achievable goal with modern Javascript, it could be great and it might not be very far off what you already have.

Don't try to solve it all, payments and budget tracking might a good mix here if you can separate them properly, because it might lay the foundations for the separation pattern to be re-usable for all of the above.

And as far as Stripe is concerned:
If I want Stripe payments, great I setup payments and nothing else, they get my payment details, but my purchase of HIV meds is hidden.

If I then want budget tracking: great, I setup Stripe Budget tracking in my browser, with the free version that is filtered to only Stripe payments. I might pay extra to Stripe to enable their premium version that can track everything I do online because I'm happy for that privacy risk if the convenience and benefit outweighs the risk to me.

If I'm really concerned but still want budget tracking, I buy Stripe's Offline version (using local storage) or their privacy first version, that is local storage with an encrypted version synced to Stripe's server that they cannot read .

I think the options for Stripe products here might extend if they are modular and hopefully it'll be a consent model that'll be easier for their data protection compliance too. It also opens the door to having the best services for budget tracking and not just the ones tied to the most popular payment services (maybe they'll be enticed to make the best all round ones before anyone else does).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, not really... the budget thing is just an example to illustrate a point... it wouldn't ever be any sort of baked in API in the browser. Don't get hung up on it.

The point I'm trying to make is:

  1. The W3C or this Working Group can't actually control what happens with displayItems. We can sprinkle MUST or MUST NOT or whatever on things, but these are just, literally, "Recommendations" (i.e., not laws, etc. or anything remotely enforceable - if we want real data protection, then that's what government regulations are for).
  2. When we do sprinkle specs with RFC2119 keywords, it's a best hope thing. So best we can do is kindly ask that, if any browser is going to share this information with a third-party app, they at least have the decency to ask the user if that's ok (my proposed text).

We can see already that Google is doing the right thing and not sharing displayItems with third party apps - but who is to say if others won't in the future... but again, if they choose to... they should have the decency to put the user in control.

scope with a payment processor, such as what is being paid for and the shipping
details.
</p>
</section>
<section>
<h2>
Expand Down