Skip to content
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

Jump to bottom

Fix a typo in use_cases.md. #124

Merged
merged 1 commit into from
Sep 26, 2023
Merged

Fix a typo in use_cases.md. #124

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
2 changes: 1 addition & 1 deletion explainer/use_cases.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -90,7 +90,7 @@ This use case is for rendering personalized information in a fenced frame at the
* **Config:** Generated by some API like `ReadOnlyFencedFrameConfig(url)`. url can only be an https, localhost or about:blank. Is able to carry 1p data from the embedding context to the fenced frame. This is not however an issue as described in the next section.
* **Information flow and privacy model:**
* The ‘src’ url can carry user id in the embedding page. Up until the fenced frame has completed navigation, there is an unrestricted network. That is fine because there isn’t any unpartitioned data available to the fenced frame till that point.
* The fenced frame is able to request access to read-only cookies after navigation is complete. At that point the network will be disallowed so that there is no exfiltration of joined data across sites via either the network or persistent storage. Othe partitioned state like storage, service workers, network and http cache will continue to stay partitioned.
* The fenced frame is able to request access to read-only cookies after navigation is complete. At that point the network will be disallowed so that there is no exfiltration of joined data across sites via either the network or persistent storage. Other partitioned state like storage, service workers, network and http cache will continue to stay partitioned.
* **Top-level site’s etld+1**: This is required in the initial navigation request so that the PSP/FedCM servers can determine if this is a trusted top-level site that they are allowed to work with.
* This is fine because it does not exfiltrate any new information that the embedder itself could not have sent to the payment service provider's server.
* **Cross-site data**: Read only access to unpartitioned cookies after navigation is complete (document and subresources have loaded) and network is then restricted.
Expand Down