Concern: Contextual Integrity violation

[bvandersloot-mozilla]

One concern that has crystalized in my mind since TPAC around all forms of FedCM is that it is deceptive to present information from one context into another, making it appear that the contexts are already linked before the user makes their choice.

This is only a problem before the user has linked their account to the IDP. One solution would be to only show account hints on a linked-but-not-logged-in account so we still get the benefit of presenting to the user what accounts they have reliably. This also gives us a route to solve #40 by simply fetching the account hints dynamically (which would be acceptable due to the pre-linkage).

@ekovac @johannhof @samuelgoto Thoughts?

[ekovac]

I think that contextual integrity issue only applies if the UX matches what exists in Chrome today. As written, surely other implementations could choose to avoid it?

[bvandersloot-mozilla]

Certainly- there is no normative language on showing those accounts in the UI. But the spec is certainly written with an assumption of presenting this information to the user, e.g. "Display an account chooser displaying the options from accountsList" really only makes sense if you use account information to show those options.

I'm interested in if we agree that this is a problem and if so, what design considerations we can make to mitigate it in Lightweight FedCM, especially since the first thing that came to my mind lets us easily solve #40

[samuelgoto]

With regards to the following points that @ekovac and @bvandersloot-mozilla raised earlier:

I think that contextual integrity issue only applies if the UX matches what exists in Chrome today. As written, surely other implementations could choose to avoid it?
Certainly- there is no normative language on showing those accounts in the UI.
it is deceptive to present information from one context into another, making it appear that the contexts are already linked before the user makes their choice.

Would you feel that it is equally deceptive to present information from one context into another, making it appear that the contexts are already linked before the user makes their choice if we had chosen different UX formulations? For example, if Chrome had chosen to implement the FedCM UX in an area that is clearly part of the browser UI rather than the content UI, would we still feel that it is being deceitful? Does requiring user activation change some of this equation?

For example, just to check, would the following UX choice be both (a) spec compliant and (b) non deceitful?

What about the following UX that requires user activation?

[bvandersloot-mozilla]

For example, if Chrome had chosen to implement the FedCM UX in an area that is clearly part of the browser UI rather than the content UI, would we still feel that it is being deceitful?

Clear to whom? Personally, I'm partial to Emily's interpretations around the line of death, particularly her intuition "that the line of death is simply a foreign, incomprehensible idea to many, many browser users."

Does requiring user activation change some of this equation?

I don't think so.

For example, just to check, [...]

The URL-bar nugget is probably the subtlest one, and is much better than the one-tap-widget. But I think the reasonable question here is "what users understand that the browser is sending them a message, not the page? and unless they click the nugget the site doesn't learn about their twitter account?", and I don't know if many do, even with this mock.

[samuelgoto]

Still trying to understand you, a few more clarification questions.

Clear to whom?

To the user.

But I think the reasonable question here is "what users understand that the browser is sending them a message, not the page? and unless they click the nugget the site doesn't learn about their twitter account?", and I don't know if many do, even with this mock.

How does this user comprehension argument stand with autocomplete? Doesn't the following UX also fit the description of "present information from one context into another"?

[johannhof]

I really understand your intuition here @bvandersloot-mozilla and I appreciate the evocation of Contextual Integrity as a concern for FedCM and similar new APIs that avoid cross-site tracking but preserve an integrated user experience on a composable web.

It's super interesting because I think these APIs (specifically FedCM and Fenced Frames w/ unpartitioned storage) walk a thin line between actually giving users a contextual choice about sharing their information and the possibility for violating contextual integrity through showing user-identifying data where a user does not expect it. I personally believe that we can be successful in building and refining (and educating our users about) these new privacy-preserving UI patterns over time, and thus shape the norms and user expectations that make the difference here.

The autocomplete example that Sam showed is a great one in my opinion, if it didn't exist today we might argue that a user would find it concerning to see their credit card information listed on a page and that it may lead them to believe that their payment information was already shared with the site. But we (users) have been trained to understand that it is indeed the opposite: We are in control whether data is shared, and the fact that it is shown on the site where the data is needed provides us with much better contextual integrity than, say, a full-screen browser prompt that hides the page in order to make it as clear as possible that it's the browser communicating with the user.

I think it would be incorrect to say that FedCM is fully there yet, but it has the correct underlying principles: User data is not shared until the user chooses to, and its metadata allows for very contextual presentation. I absolutely agree with you that we should continue to evaluate as user agents whether the presentation we choose is as contextual as possible, but I don't think that "make it clear this is from the browser" is the only criterion for such an evaluation.

[bvandersloot-mozilla]

I definitely don't mean to imply that "make it clear this is from the browser" is the only criterion. But it is an important one that hasn't been discussed. And that is a really good point that when joining contexts, both are important.

The autocomplete example is a great one and I think it can help illuminate where the finer points of concern are. I think there are a few big differences, one of which Johann pointed to already:

1. the credit card case already exists, and has some amount of user training around the "click-to-fill" semantic built in already, and is presented in the context of a form-fill action being done by the user. FedCM adds new functionality and the existing training around social login is built around the opposite semantic of "would you like to use this info we already have?" and with it being pushed to the user as a suggestion.
2. Credit card info is my data from the real world that I share with a site, whereas my Google account info is data I constructed on one site already so having it appear elsewhere on the web is more complicated by bringing in another informational context.
3. Credit card autofill's alternative leaves us with more users allowing sites to store their data. This leaves users at higher risk for credential compromise overall. If a user doesn't use a social login, we have password managers and passkeys as strong authentication alternatives.