- From: Sam Goto <notifications@github.com>
- Date: Mon, 08 Jul 2024 05:50:23 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/839/2213990081@github.com>
> Think of a public computer in a library, person A logs into a site via FedCM, then when finished, logs out of the RP, but doesn't realize they haven't logged out of the IDP, and closes the tab/window. The next person using the computer, potentially someone who was stalking person A, recognizes the site Person A was visiting, visits that site and gets to see person A's name and possibly email address. From a security threat model perspective, we don't handle physically-local attacks, which includes the use of public computers. More information on the topic here: https://chromium.googlesource.com/chromium/src/+/master/docs/security/faq.md#TOC-Why-aren-t-physically-local-attacks-in-Chrome-s-threat-model- > doesn't realize they haven't logged out of the IDP If the user doesn't realize they haven't logged out of the IdP and leaves a valid session in the cookie jar that another user can have access to (e.g. in a public computer), there are much bigger problems that the user would have before the User Info API becomes a problem: the attacker has access to the full IdP session, which is orders of magnitude richer (e.g. access to the user's email, social profile, payment instruments, etc) than the data provided by the User Info API. Much of the position regarding challenging related to physical attacks are inspired some of the lessons from past OS designs ([example](https://chromium.googlesource.com/chromium/src/+/master/docs/security/faq.md#why-arent-compromised_infected-machines-in-chromes-threat-model), [example](https://web.archive.org/web/20160311224620/https://technet.microsoft.com/en-us/library/hh278941.aspx)). -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/839#issuecomment-2213990081 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/839/2213990081@github.com>
Received on Monday, 8 July 2024 12:50:27 UTC