-
Notifications
You must be signed in to change notification settings - Fork 76
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Adding meeting minutes from TPAC session
- Loading branch information
Showing
1 changed file
with
65 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,65 @@ | ||
| **Agenda** | ||
| - [Link to presentation deck](https://docs.google.com/presentation/d/1K6surspD72-sdkVdRy6KxOA3uipj6XXB9lF_ynOaeX4/edit?usp=sharing) | ||
| - Chair: Ishita B | ||
| - Scribe volunteer: Helen Cho | ||
|
|
||
| **Notes** | ||
| - Johann: FPS is now RWS (Related Website Sets). Expect overview and demo and next steps. Overview: we renamed FPS to RWS to better represent the intent of the API. 1P has many other connotations (like security-related), don’t want to give wrong impression. New name fits better. Numeric limit has been increased from 3 to 5. Currently rolling out to 10% in Chrome Stable. Also rolling out SAA outside of RWS in Chrome 117+ (using prompts). Also published explainer to extend SAA to unpartitioned storage (emphasis on storage). Currently SAA can only be used for cookies, but many developer requests to extend to unpartitioned storage. A couple of hairy details to figure out. If you want to test or actually submit, submission process is operational and open for submissions. To make things even easier, we have an RWS JSON generator tool - can enter sites you want to put in a set and the tool will generate corresponding JSONs for you. | ||
| - Ben: how many developers are actually using sets? | ||
| - Helen: about 5-6. Beauty of FPS (RWS) is that you can see how many sets have been created | ||
| - Chris: quick refresher on what RWS looks like. Reorganized things so that it’s not a flat list of sites. Distinct subsets that sites are grouped into - ccTLDs, service sites, associated sites. Declaring site into a subset imposes certain restrictions (enforced by submission process in GitHub). There is also a primary site in the set, which is separate from subsets. Once you have declared a RWS, the way that you use it is through requestStorageAccess or requestStorageAccessFor (the latter is a special API geared towards the top-level). rSA method is called from a cross-site iframe, embedded in a site that’s in the same RWS. If it requests the access, and all the appropriate security checks have passed, the request will be auto-granted by Chrome (no prompt). rSAFor method is geared for the other direction (1p requesting on behalf of embed). Top-level and embedded site must be part of the same site for the auto-granting to occur. | ||
| - Chris: Public GH repo where you can create a pull request (there is also a tool to help you structure the JSON properly). Can declare your set primary and and any of the subsets. GH will run a series of checks - none of the sets can overlap + established a .well-known file. There are also subset-specific technical checks - like size of associated subset. Once that PR has been approved and merged into GH repo, Chrome will ingest periodically and ship to Chrome clients. At this point, websites can see benefit on real users’ machines | ||
| - Matt Finkel: for SAA requests not in a set - is that a prompt? | ||
| - Chris: yes | ||
| - Chris: Demo time | ||
| - Everything happens in embedded iframe. Checks document.hasstorageaccess. If true, nothing needed. If false, <questions> | ||
| - Explicit API call needed to grant permission | ||
| - Nuance on how we handle navigations. | ||
| - Thomas Steiner: there is a case in the FPS repo (https://www.bild.de/.well-known/first-party-set.json) where a site seems like they shouldn’t have access / share data with other sites in the set based on the info they provide in `rationaleBySite`. Is this normal/expected behavior? | ||
| - Helen: What we wanted from the submission process was an objective and transparent process - why we rely on technical checks. Associated subset is for sites that don’t fit into the technical requirements for ccTLDs and service sites, but instead we have a numeric limit to mitigate scope of abuse. We also require rationale field to hold developers accountable to public and regulators - their brand/reputation is on the line. This is the first iteration of RWS we’re shipping - learning opportunity for Chrome, other browsers, ecosystem, others. | ||
| - Khushal: how might RWS extend to other web platform capabilities? | ||
| - Johann - possibly, would want to make sure goals are aligned | ||
| - Khushal: security properties question? | ||
| - Chris: not compromising on any cross-origin policy in any way. One of the reasons why we rely on an explicit API call | ||
| - Johann: name change communicates this as well. | ||
| - Matt - when you remove an associated site from a set and reintroduce it to another set, can that happen? | ||
| - Chris: you can immediately, but Chrome will clear cookies and take measures to prevent data leakage. | ||
| - Ben: Is that in the spec? | ||
| - Johann/Chris: yes. It’s recommended as a privacy/security consideration | ||
| - Johann: Next steps/improvements. Looking for feedback on some extended use cases: response header to opt-in storage access coming from embedded access (Chris will talk more about this in PrivacyCG tomorrow). Still thinking about how to best integrated with partitioned cookies - previous version “FPS” before relying on SAA had integration with CHIPS, but moved away from this for better interop. Question remains about how / whether common 3p partition could be shared across a set of sites (theoretically and in practice). Looking for feedback on ergonomics of both APIs and submission process as well. | ||
| - Johann: Also looking at possibly more ambitious API for login use cases. | ||
| - Vlad: unclear why we need explicit call. | ||
| - Chris: recent security improvements made to SAA. general idea is that “being in the same set” to imply “full trust” -- one site should not be able to CSRF attack to another. | ||
| - Johann: generally align on SAA for privacy/security reasons as the method for cross-site cookies. Has the nice benefit of aligning with other browsers on a single mechanism. RWS has added layer of no prompts in a clear user flow (not all browser agree but less compat issues with developers). | ||
| - Ben: have we heard from other browsers since we made these changes? | ||
| - Johann: can try my best, not necessarily opposed to the change. Doesn’t mean we’re fracturing the ecosystem too much. | ||
|
|
||
| **Attendees** | ||
|
|
||
| - Ari Chivukula (Google Chrome) | ||
| - Achim Schlosser (European netID Foundation) | ||
| - Sarah Nogueira (Criteo) | ||
| - Lionel Basdevant (Criteo) | ||
| - Ben Wiser (Google Android) | ||
| - Helen Cho (Google Chrome) | ||
| - Russell Stringham (Adobe) | ||
| - Theodore Olsauskas-Warren (Google Chrome) | ||
| - Ben Kelly (Google Chrome) | ||
| - Matthew Finkel (Apple) | ||
| - Sam Sneddon (Apple) | ||
| - Daniel Huigens (Proton) | ||
| - Ryan Kalla (Google Chrome) | ||
| - Kyra Seevers (Google Chrome) | ||
| - Mihai Cirlanaru (Google Android) | ||
| - Mike Taylor (Google Chrome) | ||
| - Thomas Steiner (Google Chrome) | ||
| - Aaron Selya (Google Chrome) | ||
| - Kaustubha Govind (Google Chrome) | ||
| - Ishita Bhattacharjee(Google Chrome) | ||
| - Maxim Salnikov (Microsoft) | ||
| - Jeffrey Yasskin (Google Chrome) | ||
| - Shivani Sharma (Google Chrome) | ||
| - Florian Scholz (Open Web Docs) | ||
| - Johann Hofmann (Google Chrome) | ||
| - Simon Hangl (Google ChromeOS) | ||
| - Taurence Bass (Google Chrome) |