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

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 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, by 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 their 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 ones before anyone else does).


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