Yoav Weiss, Nic Jansma, Ian Clelland, Carine Bournez, Sia Karamalegos, Andy Davies, Barry Pollard, Michal Mocny, Ming-Ying Chung, Noam Rosenthal, Sean Feng, Anne van Kesteren, Lucas Pardue, Rafael Libre, Andrew Galloni, Philip Tellis
Minutes
Yoav: Want to hash out things related to fetchLater API
... Anne has some questions regarding various restrictions on the API
Ming-Ying: Current open question is about limiting third-party usage of the API through something like Permissions Policy.
Yoav: Right now, this is behind background-fetch permission
Ming-Ying: In our current proposal, we agree to allow request to be sent after navigating away
... Otherwise the request ???
Yoav: Anne from the thread it sounded like this was not necessarily sufficient?
Anne: Two issues
... One is that background-sync as far as I know doesn't have multiple implementor interest (Chromium-only API)
... Using that permission for this new API doesn't seem good
... background-sync is enabled by default in cross-origin documents, doesn't seem good to us
Yoav: Can you elaborate on that?
... Specific permission is not necessarily critical to the use-case
... Being able to beacon data from cross-origin documents seems like an important piece
Noam: We're talking about background-fetch not background-sync right?
... background-fetch is letting Service Workers continue fetch when document is closed
... background-sync is e.g. every 24h getting data for the application
Ian: I thought we used background-sync for this, and also as a signal for reporting
... Using as a general "Can the browser send things out-of-band" permission?
... Not sure if it needs to be renamed?
Fergal: Previous discussions have been about background-sync, not sure what the code uses
Yoav: One discussion where we can dig further, but larger discussion is around enabling background fetches in cross-origin documents
... Is this an important use-case? Seems like it would be
... Why is that an issue from Anne's perspective?
Anne: Main issue is having it by default
... I think it should be opt-in
... We hold the top-level context responsible for resource usage
... Group them as far as limits go
... So we don't allow website to circumvent limits to have cross-origin documents
... In some cases fetches happen after user closes tab
... Given there's limits, seems like top-level context should have first shot at filling up limit
... They could deleage to cross-origin descendents
... Don't want them to be able to queue anything
Nic: A question to make sure I understand - cross origin documents, are we talking about iframes or cross origin resources?
Noam: iframes
Nic: Other cross origin documents, ok
Anne: other documents
Ming-Ying: Question about background-sync or background-fetch, the suggestion was to use background-sync
... According to the user-interface, the permission is relevant
Fergal: On the cross-origin thing, if I'm a developer, and I examine the permissions policy and find out fetchLater is disallowed, I'm just going to send all my data eagerly instead
... No limit how much data I can send with fetch()
... Seems worse for the user
Anne: Depends on what the user is going to do after they close the tab
Fergal: Imagining this scenario where there's vast quantities of data wanting to be sent after the tab is closed
... Are we defending against something that isn't likely to happen?
Anne: Is there a shared-limit for the tab, in that case we don't want X-O documents to take over limit
Yoav: Until now we didn't talk about shared limits for the tab, limit per reporting origin
... in the past we have seen, X-O resources on the page compete with each other on the quota for the sendBeacon
... sendBeacon was quota up until the number of seconds during which the browser is sending the beacon. Here's a longer quota, so we want reasonable limits on a per-reporting-origin basis.
... Maybe there's room to have document-wide or tab-wide limits
... We want to (1) make sure API -- people don't send to much data on per-origin basis
... (2) we want to protect users from abuse with a significantly higher per-tab quota
Anne: Just-origin doesn't cut it, has to be top-level plus reporting origin
Yoav: Not talking about X-O communication here
Noam: Risk is those things accumulate, and you can't stop them by just closing a tab
... Close a bunch of tabs, and you accumulate things that will happen where you have no control of anymore
... Permissions-Policy does make sense here, enable by default but you can turn it off for third-parties
... All of this network activity you can't control as you're closing tab, not related to fetching inside of the document
Fergal: Another point Anne touched on, if we have a per-origin quota, you have unlimited quota, unlimited iframes on origin you want. Queue that data under that quota.
Yoav: If we have a top-level site plus reporting origin, then you need multiple origins, infra cost.
Nic: Unless you limit to top-level reporting origin (plus document TLD)
Anne: I was thinking that top-level origin of frame
Noam: Per register-able domain for the target URL, and per origin of the document
... Otherwise you can do subdomain trick and fight other RUM providers
Anne: If there's a limit for top-level origin shared amongst the tab, how does that work?
Noam: You need that, plus a smaller quota for the reporting TLD
Anne: A single top-level origin would have embedded both
... Are they in sub-documents or scripts?
Yoav: Scripts
Anne: That's why you're talking about target origin
... Overall limit is for top-level origin, then smaller for target origins
Fergal: 64K for top-level origin and 64K for everyone else
Noam: One is reporting origin and one is the reporting sink
... 256K for top-level document origin, 64K for target
Fergal: What happens if you use it in a subframe?
Noam: You might fail
Anne: In case where we allow 4 buckets in top-level site, and subframe as Permissions delegation, then subframe could fill up all of those buckets in theory
Yoav: Thing we have to bear in mind, that delegation has deployment costs
... We need to see the benefits we're getting from those limits outweigh the costs
Fergal: Maybe revive, idea to send stuff early if buffer fills up, you flush it
... No guarantee when things are sent
Yoav: We changed model so queuing up extra data will fail and developers can do that on their own
Noam: About later, this is on top of fetchLater(), buffering fails, you have userland pending beacon that does this buffering stuff
Fergal: That inverts the order
... Lose that data or send it early
... Have this other data that gets queued, and now you're sending data where buffer is full, and still haven't sent data from earlier
Noam: Doesn't invert order, stack
... I don't think we can do what Yoav is saying, if global quota for the tab, and no Permissions Policy, X-O frames can detect which RUM providers you have on top-level frames by trying to send to them
... Opt-out somehow
Nic: detection is trivial today
Yoav: Not across frames
Noam: If we have a global quota we need a permission policy
… Agree that this inverting things from a queue to a stack is not great
Fergal: You can still queue. You can’t guarantee that you’d empty the buffer faster than someone else filling it. Unclear how that would work
Ian: Is there an open thread on what the quota model should be
Noam: long thread on GH
Ming-Ying: have an issue. I’ll reopen it.
Ian: Is there room for experimentation on this, or do we need to decide on this after shipping?
Noam: The numbers can change later. People would get “quota exceeded” error
… Also, does the quota need to be specified? Can we have different quotas for mobile/desktop? Why should this be interoperable?
Anne: If you were to write a library that uses this, you’d want to know what the values are roughly
Fergal: so a minimum value need to be specified
Noam: defining the minimum to 64K can be a good start and then Chromium can play with it
Fergal: But would the permission policy be on or off by default?
Noam: Has to be off
Yoav: Could be interesting to look at different use-cases and which would be significantly harmed by off-by-default
... Suspect RUM providers won't be affected because they're injected as a top-level script
... Ads or third-party widgets under that could be a hard time convincing to give a permission, or resort to other means
Fergal: Have any partners to talk to?
... Not even about convincing these people, they have to be aware
Yoav: 3P have to convince their embeds they have permission to use
Fergal: A load of people who don't know how internet works
... Embed ads on their blog or whatever
... Seems like couldn't be used by a lot of ads
Nic: Boomerang has a way of being loaded through a non-blocking iframe. We still use this in modern browsers. Would dynamically created about:blank iframe be cross-origin?
Anne: that’s same origin
Ian: If you’re creating the iframe, you can add the allow attribute dynamically
Yoav: if that's the case, not a problem and you can add a Permissions Policy
... Useful to talk to people actually doing this and see which case aren't allowed by off-by-default policy
Barry: What do we gain if we don't say embed this iframe, but embed this script and we'll handle it?
Noam: Many times ad providers tell pages what to do, and not the other way around
Anne: I think without it, in principle, a security issue where different origins can figure out what other origins are doing. One origin fills the limit, another origin can figure out.
... Top-level origin includes whatever script and trusts them, that script can do anything
... Seems like sketch practice to do
Yoav: How most of the internet work
Anne: At least we should make sure security model, try to uphold some basic things
Yoav: I think this would be a hurdle for 3P providers considering moving to isolated iframe vs. injecting a script, this would be a hurdle on the way there
Barry: This would encourage doing the sketchy thing
Yoav: Agree if we have a top-level, limits are triple-keyed (top-level origin, iframe origin, reporting origin), or we need some form of enforcement that flows from the top-down
Anne: With many-keying thing I think you still want an overall limit, still have problem
Yoav: But you won't know which other RUM providers, know top level quota was use,d but don't know of anyone specific
Fergal: Assumes sub-quotas are smaller than the overall quota
Noam: Yes
... Obfuscates the problem a bit
... In the end you want a single tab to control this
... I don't think I've heard any alternatives to an off-by-default Permissions Policy here
Yoav: If we go back to triple-keyed, each quotas in IFRAME are tied to reporting origin in ways that they cannot tell if anyone else in another IFRAME is using same reporting origin
... 64K for each reporting origins, overall quota for 640K for entire tab
... In this scenario, each frame can only know if quota was exhausted by everyone else, but doesn't know which frame exhausted the quota.
... Too much of an info leak?
Noam: Let's them know someone else used fetchLater()
Yoav: If multiple providers are using it, it seems
Noam: Could tell you top-level origin is logged in for example
... If page only turns on RUM if logged in
Yoav: Infer specific behavior on specific scenarios on specific sites
Noam: Top-level tab does a lot of fetchLater() when logged in but not when it's not
... 3P iframe tries to fill quota, guesses they're logged in
Fergal: Site has to upload full quota on all 10 64Ks
Noam: Only has to fill one, IFRAME has to fill all the rest, then it can determine someone
Fergal: Give each frame, has a limited quota, then it can't fill out the other 9 things
... Don't want one frame to fill up all of the slots
Yoav: Off-by-default Permissions Policy comes in as a guard
... Deployment issue for third-parties
... If we don't do that, top-level quota would be a privacy issue
... If we don't do that, we're risking abuse when user closes a tab
Barry: What is the point of this quota? If closed tab, we shouldn't be sending a ton of data for hours
... Can we limit sending beacon time, N minutes
Yoav: Then you're losing data. Also if someone else exhausted the quota.
Fergal: When you call fetchLater() we can say "no you can't" and the script can do something else
... When the page isn't closed, and you're queuing data, and we return false, you can send data now
Anne: I don't agree it's a deployment problem
... Most solutions have some kind of script in place in top-level origin
Yoav: Potential problem
Fergal: For RUM providers
Yoav: For 3P widgets, may be an issue
... If everyone injects top-level scripts, and no one intends to stop, then maybe this isn't a problem
Fergal: Are ads created by top-level scripts? They could communicate between frames
Yoav: If they're creating IFRAMEs, they could allow a quota within in those IFRAMEs
Fergal: Maybe a problem where people have casually created multiple FRAMEs in a page, and they put ads or RUM in a non-top-level frame and they haven't given it permission
Barry: If their script is changing to use fetchLater() then they can change their script
Ian: We've added permissions policies for things like Full Screen where YouTube had to update their loading snippets
Yoav: This would be a hurdle to adoption for those
... I think it'll be useful to talk to those 3Ps
... Any one of those widgets if they're telling people to embed IFRAME directly then they have to change their advice, only work for new deployments
Fergal: If I want to embed YouTube in my site, I know where I dropped it, I can change it. But if it's embedded by script, it has to know where to add the frame
Yoav: What would be a good list of action items?
... Open an issue to discuss this specific issue
... Other than that it would be good to talk to 3Ps that are likely to be affected by decision
... See how sad they would be about it
... Another option, we have an Origin Trial running for this.
Fergal: Very close to starting to run
Yoav: Would it be possible to add a counter for how many bytes are being queued up
... See if this is an issue?
... If no one is queuing up more than 100K
Fergal: We could look at sendBeacon and fetch(keepalive:)
Yoav: Would need to know entire lifetime of the document, how much do they send
... Assuming no duplicate data, at end of lifetime, how much would that be
... Insert data into this discussion
... sendBeacon() and fetch(keepalive:) will give us data about what people are doing in the wild
Nic: Boomerang can send up to 50K, so could be approaching the 64K limit, post compression. Some sites have lots of resources
Philip: Error beacons can contain stack traces as well
Yoav: So a 64K limit would be tight?
Nic: Can look at the data
Fergal: Would you put your errors through this API?
Nic: Ideally yes. We’d love to send everything in a single beacon, including errors
… most other providers don’t collect resource timing
Andy: Yeah, we don’t collect them. Aggregate it on the client
Ian: Should we add a counter for any usage in cross origin frames during the OT?
Fergal: easy to log that
Yoav: sendBeacon in cross-origin iframes can also be an indication