- "Limited bits" subset
- CHIPS integration - use cases? Requirements?
- Other topics?
- 5min FYI on FPS+rSA+rSAFor I2Ses, and submission process.
Chair:
Scribe volunteer: johannhof@google.com
Slides: WICG: April 26 2023
(Please sign in at the start of the meeting)
- Johann Hofmann (Google Chrome)
- Kaustubha Govind (Google Chrome)
- Chris Fredrickson (Google Chrome)
- Helen Cho (Google Chrome)
- Ralph Brown (Brown Wolf Consulting)
- Helena França (Google)
- Ishita Bhattacharjee(Google Chrome)
- Shuran Huang (Google Chrome)
- Allan Spiegel (Adobe)
- Bel Curado (Google)
- Presentation by Helen Cho, Status update on FPS
- Sent out I2S for SAA / rSAFor in the context of FPS
- Will ramp up in Chrome 113 at 1% and proceed to 100% eventually
- Multiple components to FPS
- Submission process in GitHub. Submissions are live now. Will be merged on a weekly basis.
- In the browser there will be user controls for toggling FPS, and see what sites they visited are in an FPS.
- Call to action to test and integrate with FPS, developer material and documentation is available and more will be published.
- Questions?
- Ralph: FPS is expressed as a .well-known resource, correct?
- Chris: Yes, there’s a requirement to host a .well-known file.
- Ralph: That is validated when it is submitted to GitHub to validate it’s coming from the right domain?
- Chris: You mean the submission?
- Ralph: Yes.
- Chris: There’s no technical way to ensure that the GitHub account is the technical owner of the domain, but we can check if there’s a mismatch between what the site owners and the PR say.
- Ralph: What happens if the .well-known resource gets out of sync with the data in the repo?
- Helen: The .well-known file has to be maintained across the entire lifetime. Subsequent PRs will fail and we’ll notice that and notify the original submitter of the file that is failing.
(switching to Topic #2 as Don Marti isn’t present to talk about #1)
- CHIPS integration
CF: This is talking about FPS and CHIPS integration. It used to be that the partition key for CHIPS was scoped to the entire FPS rather than just to the top-level site of the embed that set the cookie. With the changes we made that’s no longer in place. We’re looking to get feedback on whether this kind of thing is still needed/useful for people. Chris: Waiting on people to chime in with questions/comments.
KG: This is probably relevant to folks who are in a SaaS/vendor relationship with a service helping customers that have multiple sites, e.g. consent management integration. There’s at least one use case called out in #94, for A/B testing use cases.
CF: Don’t know all the specifics about the A/B use case, but: The Shared Storage proposal does have an example for how to do A/B testing with it. A bit limited for privacy reasons, but if you can render the content in a Fenced Frame or use Private Aggregation for your testing then this is something they could use.
(Ralph asks about the FPS GH repo in chat, Helen linked to submission guidelines and added some explanation)
KG: For context, Ralph is involved in an effort that uses this .well-known resource and we’re looking to see if we can work on an approach that involves this without adding a huge barrier for site authors.
- Limited Bits subset
CF: This is a proposal that allows sites to share a limited number of bits, want to get more feedback on this and see if folks would have use cases for this and what the constraints on those are.
HC: The assumption in that proposal is that FPS isn’t solving all the use cases that developers need, e.g. through the domain limit. Broader question we’re trying to ask is what are those use cases, and then this may be the solution.
KG: The reason people came up with this is the domain limit and larger organizations didn’t see their use cases represented anymore. This is one of the use cases that Don Marti found. In this case we wouldn’t have a numeric limit anymore but limited bits. One of the use cases he was thinking about was consent management.
CF: Nobody on the queue, limited discussion and attendance on the call. We should probably cut this call short and want to invite you to reply to the threads we mentioned.
Allan Spiegel: Follow-up to Ralph: If there’s a mismatch you can’t create a PR. Still have a mismatch. What happens then?
HC: In the beginning, the well-known file needs to match the submission. Only those who control the domain can do that. It’s possible of course that someone modifies that file later. At this point the FPS list has the submission. If there’s a mismatch, subsequent PRs by other developers will error, which will let us know that we should reach out to the owner of the domain that failed.
RB: So you validate all domains on the list at every PR?
HC: We should probably follow-up offline, not sure about all the details.
KG: Engineer who works on this isn’t on the call.
RB: You have mergers etc. all the time. What happens if things get out of sync temporarily. My suggestion is a solution to what happens then.
RB (in chat): I assume /.well-known/first-party-set will be registered with IANA https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
CF & Johann Hofmann: We’ll do that. Thanks for the suggestion.
KG: We are updating the .well-known/first-party-sets file to now require the .json extension, and also have the site author specify the content type - see issue#149. Without the extension, legacy servers are failing. The GPC spec folks ran into this. Ralph - I’m not sure if you’ve seen this with your trust.txt work?
RB: Not really, since it’s already specified as a .txt file
AS (in chat): sounds like one unresponsive domain that doesn't fix a mismatch can stop all changes/additions to the git repo
CF: Good callout, Helen, do you know what the policy says for this case? If all PRs are blocked on a failing check from some unresponsive company?
HC: We can see why the check is failing, i.e. if others are failing we can still manually merge if the domain itself is failing. We can reach out to the owner.
AS: If domain A after passing checks modifies their .well-known file after passing checks what happens?
HC: Do you mean do they get booted out?
RB: My understanding is that the GH repo is the source of truth. Everything there has passed tests, if a .well-known resource gets modified later.
AS: So the well known doesn’t actually do anything?
HC: For one, it’s for transparency. You attest that you’re the owner of the domain. You want to make sure it’s stable but we’ll only enforce if it causes PRs to fail along the line.
CF: Intentional choice to ensure that if something happens to the well-known file the GH list is still valid.
JH: We may want to have a different workflow for GitHub CI runs, vs. a per-PR check. You may not have to validate the entire list on individual PR checks. (It’s possible that’s already the case, but we are fuzzy on the details and can check with the engineer who implemented it).
CF: Also a bit fuzzy on the details but I don’t think that was done.
RB (in chat): It is better to do it at merge than at PR
RB: Have you thought about the FPS repo being a single point of attack if someone wants to exploit FPS?
CF: All changes get mirrored into an internal repo, at that point an engineer will check the contents and publish only if it looks good. So that could be a potential opportunity to defeat such an attack.
RB: Ack. Just looking for weaknesses.
CF: No one else on the queue. Happy to give people time back. Feel free to submit additional feedback.
RB: One more Q: How are you promoting this with developers? Any submissions so far?
HC: We were in testing so far. We had a few submissions and a few entries on the tester list. Live submissions only started on Tuesday. We are planning outreach of course, including with developer documentation.
RB: Just wondering if there are ways we can assist.
HC: Happy to get help, please feel free to let us know.
CF ends meeting