Lola: I haven't looked at this yet.

Ehsan: I haven't read it carefuly. Don't have concrete opinion yet.

Lola: Am a bit biased the title doesn't fill me with hope.

Ehsan: It seems like the discussions have been around for a long time (2020?) I see Martin has an interaction so will ask him later for opinion.

Lola: I may be wrong about this but this is one of the proposals related to third-party cookies.

Matthew: What's the diff with https://github.com/w3ctag/design-reviews/issues/1145 ?

Lola: I'll ask them.

Matthew: Any updates? Ehsan: Have read the explainer, preparing review on it, hope to have the review by next week. … Don’t have any critical objections up until now. … Maybe next week we can discuss it in more detail. Matthew: Think we discussed this during the F2F in HK, there was confusion about a potential duplicate between issue #1145 vs. #1136. Let’s discuss this next week.

Ehsan: Review almost ready to post. Main concern is that removing one of the URLs (shwoing 2 instead of 3) may increase the chance of phishing/social engineering attacks. This is becuase they're delegating the task of specifying the iframe to the developer and trusting that they will act in good faith. This seems to be a fundamental question: it seems to reduce user confusion perhaps, but increase the chance of phishing and privacy leakages. I am slightly inclined to oppose it due to that. Whilst the likelihood isn't huge, it does present some risk. (That's a summary of what I'm about to post.)

Lola: Can you post that in the private thread and folks can review it? I have questions but would like to read it.

Ehsan: Yes, sure.

Lola: To Matthew's question yesterday about whether they have any mock-ups. I was looking at the web speech API today and they have a screenshot of what the UI could look like if you're using Web Speech APi - so I dont' think it's out of our remit to ask for something similar on this. Whislt it's up to the UA to decide on the UI, the spec authors could give us an idea.

Ehsan: My main issue is they're removing one of the URLs. If they can find a way to include all 3 It hink it would help.

Matthew: Bump to Breakout C. We thought the picture would be a mock-up of the UI, and it's just a flowchart. They want to minimize the number of domains you need to show. Ehsan has concerns about that. Death of the line of death. They say that sometimes they don't need to show all 3 domains. Where are they proposing to show 3 domains? Address bar, iframe, 3rd???

Lola: They're talking more about implementation than presentation.

Matthew: Get that we avoid talking about UI design, but want some illustration. Even some text.

Lola: +1 to your comment Ehsan

Ehsan: In general I'm in favor; have a couple of qustions about social engineering attacks that apply to the way they're doing it (in proposed comment).

Lola: You can just post - if any of us think of more questions we can add them.

Jeffrey: We shoud clarify regarding the polarity mismatch between title and explainer.

Lola: We should decline to review when there isn't an Explainer (document) (rather there is just a comment). Or we should put them in a holding pattern.

Jeffrey: Sometimes a comment is appropriate when it's a small change. But this is above that threshold.

Lola: Martin proposed adding something to the process about AI. Check out Slack.

Matthew: Can we ask for more concrete examples (maybe there's a reason why they can't)? Think that would help a lot. Did appreciate the case they raised about apps within other apps, and signing in.

Lola: We should ask, yes. Leave it to them to let us know if they can't.

Jeffrey: +1 and this is a reason why they should write an explainer rather than comments. I think Ehsan is coming up with attacks based on the 'backwards' understanding of what they're doing (because their explainer had the order backwards). We should write our comments with the threat model they have in mind.

Lola: recapping prior discussion: we wanted to ask them for an explainer, and ask them for more concrete examples.

Ehsan: can draft something in private repo. Could you check out their last response? They seem to conflict somewhat with each other. I'll draft somethihng based on what we discussed.

Jeffrey: Is it clear they're asking about adding an extra domain?

Ehsan: Having 3 helps, but not clear on why in some cases they're going to make it 2. Despite the confusing title, I think the text is clear they want to add something, but in some cases they're proposing not to add the third. I don't think the branch with only 2 will help users.

Jeffrey: I'm not sure that question has come through - the question of 'why not always show all 3'.

Ehsan: I mentioned it in one comment

Lola: point 2 - but I don't think, from their responses, that they've picked up on that. I think it's worth emphasizing why 2 rather than 3 origins is an issue. Looks like they're not clear on what's important to us, and vice-versa. Clarifying would be good in next tommend.

Ehsan: I think Jeffrey's point about confusing title should be emphasized too. I'll draft something.

Lola: I'll check what you mentioend about their last two comments.

Lola: In the private brainstorm, Jeffrey and Ehsan, you seem to have been trying to work something out.

Ehsan: I have drafted a response to Jeffrey's comment. I agree with his first point. The second point as well, but. I think the one thing that is still ambiguous for me is the delegation of the permission of the top origin to annouce their relation to the iframe. So I have a small analysis that I will post later today, to make my point more clear by example.

After that, Jeffrey, we can have a better discussion. I tried to find the propenents at TPAC, but I couldn't find them.

Jeffrey: In future, if you need help running into a Googler at TPAC, that's my job.

Ehsan: Thank you.

Ehsan: I prepared a table for this, in terms of each circumstance or combination of iframe and top origin relationship. So at least for me, I summarised my concerns in the last two items in the conclusion. There are two things: the matching process is not clear at the IDP level, and the delegation of permission is on the top origin, which I don't think can be trusted for many reasons. Overall, the main issue is the wider cases that two be shown instead of three, and I'm proposing that all situations show three. Based on an ambiguous process, some need to output two URLs instead of three, and that would make users less informed.

This is for the cases in the authentication ceremony that the top origin calls the iframe where the origin is different than the top origin, and it only relates to the UX string shown in the authentication popup or prompt. in the current situation, the iframe origin and the IDP is shown. This spec is trying to add the relationship between the top origin and iframe to the picture as well, and proposing a mechanism that in some cases shows three origins and in some, two origins.

My problem is that that process is ambiguous, and if you want to make users informed, why not show all three?

The announement of the relationship is delgated to the top origin. If the intention of the top origin is not good, then it can lead to different outputs. In the table, I'm showing my understanding of the different outputs.

Jeffrey: the proponent's counter-argument to the bottom two rows is that, if the top origin doesn't want to show the iframe's origin, it can just call FedCM directly without an iframe. So what is the difference and why is it worse to hide the iframe that it's using?

If it... wants to be showing an iframe's origin, it can just call FedCM itself?

Ehsan: In that case, there is no need for this spec. They justified that there is a genuine need for an iframe to be called.

Jeffrey: the use case is for benign top-levels.

Lola: Does that prohibit malicious...?

Jeffrey: you can't.

Ehsan: That's too much trust.

Jeffrey: This is a convenience thing. Top-level origins delegate to an iframe for sign in. Sometimes they are doing it because the iframe origin is more trusted than the top level origin (accounts.google.com in another google.com domain where accounts is resistant to XSS but the other one isn't). But if you're a malicious top-level user, you could just inline the sign-in code in the top-level origin. You aren't going to use an iframe if you don't want to show it to the user.

Ehsan: I see your point. My concern is not about the technical vulnerability, it's focused on the amount of data the user has been shown. It's a UX spec. So the attacks are focused on social engineering. I think users need to be shown as much information as possible for authentication.

Lola: I'm stuck on this: when the top origin is good and the iframe is good, and the fedCM dialogue text is the same as when the iframe is good and the top origin is bad... That, to me, is highlighting the issue of not showing all three URLs. Those two conditions are enough to be like... If you can have a malicious top level origin present the same thing as a non-malicious one, that's not good.

Hadley: Ehsan, can you describe a use case where this would go horribly wrong with two URLs?

Ehsan: UX, so it's limited to the amount of information that's shown. It should show as much as possible. If there's no distinction beetween a good and bad top-level origin, users might not learn as much as they should. I had in mind that if gogle.com as the iframe is supposed to be the iframe that's used for URL scamming, then hiding it will cause some sort of problem for someone. Imagine that gogle.com is similar to Google. Then it could be used as social engineering.

Hadley: How does having a third URL mitigate that?

Ehsan: If the top-origin has bad intention, it would be hidden from the user.

Lola: Having the third URL might prevent the user from giving the information they might normally give?

Matthew: The main situation that we're talking about: you want to sign in to a site that is bad, in collusion with gogle.com, which isn't google.com, and it's trying to phish your account details. In that situation, there is collusion between gogle.com and the top-level frame. You could have a bad top level site that genuinely wants you to sign in with your google account. Badness is in the eye of the beholder. It's not trying to address that situation. It's trying to prevent you giving up your credentials for a valid service.

If it doesn't show all three URLs, you are denied the chance to realise you are signing in to gogle.com and not google.com.

I see what you're saying that if the top frame is bad and the iframe is good, it's a different problem. That's not what the focus is here.

I tend to agree, that not showing all three is inviting more opportunities to be phished. Ehsan has asked that we get them to be clear when they propose to only show two. They talk about relying on the top level origin to make it clear that it and the identity provider are related. So the top level origin (which could be malicious) is allowed to say if the sign-in origin is related. So you could sign into maps.google.com with accounts.google.com, and it doens't show both to the use as a convenience. but the party you are trusting that decision to could be malicious. It's concerning.

Jeffrey: gogle.com isn't helpful here, because the point is that it's confusing with "google.com". Showing it to the user could make it worse. So we need another example.

Hadley: evillogin.com?

Jeffrey: Right. So if the iframe is trying to attack the user, and they are trying to phish the user, there is nothing to stop the top level site from using FedCM to use evillogin.com.

Lola: If the iframe is evillogin.com, will showing all three URLs not at least help the user know that the URL is malicious?

Jeffrey: It helps, but we can't expect a malicious site to use it. There is no benefit to saying, "If you decide to use an iframe, then you have to show it", because if you're malicious and you don't want to show it, you won't use an iframe. If you're good, there are architectural reasons to use an iframe.

Lola: You don't think this invites more malicious attempts?

Jeffrey: I'm not completely sure, but we need to provide the actual use case to explain to the proponents what worries us.

Ehsan: I think it's about helping the user make an informed decision. That will be better achieved by presenting them everything.

Jeffrey: Not always true. Sometimes too much information isn't helpful.

Ehsan: I see your point, but you said there is a problem with FedCM anyway. The problem here is that there are two URLs shown to the user; let's present as much info as possible. But they said in some cases two, sometimes three... I think there should be some consistencies in making this process. I don't think that's helpful.

Jeffrey: The site already has a choice of whether to show two or three URLs, by choosing whether to use an iframe. This lets the site decouple that decision from whether to use an iframe. The question then is: what extra attacks would this allow?

Lola: I think we should think about what this would allow, if any. But I think Ehsan's question on reasons not to show three is good to put to them too. I agree with Jeffrey's point that sometimes too much info is bad, but I'd like to hear their thoughts. I don't think I've heard much justification about how this makes it easier or better for users.

Matthew: I see Jeffrey's point about, "if they're bad, they'll do it differently". I'm not sure that gogle.com is a bad example, but I suspect that if we work through the example, it would be clearer. I'd like to see that written down. And I don't think they're explaining the user need clearly.

Could we take off the conclusion part of Ehsan's comment and post it? At the same time, we could go through a few examples with concrete URLs and domain names, and explain what attacks we are concerned about.

Jeffrey: +1 to asking for a better explainer

Matthew: Also, is it a bug that you can call FedCM from the top level?

Hadley: Isn't that the point of FedCM?

Jeffrey: It's not the whole point, but we don't want to require that sites rely on a separate iframe to ask for federated login. You should be able to write a site on one page.

Lola: Ehsan, I think you should post your conclusion. Or just the question: why would we not want to show three? What are the use cases? Ask them specifically about the end user benefits on this? And their explainer is a comment, referring to other comments. A better one would be good.

Ehsan: I read through the comments. It has been mentioned, the problem of permission, and delegation of permission. I don't think there was a clear solution for it. I will draft a comment and post it here, so you two can make sure. Because of the history, I would like a second eye.