Re: [w3c/payment-request] Suggested emphasis of privacy protections (#628)

markalanrichards commented on this pull request.



> @@ -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

Sorry but I'm more confusing.

Especially as you stated the data would never be sent https://twitter.com/marcosc/status/909715647977840640

I feel there is a mixed message here and a confused spec.
 - If consent is how privacy will be protected, then that is sad, because consent models rarely work, but if this is the case then, how is this spec designing the consent protection?
 - if this spec is about payments, why is attempting to do budget tracking? Surely binding the two reduces the best both can be.

## Consent
So the spec is a consent model and it's okay for details of healthcare, religious and legally mandated products (passport/visa purchases, court fines, etc that are increasingly available via online services) to be available to payment processors under a consent model. 

How does this API design the consent to ensure that in browser preferences alone:
 - for payment processors by default no data can be sent
 - on a per payment processor basis, consent can be given
 - on a per purchase bases, consent given, can be withdrawn
I'm guessing this would be the minimum needed for a strong consent model.

## Budget Tracking
For payments all you need for a good spec is:
 - an offline view of what you're paying for and payment options to choose
 - a network communication to the payment provider to advise the payment details, authorisation and unique payment reference for the seller
 - per payment processor

For budget tracking all you need for a good spec is:
 - a log of payment requests
 - a reconciliation with payments used of whether payment succeeded matched with the payment request
 - for every payment processor

Payment processors won't be available on all sites and may not be the best on different sites: fees will vary on foreign currency, small payments and payment processors will have incentives (like Walmart might offer bonus points in Walmart, Avios might be best for buying BA flights). So budget tracking via a payment processor restricts the capability to track your purchasing behaviour.

Therefore...
Budget Tracking is a great idea, if it is a separate api so that it is across payment processors.
Tying the two together is a bad idea for users and risks data privacy concerns they need not face if they're uncomfortable using an online budget tracking tool: better still, journalists, lawyers, doctors, former criminals, etc who want to protect privacy of what they're doing (former criminals pay court fines, not just illicit payments) could easily have budget tracking as a local app or find a vendor that offers the security requirements necessary for their industry.

In the context of Privacy by Design (EU regulators are steering towards) and single responsibility (good programming practices) it makes a lot of sense and enhances the user experience capabilities to separate the two APIs and in the process restrict information security risk and the risk of losing privacy.

## Note: "Perhaps foolishly" indeed:
Probably best to not to cite Ebay to me, I blew the whistle there.
I worked for them, when they owned PayPal. The had a great set of information security policies: encryption of PII, hashing of passwords, access controls,  anonymisation... 
For analytics, one of their Hadoop analytics database, used internationally, tracked behaviours (anonymously) to help marketing and improve the service: that happened to include usernames and passwords for everyone using at least one of their notable IPhone apps (potentially millions of usernames and passwords in that Hadoop db for marketing to read through and create their queries on). I blew the whistle on the whole mess (although neither the regulator or Ebay advised customers to change their passwords on the affected products). I'm not sure who was following the information security policies, but like many places I've worked, few developers read them and judging by the ease (this year) to man in the middle attack Ebay checkouts and amazingly they were still using http for sensitive data: two years on they've not learned very much. Ebay has decades of experience, what are the chances newcomers like Stripe are any better? 



-- 
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/pull/628#discussion_r140198658