这是indexloc提供的服务，不要输入任何密码
Skip to content

Remove UI claim #337

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 24, 2022
Merged

Remove UI claim #337

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 10 additions & 12 deletions spec/index.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1438,18 +1438,16 @@ The FedCM API introduces new (trusted) user agent UI, and the user agent may cho
entirely on top of the page's contents, if anything because the page was the one responsible for
this UI. This introduces a potential concern of a malicious site to try to replicate the FedCM UI,
gain the user's trust that the user is interacting with a trusted browser surface, and gather
information from the user that they would only give to the browser rather than the site
(e.g. usernames/passwords of **another** site). This is not possible because the FedCM UI uses the
metadata about the user accounts of the [=IDP=], which the website doesn't have access. If this is
a malicious site, it would not know the user accounts, otherwise the user is already compromised.
In addition, the FedCM UI is deliberately constructed to not prompt the user to provide additional
information, such as username or password. Thus, an attacker trying to impersonate the browser
using exclusively UI that is accessible to the content area (e.g. iframes) to attempt to retrieve
sensitive information from the user would be noticeably different from the FedCM UI. Finally,
because the FedCM UI can only be queried from the top-level frame (or potentially from an iframe
with explicit permission from the top-level frame), the priviledged UI surface is only shown when
the top-level frame wants it so. A sneaky iframe cannot force the FedCM UI to occlude important
content from the main page.
information from the user that they would only give to the browser rather than the site (e.g.
usernames/passwords of **another** site). This is not possible because the FedCM UI uses the
metadata about the user accounts of the [=IDP=], which the website doesn't have access. If this is a
malicious site, it would not know the user accounts, otherwise the user is already compromised.
Thus, an attacker trying to impersonate the browser using exclusively UI that is accessible to the
content area (e.g. iframes) to attempt to retrieve sensitive information from the user would be
noticeably different from the FedCM UI. Finally, because the FedCM UI can only be queried from the
top-level frame (or potentially from an iframe with explicit permission from the top-level frame),
the priviledged UI surface is only shown when the top-level frame wants it so. A sneaky iframe
cannot force the FedCM UI to occlude important content from the main page.

<!-- ============================================================ -->
# Privacy # {#privacy}
Expand Down