Suggested emphasis of privacy protections #628
Conversation
Perhaps my mistake, but I missed exactly how details of the the purchase (beyond payment scope) were protected from being sent to the payment processor. @marcoscaceres helped make it clearer https://twitter.com/mrmarkrichards/status/909707142076227584 and suggested I raise a request here. It'd be great to to ensure it is very clear that purchase item details, same as shipping details, shouldn't be shared with third parties (only the site you are paying would know). Hopefully, this will reduce the likes of me querying it again. I think the wording suggested achieves the goal, but I'm not used to contributing to specs so feel free to criticise.
| @@ -3320,6 +3320,11 @@ | |||
| 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 | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Agree. I think the other members are quite well covered by the previous paragraph in the spec.
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
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:
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:
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).
There was a problem hiding this comment.
Especially as you stated the data would never be sent
Yay! twitter :) Would never be sent without user permission.
There was a problem hiding this comment.
@markalanrichards thanks for the details. Will respond more fully tomorrow... just heading home, but lots to think about here.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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:
- 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). - 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.
|
@ianbjacobs I think we need to carve some time out for this at TPAC |
If we go to crazy with this we will end up exactly where we are now: with the spec saying nothing. Let's accept the minimal of what we can get away with (and what's most realistic, and is better than the current status quo in the wider market). I think all implementers are already doing the right thing and not sharing this information with third party apps - so to make this an issue, when it's not actually an issue, risks upsetting people unnecessarily on what is already a super sensitive topic. I think best we can do is really try to educate people as to why it's a really terrible idea to share |
|
@marcoscaceres - creating an api that includes the private data in the first place is not all you can do to protect privacy, you can not include it in the first place. The PaymentResponse (which is what I believe the payment handler would get) doesn't need to have the fields and you can explicitly make it clear in the spec that payment processors should never get this data. Please decide on whether you care about protecting privacy, you've gone from.
If the w3c is making an internet for the people, it needs to put their protection first, not hand off trust to third parties who may or may not act in the same way in the future. It's not like we've got a history in our industry of companies not being evil and then very obviously losing multiple anti-trust lawsuits. If all the w3c can create an API that leaves the door open for privacy invasion and get a working group to nod heads and state "you can trust us we're not doing anything evil at the moment": then that's a failure for the future: you're delegating protection of users to others outside of w3c and have lost control of protecting users of the internet. The fintech industry you are dealing with is hopefully sensitive to w3c values. Would they be in the room if they told you they weren't? However, regardless of their noble intent, this is a spec for all areas of the internet and it'd be sad if your API is an enabler for further invasion of privacy in countries where your fintech peers aren't dominant today or may not be able to maintain dominance: once that happens the api will be used however those dominant in that country at corporate or even government level will choose. |
They get a
Yeah, that's already the design in Payment Handler spec. However, third-party payment handlers is different. |
|
closed via #670 |
Closes #626
Perhaps my mistake, but I missed exactly how details of the the purchase (beyond payment scope) were protected from being sent to the payment processor.
@marcoscaceres helped make it clearer https://twitter.com/mrmarkrichards/status/909707142076227584 and suggested I raise a request here.
It'd be great to to ensure it is very clear that purchase item details, same as shipping details, shouldn't be shared with third parties (only the site you are paying would know).
Hopefully, this will reduce the likes of me querying it again. I think the wording suggested achieves the goal, but I'm not used to contributing to specs so feel free to criticise.
Preview | Diff