Attendees:

• Aaron Selya (Google Chrome)
• Ari Chivukula (Google Chrome)
• Johann Hofmann (Google Chrome)
• Chris Fredrickson (Google Chrome)
• Dan Veditz (Mozilla)
• Dylan Cutler (Google Chrome)
• Mike Taylor (Google)
• Anusha Muley (Google Chrome) 
• Matthew Finkel (Apple)
• Shivani Sharma (Google Chrome)
• Erik Anderson (Microsoft Edge)
• Kaustubha Govind (Google Chrome)
• Steve Becker (Microsoft)
• Yi Gu (Google Chrome)
• Ben Kelly (Google Chrome)
• Vincent Scheib (Google Chrome)
• Victor Tan(Google Chrome)

Slides: https://docs.google.com/presentation/d/1VcJ6lX2R74IpZve0fmxoZ1P_4SiwvIR_mFDQDxo6YAs/edit?usp=sharing

Notes

• [Welcome]
• Problem: embedded sites don't control where they're embedded. Some functionality depends on unpartitioned cookies; generally supported by Storage Access API (SAA). But SAA requires a visible iframe that can execute JS. Some use cases don't meet that requirement.
• Status quo:
  • Mozilla proposal: Top Level Storage Access API
  • Chrome proposal: requestStorageAccessFor
    • Restricted to Related Website Sets in Chrome
• Why limit rSAFor to RWS in Chrome:
  • Prompt might be interpreted as endorsement by top-level site of embeddee. Embeddee has no way to prevent a prompt from associating the pair of sites.
    • Security implications here; top-level site could attack embedded party. Initial version of rSAFor requires use of CORS to mitigate that concern.
  • Prompt spam
  • Question: is rSAFor viable outside of RWS, with a prompt?
• Solution requirements:
  • (Embedded) sites should have ability to allow prompts when embedded on other sites
  • Barrier for adoption should be low
  • Should not require an external dependency
• Ideas:
  • Well-known file
    • Would contain a list of top-level sites that are allowed to call rSAFor on this site's behalf
    • Pros:
      • Gives embedded sites control
      • Top-level sites can predict behavior in advance
      • Backward compatible with current behavior
    • Cons:
      • Public resource, may not be ideal in all cases
      • Requires caller to process entire list of sites
      • Static resource
  • API endpoint
    • Pros:
      • Gives scontrol
      • No need to ingest entire list, response just includes single site
      • Backward-compatible
      • Dynamic
    • Cons:
      • Other sites can't predict behavior
      • Not as private
      • Higher cost of adoption
    • Matt Finkel: are you thinking of a CORS preflight-like mechanism?
      • Something similar, maybe even simpler.
    • Ben Kelly: any developer feedback on these proposals? How should people estimate QPS? I hear adding headers is hard, this seems harder. Can't do an API endpoint on github pages, whereas I could do a well-known file.
      • Haven't brought this to developers yet. Some facilities in browser exist already as a caching mechanism, e.g. permission lifetimes (30 days for Storage Access API).
    • Shivani: not clear who is creating this list. Embedder or embeddee?
      • Embeddee. They decide who gets to create the prompt.
      • Could this also be solved by a permissions policy in the response?
        • That requires an iframe/document that could provide the permissions policy. This API is addressing the case that does not have an iframe.
• Other solution ideas:
  • Lightweight FedCM
  • Storage Access Headers
• Discussion:
  • Ari: The Well-Known file and API endpoint could be merged into one solution, if you had an API endpoint that returned a JSON list of approved origins it could be populated from a static file at that path or dynamicly generated based on the API call params
  • Yi Gu: the FedCM has a lot of endpoints. What does the browser show if this API endpoint isn't responsive immediately? Could lead to a poor user experience
    • That's a concern. Anything that's fetched will run into this problem. Harder to show UI here than in the FedCM UI.
  • Ben Kelly: re: permissions lifetime, need to have a revocation path for the site in case the embeddee realizes it's under attack and wants to revoke permission.
    • We need to reconsider the security model overall for rSAFor, we developed it early on and designed it using CORS, but we now consider that insecure. We now have a better model, Storage Access Headers (https://github.com/privacycg/storage-access-headers) has a better security model that we could use here.
  • Ari: does this go in the same permission cache as rSA? Is it the same permission?
    • That's the intent. Right now they're separate permissions, we made that decision back in the day but are rethinking that now.
  • Zainab: size limit for this?
    • Asking sites to explicitly indicate which sites are allowed to create prompts will help a bit with that. A dynamic endpoint that always returns "true" is more complicated.
  • Ben Kelly: dynamic endpoint, what about customers that have a huge list? Wildcard?
    • Sounds like a resonable approach to allow, for customers that aren't worried about these attacks.
  • Mike Taylor: do we have evidence that sites actually care about the reputational harm problem? Is this a non-hypothetical concern?
    • This is an anticipatory concern, if we were to make this API available outside of RWS. Haven't heard specific feedback from sites.
    • Ben Kelly: security concerns seem more tangible. If you solve those, does this go away?
    • Johann: the permission would still be granted. Storage access headers would allow the embedded site to refuse to use the permission, but it would still be there.
    • Ben: why give the user prompt and user friction if we can determine beforehand that these sites will never work together?
    • Johann: that's what this proposal is all about - trying to find a way to beforehand to prevent the prompt.
    • Ben: Could be another storage access header semantic.
    • Johann: tradeoffs are still the same; still a performance problem, embeds still have to list the sites that they'll work with.
  • Matt Finkel: sounds a lot like CORS. Want to make sure the cross-origin server wants to do the thing the other site is trying to do. Maybe some sites don't support CORS. You're envisioning creating a new thing.
    • Discussion on this in Storage Access Headers, reasoning why CORS should neither be sufficient nor necessary. Actually increases the attack surface if we were to integrate this feature (or Storage Access Headers) with CORS.
  • Zainab: what drives the preference for keeping the list of sites private?
    • Partners telling us that they don't want to expose the long list of their clients. Well-known file conflicts with this.
    • Zainab: even a dynamic endpoint is vulnerable to this, you could just crawl and query all the things you think might be on the list.
  • Ben Kelly: do you forsee supporting differences in behavior based on the credentials in the request? Is this a credentialed request?
    • Could be an option where the well-known file is credentialed, but this gets messy with side channels.
    • Charlie: could have an agreement of deterministic hashing system and just list the hashes in the well-known file. Involves an exponential number of client hashes but it's a different kind of attack. Just depends on what is the threat and what you're trying to protect. It's public at some level, so we can't protect it absolutely.
    • Ben Kelly: there's a difference between user privacy and web site privacy.
  • Ari: understand the temptation of having the call be credentialed to auth the user, but it feels like a bad thing to overload.
  • Nicolas: If the resource being embedded knew <...> could it just request access for itself?
    • Non-iframe resources are the big problem, they can't call requestStorageAccess and get the permission themselves. 
    • Example of this issue: https://github.com/privacycg/storage-access/issues/72
  • Dan Veditz: how annoying will this be when there are N embedded resources that want this and each prompt the user?
    • This is why the first-party should be in control of that UX.
  • Mike Taylor: re: site not wanting to disclose the people it trusts. But the opposite isn't true? Wouldn't be unreasonable to say "if you're comfortable with your users seeing these sites, you just have to do this". But I can understand both sides.
  • Ari: credentialed-ness impacts caching. Can't cache uncredentialed requests, have to validate every request.
    • Won't be credentialed.
    • Ari: is there an interest in caching the positive cases as well as negatives?
    • Seems like a good idea. Ideally the prompt wouldn't be shown on a massive scale anyway. Some use cases still require something like this (and anything new that we could build would look similar to this), but we still expect that the volume of usage would be limited.

Queue