Meeting minutes
Privacy Sandbox
Rouslan: Privacy sandbox is undertaking project related to data collection.
… default browser behavior will limit silent tracking
… general concept is that if 2 sites have independent identities, then intended behavior is that correlation without user consent will not be possible
rouslan: Chrome will phase out support for 3p cookies over a three-month period finishing in late 2023
… cross-origin iframe will not have access to cookies
… (by default)
… the iframe can communicate with the top-level (who can tell the iframe who they think the user is).
… if the user provides random identifier to top-level site, won't facilitate tracking via 3p
… there are some other behaviors expected as well.
… e.g., CHIPS
… where the iframe can store SOME information, but CHIPS cookies will be scoped to the parent origin.
… (storage partitioning)
… cross-site information needs 1 user authentication in order to be able to store CHIPS cookies
… another project: "Fenced Frames"
… this one blocks communication between the embedded iframe and the top level Web site
… this proposal is very early in its life
… but the idea is that tracking inhibited by lack of communication between origins
rouslan: So how does all this affect payments?
<weiler> [what's the expansion of CHIPS?]
rouslan: Embedded code may have no idea who user is via regular iframe. This might mean, e.g., user retypes credit card each time they visit the same merchant
rouslan: I think this will be a big change so we need to find alternatives to avoid breaking the web.
… we need to hear from you what flows will break so we can find solutions
rouslan: We invite members of this Working Group to let us know your payments flows and how they would be broken by privacy sandbox changes
<Zakim> AdrianHB_, you wanted to ask what "authentication" means on the top-level site
AdrianHB: What does authentication look like to give an iframe access to CHIPS?
rouslan: That's my shorthand for "identifying yourself to the iframe". This might be, for example, providing an identifier for yourself.
AdrianHB: So you don't provide ID to the top-level iframe that is shared with cross-origin iframe?
Rouslan: You could do that, but if you provide a random identifier to the top-level identifier, you won't support tracking
AdrianHB: So I could identify myself as "user X" to cross-origin iframe and they could tell parent origin "This is user X".
Rouslan: Yes. But when code is embedded on a different origin, that information ("X") won't be available to them.
Weiler: What does CHIPS expand to?
Stephen: "Cookies Having Independent Partitioned State"
rouslan: Ideally you don't want to have to retype your card or bank account number on every site.
Adrian: If you use payment apps you still need to authenticate to the payment app.
rouslan: We don't want users to type username/password in an iframe.
<Zakim> weiler, you wanted to ask for expansion of the CHIPS acronym
Rouslan: I need to find a better word than "authenticate" to mean "user provides identifying information"
Gerhard: Fenced frames sound more appealing to me. If I put a custom URL in a fenced iframe (e.g., in 3DS method URL). That's a channel of communication.
Rouslan: The fenced frame explainer discusses this. One thing they might do they call a "three states machine"
… when the fenced frame accesses its URL from JavaScript it then loses storage access (write access) and network connectivity.
… but I think this is an unanswered question in this early stage of the project
Gerhard: I heard each iframe would have isolated storage.
Rouslan: Again, fenced frame behavior is not entirely known.
… in this group we can help answer questions by describing what would break
Rouslan: I think we may need more than CHIPS and fenced frames for payments
Gerhard: How do these changes change:
a) hidden iframe
b) Secure storage in iframes
c) payment handlers
d) Popups
… in an iframe
rouslan: We don't know yet. What do you mean by secure storage?
Gerhard: Local storage / index DB
rouslan: I think the expectation is that all storage mechanisms would be partitioned
… regarding payment handlers, they use service worker, and privacy sandbox expectation is partitioning there, too.
smcgruer_[EST]: See the Federated Credential Management explainer
… helpful in calling out problem statements
… FedCM is evolving to a model where they are pretty sure their technology is privacy sensitive against all the changes that are envisioned
… so that's a good example to be aware of
<Zakim> Ian, you wanted to ask rouslan where we can document these flows that will break
Gerhard: We know the 3DS flows; has that use case already been covered in privacy sandbox discussions?
Rouslan: We realize that 3DS will be affected.
<AdrianHB_> +1 to the problem of general purpose features being abused. I still believe we can find a balance with PR API + PH API + SPC that is payment specific enough to prevent tracking exploits but generic enough to be widely useful
Gerhard: The EMVCo world view is that when data collection does not suffice, either accept risk or challenge
… if we can get guidance on getting adequate consent that would be helpful.
… are three clicks enough? a daily click? What suffices?
… just tell me what the hoops are :)
<Zakim> smcgruer_[EST], you wanted to react to Ian
smcgruer_[EST]: is this something we should pick up in the WG?
Ian: Should be starting a document with "things that will break"?
rouslan: Yes, that's one step
smcgruer_[EST]: Also people can reach out to us directly.
Ian: Do you have an initial list?
smcgruer_[EST]: I have a partial list
Ian: Any co-editor volunteers?
Action: Stephen to start to move "things that will break" list to that repo.
Stephen: Again, we'd like to hear concrete flows.
… e.g., part of a flow might be for a wallet to give back some data to the merchant to give to their payment processor.
… what mechanisms are we using to take these steps, and what would a world look like where primitives would not be abused.
… we've mostly thought about 3p cookies but we need to start looking beyond those mechanisms.
… as an aside, this is a general browser direction and so we presume the payments industry has ALREADY been affected.
… if the world hasn't yet burned down, why are things still working? What does that tell us?
TPAC Recap, Anti-Fraud Next Steps
Minutes linked from the agenda
Ian: Rouslan, you asked questions in 3DS WG discussion. Any movement after those?
Rouslan: Not yet
Ian: We also want to connect to anti-fraud discussions
Kaustubha: I'm working on sandbox. One work stream we are involved in is anti-fraud.
… we recognize that anti-fraud solutions rely on 3p cookies, data collection, etc.
… client IP addresses, etc.
… across the industry browsers, OSes and so forth have been working towards making some of these signals harder to use to track users.
… we want to be doing this responsibly.
https://
Ian: What will happen in the anti-fraud CG?
Kaustubha: We'll start by listening. We are working on trust tokens, for example.
… we want to hear about use cases, requirements, and constraints.
Ian: Is risk scoring part of your team's remit? the CG?
Kaustubha: something like that could be interesting. On Android and iOS there are native APIs regarding confidence in user.
… I think exposing something like that in a privacy safe way on the web is something to consider
… but we don't want to lock people out if they don't have the token.
… we are experimenting with that, in relation to trust tokens.
Ian: Where is that conversation happening?
Kaustubha: WICG (via GitHub)
… but we might ask to move it to anti-fraud CG
<Zakim> smcgruer_[EST], you wanted to note the sort of insights payments could bring to anti-Fraud CG
smcgruer_[EST]: Here's why the anti-fraud CG will be important and why payments folks should go there: there are interesting payments points of view that may not be captured .... like "trustworthy user but inappropriately using stolen card"
Kaustubha: Agreed. There are some post-facto activities and some not; we are hoping to identify what signal fidelity is needed for different use cases.
… e.g., want to discard tokens when users log out
Kaustubha: As we make progress, we can make touch points with this WG.
<Gerhard> (Found the way to show my support
Ian: See also the WPSIG
[WE CELEBRATE Anti-Fraud CG LAUNCH!]
Ian: Next meeting: 18 November.