- From: Martin Thomson <notifications@github.com>
- Date: Tue, 17 Jun 2025 17:58:44 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/1092/2982263716@github.com>
martinthomson left a comment (w3ctag/design-reviews#1092) > Does this address your concerns? Not really. At least, not for me personally. Though the API doesn't get to name a credential, this is new information leakage. I realize that attempting to read this bit carries the risk of showing prompts that will be very annoying, but I don't see sufficient justification for this. If this is for first-time visits to a page or visits from people without any associated identification, as you note, it would be better to have an explicit user choice to log in - engaging the existing flow - rather than have this pop, conditional on there being a credential. It seems that the set of cases where a user is unknown to a site, but has a usable credential for that site, is a fairly narrow set of cases. * There is obviously the cross-site credentials in Related Origin Requests. Is that a primary use case? We haven't established a TAG position on this yet, but we have concerns about cross-site information flow, similar to those for Related Website Sets. * A user who has cleared cookies is another potential candidate. But this design allows for invisible confirmation of a non-recognition, which is undesirable. * What else did I miss? Overall, the information leakage, both through the immediate failure and the API being disabled in private/incognito modes don't seem to be justified by these. -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/1092#issuecomment-2982263716 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/1092/2982263716@github.com>
Received on Wednesday, 18 June 2025 00:58:48 UTC