Open Window Algorithm and tracking through 1ps

[pes10k]

I am attempting to understand the "Open Window Algorithm" section of the spec. My understanding is that it would allow (say) example.com to open and interact w/ 3p domains (those of the payment handlers) but in a 1p / top-level-context.

If Im reading this correctly, this would enable types of tracking that other parts of the web platform are trying to address (specifically, double-keying, or partitioning, storage by 1p-3p to prevent the 3p from tracking the user across the web). If I read the spec correctly, the standard would allow the payment processor to track the user across pages that use the processor, since the processor would always have access to the same global storage, instead of different storage for each 1p it appears under.

Updating the spec so that open window doesn't create a top-level-context, but a 3p context, would solve this problem, and would be inline with the privacy protections being pursued by partitioning storage, Storage Access API, etc.

[ianbjacobs]

Hi @snyderp,

Thanks for raising an issue.

One quick note: the merchant does not open the payment handler. The user chooses
(and launches) a payment handler to respond to a payment request. Once the payment handler is running, the merchant and payment handler can interact through a small set of events defined in Payment Request API and Payment Handler API.

I have a couple of questions:

• Today users are often redirected to payment services, which also seem to be top-level contexts. Our thinking is that this is analogous to that, except a better user experience through a modal window. Does your comment about 3p context also apply to those sorts of redirects?

• Payment services know to whom I am making a payment. When you refer to tracking users, do you have in mind tracking beyond that knowledge of who is the beneficiary?

Thanks!

Ian

[pes10k]

Howdy @ianbjacobs!

Today users are often redirected to payment services, which also seem to be top-level contexts. Our thinking is that this is analogous to that, except a better user experience through a modal window. Does your comment about 3p context also apply to those sorts of redirects?

It depends on the details of those redirection flows, how deeply nested they are, etc. Safari, for example, prevents some sites that are part of redirection flows from keeping state (ITP2.x) (those that it thinks are tracking). Brave and Safari both strip query params from some URLs to prevent sites from pushing information between 1p contexts. There are browser extensions that do similar things, and other browsers may, or may plan to, do other things that I'm not familiar with.

So, its all depends, but the overall point is that if payment.com is opened up from example1.com, and also opened from example2.com, payment shouldn't be able to link those two events from that activity alone.

Payment services know to whom I am making a payment. When you refer to tracking users, do you have in mind tracking beyond that knowledge of who is the beneficiary?

Not all visits to the checkout / payment page result in entering information (some users decide not to purchase). And some visitors may want to maintain different identities with the same payment provider, so (for a variety of reasons) may choose to present one identity payment.com when buying boring things, and might present another identity to payment.com when buying sensitive things. (e.g., paying for insurance and paying for a cancer screening).

[ianbjacobs]

hi @snyderp,

It depends on the details of those redirection flows, how deeply nested they are, etc. Safari, for
example, prevents some sites that are part of redirection flows from keeping state (ITP2.x) (those > that it thinks are tracking).

So an interesting question is: what information can be sent by the merchant to the payment handler once the user selects the payment handler to pay? The Payment Handler API defines some data for the browser to hand to the payment handler. This is data deemed necessary for the transaction to take place:
https://w3c.github.io/payment-handler/#the-paymentrequestevent

The browser passes the origin of the merchant site (and the origin of the party that called Payment Request API, e.g., if from an iframe).

In addition, a payment method definition can include its own "request data" (e.g., information to identify the merchant to the payment handler).

Not all visits to the checkout / payment page result in entering information (some users decide not to purchase).

That would be the same as if the user were to cancel the payment handler before completing payment.

And some visitors may want to maintain different identities with the same payment provider, so
(for a variety of reasons) may choose to present one identity payment.com when buying boring
things, and might present another identity to payment.com when buying sensitive things. (e.g.,
paying for insurance and paying for a cancer screening).

I believe that the payment handler approach would support that use case. A (Web-based) payment handler is a Web site, so the user should be able to interact with it with different identities.

[pes10k]

So an interesting question is: what information can be sent by the merchant to the payment handler once the user selects the payment handler to pay?

My concern isn't related to the information that can be exchanged, its related to which storage the web payment handler context receives. If the frame is a 1p context, that will allow for tracking to occur across 1p pages. If its a 3p context (and so all the restrictions placed on nested contexts would apply) then most methods of tracking are prevented.

That would be the same as if the user were to cancel the payment handler before completing payment.

I believe that the payment handler approach would support that use case. A (Web-based) payment handler is a Web site, so the user should be able to interact with it with different identities.

Again, my concern is not whether the API would allow people to long in with multiple identities, its that the spec, as written, would allow the payment handler to link those multiple presented identities together (since they're all happening in the same storage context). Having the context be 1p / top level makes that possible; having it be 3p / nested-context prevents most methods of that, since the storage the payment handler context gets when opened from store1.com would be distinct from the storage the payment handler context gets when opened from store2.com

[rsolomakhin]

the storage the payment handler context gets when opened from store1.com would be distinct from the storage the payment handler context gets when opened from store2.com

Would this mean that I have to login into Google Pay separately on each merchant website?

[pes10k]

By default yes (the same storage that allows not-logging-in also enables tracking)

https://developer.mozilla.org/en-US/docs/Web/API/Document/requestStorageAccess is one method that would both reduce tracking and remove the need to login repeatedly though.

So, well behaved sites would not require multiple logins

[danyao]

Thanks @snyderp for raising these thoughts. I understand the importance of locking down 3P iframes. Where I respectfully disagree is that the payment handler is not a 3P context the same way iframe is. It's more like a nicely positioned popup because:

1. It can only be triggered with a user gesture, unlike iframe or redirect which happen automatically at the embedder context's discretion.
2. It contains a URL bar that shows the origin the user is interacting with, unlike iframe where the origin is hidden.
3. The embedder context cannot play with its visibility or overlay other content on top of it, unlike iframe which can be made transparent or hidden behind other layers.

I'd argue that the payment handler window is not fundamentally different from a new tab that's triggered by the user clicking on an <a href="..." target="_blank">, so it shouldn't be subject to the storage partition ideas for 3P iframes.

Again, my concern is not whether the API would allow people to long in with multiple identities, its that the spec, as written, would allow the payment handler to link those multiple presented identities together (since they're all happening in the same storage context)

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. Being able to follow links is a fundamental property of the web. The only question is, how different is the payment handler pattern different from following links? I'd argue it's pretty similar, because user sees a "Pay with eWallet" button, clicks on it. It shouldn't be a surprise to them that we load a page from ewallet.com.

Other features of the Payment Handler API arguably needs more thought. For example, the Just-in-Time Install feature causes the browser to download a manifest from a payment app origin that's specified by the merchant, without user guesture. However, Chrome's implementation doesn't send any cookies on this request. I believe we also don't allow setting any cookie on the response, but need to check. If it does, it's a bug and we'll fix it.

A bad actor can trick the user into clicking on something that opens a payment handler window to accomplish tracking. But the effect is very intrusive, so it doesn't seem to me that it will be a very successful exploit. Also browsers implementing the payment handler window can monitor how origins use Payment Request API. If there's good reason to believe this API is not used for legitimate e-commerce use cases and can prevent these attacks similar to how Safe Browsing works today.

[pes10k]

I'd argue that the payment handler window is not fundamentally different from a new tab that's triggered by the user clicking on an <a href="..." target="_blank">, so it shouldn't be subject to the storage partition ideas for 3P iframes.

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. In general, you will find few places where 1p contexts can communicate with each other, and the few that exist are being actively addressed / worked on for removal.

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.

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

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. The proposal as is would re-introduce the privacy harm currently being worked on / solved by these platforms. The issue here has nothing to do with following links, and all about what 1p contexts can learn about the behavior of the user in other 1p contexts.

[danyao]

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?

[pes10k]

I feel I'm missing some key insight to understand why segmented storage helps here. Would you help me understand?

Segmented storage prevents this kind of tracking because when ewallet.com is a 3p of store1.com, it gets a separate cookie jar (and other storage) than when ewallet.com is a 3p of store2.com. The distinct cookie jars (sometimes called double-key-ing storage, since (store1.com, ewallet.com) gets distinct storage from (store1.com, ewallet.com)) prevents ewallet from connecting the two sessions.y b

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

Unfortunately, the web platform is full of privacy harms that start exactly this way "sure its possible, but no way anyone would ever use it". Partial list includes etags, HSTS cookies, communicating across tabs using nested iframes, 1000 different sources of fingerprinting entropy, etc etc etc etc. If there is a way to track, you can be sure someone, somewhere will use it

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?

This differs by browsers (Safari strips all query params when the user is coming from a labeled tracking domain, Brave ships a set of query params used by known trackers, etc), but is getting increased focus. There is no perfect solution right now, but things are in a "lets not make the problem worse while we try to solve it" scenario.

[danyao]

I think the problem boils down to this: both legitimate payment handlers and trackers would want to access 1P storage with minimal user friction. Browsers need to allow legitimate use cases while blocking trackers.

Segmented storage blocks 1P storage by default and relies on browser heuristics to remove as much user friction as possible for well-behaved websites that use Storage Access API. For example. Safari suggested automatically granting requestStorageAccess() calls that are triggered by user gesture, and only prompts if the browser suspects some funny business is going on [1]. Microsoft seems to be planning something similar from talking to them at BlinkOn last week. I understand that Brave had made a different decision to always prompt by default [2].

What about this alternative approach: instead of blocking storage access, browser can use an algorithm similar to that for granting storage access [3] to block PaymentRequest.show()?

I believe this is better than the segmented storage approach in two ways:
The risk of a tracker masquerading as a payment handler is more than access storage: the payment handler window itself, because it looks like native UI, is a powerful feature that needs to be restricted to only legitimate use cases to avoid losing user trust. Blocking access before the open window algorithm triggers solves this problem.
Once a payment handler is “vetted” in a browser, developers can reuse their existing flows without modification.

Browser can work with the user to “vet” payment apps that they trust. For example, browser can show a permission prompt when installing a payment handler with something like "Do you wish to install https://ewallet.com as a payment method that you can use across the web?" An affirmitive answer would allow this payment app to be loaded in the open window algorithm. Or, browser can prompt the user when PaymentRequest.show() is called, e.g. “Do you wish to complete this transaction with ewallet.com?”, and offer an option to never prompt again. Chrome doesn’t do any of these today, but if folks feel this is sufficient we can doing some UX exploration.

While this model still allows some communicaton between 1P contexts (i.e. the merchant context and the payment app context), the user vetting process above limits the capability to only payment apps known and trusted by the user. Also because the communication is via Payment Request API instead of the generic postMessage, this leaves room for browser to detect and restrict abuse.

Lastly, we’ll make sure all the obvious loopholes are closed in the Payment Handler API, i.e.: window.opener and document.referrer are null.

[1] whatwg/html#3338 (comment)
[2] whatwg/html#3338 (comment)
[3] https://developer.mozilla.org/en-US/docs/Web/API/Document/requestStorageAccess