Re: [w3c/payment-request] Regulatory Compliance Support (#632)

> First of all, Data Protection Impact Assessment will not have to be performed for all sites, and that article is not stating that.

Privacy impact assessment will have to be done as some form of exercise everywhere user data is handled in Europe, which will likely include most if not all payment situations. http://www.eugdpr.org/key-changes.html - privacy by design is the legal requirement and thus requires some form of assessment in order to design: if you can design without an assessment then I'm not sure I'd trust the design which is why I'm raising this very serious issue. If you haven't assessed, then you multiply the number of assessments you could do 1 (w3c does it properly) by every adopter on either side of the API who will need to do it instead: if you don't.

For businesses involved with payments of a sensitive nature, like but not a complete list:

- court fines
- clinical trial compensation
- medical purchases
- legal service
- official documents
- childcare support
- ...

it is unlikely to be appropriate to create the risk that the payment processor will receive information that the user purchasing has say:

- a fine for indecent conduct
- is on a cancer trial
- bought Methadone for their addiction
- is getting their will written
- bought a Russian passport
- a 17 year old babysitter hired too look after the kids for tomorrow evening at 6pm
- ...

There are all additional details people want to see when choosing and confirming a payment, but it is unlikely they want them in analytics systems, logs or even just received by a service that doesn't need them.

> Sorry for off-topic, but is it also the case for other APIs? I think so!

For most of these sensitive payments, I hope Stripe, Paypal, etc, aren't involved with their full api in use and where they are using the api the organisation adopting them is hopefully going through a painful privacy assessment and having to work out how to anonymise the purchase details, whilst still allowing it to reconcile with some view the customer has (previous web page and reference numbers like 1234? I think I'd prefer a web form!).

As the interface to payments, this api will be at the centre of privacy impact assessments across Europe and for companies that wish to do business in Europe. You can either make their lives easy or risk being another nightmare like the referer header spec.

Governments internationally (not just the EU) are reviewing the privacy of the internet and if this spec is going to last the next inroads to protect users from the invasive tracking that's already happening, then it needs to be a step ahead, not behind of where regulation is going: otherwise this spec is going to be the root cause for people losing their data when payment processors get hacked or leak and for the vulnerability that users already have to misuse of web functionality: like Facebook illegally capturing data because it's so easy with how third party cookies and referers work http://www.telegraph.co.uk/technology/2017/09/11/facebook-hit-12m-fine-spain-breaking-privacy-laws/

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-request/issues/632#issuecomment-335808578