Re: [w3c/payment-handler] Open Window Algorithm and tracking through 1ps (#351)

In general I agree that there needs to be more control over arbitrary cross-origin communication. I'm still learning the different mechanisms. Thanks for being patient with me.

> The difference is that different tabs / 1ps cannot communicate with each other. Thats exactly how cross site tracking is accomplished, and what 3p containment protects against. You can test this, for example, by clicking a cross-domain `<a target=_blank>` link in safari, and then noticing that `window.opener` is null.

`window.opener` is also null inside a payment handler window today. I think this makes sense to keep, so we can modify the spec and add WPTs to make this a requirement.

> > If I click on a link to ewallet.com from store1.com, log in with account1, and then click on a link to ewallet.com from store2.com and log in with account2, ewallet.com can also link my two identities.
> 
> I don't understand this claim That is not true with out some common hook to tie account1 to account 2. If you have segmented (3p) storage, the ewallet.com lacks that common hook.

This is what I was thinking:
- I click on a link to ewallet.com from store1.com
- I login on ewallet.com with account1 -> ewallet.com plants a cookie that says "account1"
- Some time later, I click on a link to ewallet.com from store2.com
- ewallet.com reads their cookie and discovers that I'm "account1". They offer a choice for me to switch account.
- I login with account2. Now ewallet.com knows that "account1" and "account2" are associated with the same browser profile.
 
> But further, consider other types of tracking you're enabling:
> 
> 1. I click on the link to ewallet.com and then decide not by anything
> 2. I click on ewallet.com, it opens for a second, stores the tracking cookie, transmits the cookie back to the site I came from (store1.com) and now store1.com, store2.com and ewallet.com can all collude to share information.  This is not possible if ewallet.com gets segmented storage.

I feel I'm missing some key insight to understand why segmented storage helps here. Would you help me understand? Assuming the cookie ewallet.com sends back to store1.com contains some ID for the user that ewallet.com understands, and it's this cross-origin transmission that allows tracking, why can't ewallet.com and store1.com accomplish the same via a server-side backend communication? This should be possible since we already assume they are colluding.

> 3. More broadly, if all thats needed is a user gesture to get a common / global 1p storage, my analytics script can use that to track users across all sites (e.g. anytime the user is trying to leave the site, spin up this modal window, cookie sync, and then let them leave).  That would undo 100% of the benefit of partitioned storage.

I agree theoretically you could do this. However, I suspect the fact that the tracking is not completely seamless (because a modal will open) would make this not a very useful mechanism to deploy trackers. We can make it even harder by having the browser require another user gesture inside the payment handler modal to dismiss the modal. This will not add any friction to legitimate use cases but would make an attempted attack very visible to the user. If this experience persists, they probably wouldn't come back to the site again. I feel this may be a sufficient disincentive for this abuse of payment handler.

> > Being able to follow links is a fundamental property of the web.
> 
> This is not at all like following links on the web. Tracking user across link clicks is currently accomplished by using the referrer header and / or query parameters. Browsers (Safari, Brave, Firefox) are all working on ways of preventing exactly this. 

Removing referrer header seems a reasonable proposal. How would removing query parameters work? Would I no longer be able to link to a page with query parameters?




-- 
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-handler/issues/351#issuecomment-552032168