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

Add a consideration for weakening security boundaries #85

Merged
merged 2 commits into from
Mar 29, 2022
Merged

Add a consideration for weakening security boundaries #85

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f0f5a21
Add a consideration for weakening security boundaries
johannhof Feb 23, 2022
24de7ec
Replace 'trust' between sites in an FPS with a clearer definition
johannhof Mar 15, 2022
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
12 changes: 12 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -38,6 +38,8 @@ of the [Privacy Community Group](https://privacycg.github.io/).
- [Signed Assertions and set discovery instead of static lists](#signed-assertions-and-set-discovery-instead-of-static-lists)
- [Self-attestation and technical enforcement](#self-attestation-and-technical-enforcement)
- [Origins instead of registrable domains](#origins-instead-of-registrable-domains)
- [Security and Privacy Considerations](#security-and-privacy-considerations)
- [Avoid weakening new and existing security boundaries](#avoid-weakening-new-and-existing-security-boundaries)
- [Prior Art](#prior-art)
- [Acknowledgements](#acknowledgements)
- [Appendix](#appendix)
Expand Down Expand Up @@ -342,6 +344,16 @@ This origin-defined approach has additional complications to resolve:
These complexities are likely solvable while keeping most of this design, should browsers believe
this is worthwhile.

# Security and Privacy Considerations

## Avoid weakening new and existing security boundaries

Changes to the web platform that tighten boundaries for increased privacy often have positive effects on security as well. For example, cache partitioning restricts [cache probing](https://xsleaks.dev/docs/attacks/cache-probing/) attacks and third-party cookie blocking makes it much harder to perform [CSRF](https://owasp.org/www-community/attacks/csrf) by default. Where user agents intend to use First-Party Sets to replace or extend existing boundaries based on *site* or *origin* on the web, it is important to consider not only the effects on privacy, but also on security.

Sites in a common FPS may have greatly varying security requirements, for example, a set could contain a site storing user credentials and another hosting untrusted user data. Even within the same set, sites still rely on cross-site and cross-origin restrictions to stay in control of data exposure. Within reason, it should not be possible for a compromised site in an FPS to affect the integrity of other sites in the set.

This consideration will always involve a necessary trade-off between gains like performance or interoperability and risks for users and sites. User agents should facilitate additional mechanisms such as a per-origin opt-in or opt-out to manage this trade-off. Site owners should be aware of the potential security implications of creating an FPS and form only the smallest possible set of domains that encompasses user workflows/journeys across an application, especially when some origins in the set opt into features that may leave them open to potential attacks from other origins in the set.

# Prior Art

- Firefox's [entity list](https://github.com/mozilla-services/shavar-prod-lists#entity-list)
Expand Down