- From: Yoav Weiss <yoavweiss@google.com>
- Date: Tue, 28 Nov 2023 07:39:30 +0100
- To: public-web-perf <public-web-perf@w3.org>, Anne van Kesteren <annevk@annevk.nl>
- Message-ID: <CAL5BFfVZO8OocsaNEUGkbbRLf0EVSk1drr4+eJa0+xHVrd-h2A@mail.gmail.com>
Minutes <https://w3c.github.io/web-performance/meetings/2023/2023-11-17/index.html> from the call are now published. Copying here for convenience: WebPerfWG call - November 17th 2023 Participants - 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 On Mon, Nov 13, 2023 at 1:08 PM Yoav Weiss <yoavweiss@google.com> wrote: > Hey folks, > > This Friday we're having an out-of-band meeting (due to TZs) to discuss > <https://github.com/whatwg/fetch/issues/1715> the `fetchLater` API with > Fetch folks. If you have opinions on the API, or are simply curious, feel > free to hop on the call! > > Cheers :) > Yoav >
Received on Tuesday, 28 November 2023 06:40:11 UTC