For the new deferred fetching (fetchLater) API (explainer, Spec PR), we would like to propose a new permissions policy deferred-fetch to help developers manage the quota for all fetchLater requests that can be fired within their documents.
Specifically, the main motivation is that, without any constraints, every frame can queue an unlimited number of fetchLater requests, which may use up network resources. However, unlike other types of JS-initiated requests, there is no way for users to be able to terminate pending fetchLater requests, as closing a tab will simply trigger sending all fetchLater requests on it.
While setting a quota for individual sites, we would also like to prevent (1) leaking cross-site activity and (2) abusing by creating additional frames.
For the new deferred fetching (fetchLater) API (explainer, Spec PR), we would like to propose a new permissions policy
deferred-fetchto help developers manage the quota for all fetchLater requests that can be fired within their documents.The discussion happened in https://github.com/WICG/pending-beacon/issues/87, and in the comment we proposed to add
deferred-fetchalong with its usage.Specifically, the main motivation is that, without any constraints, every frame can queue an unlimited number of fetchLater requests, which may use up network resources. However, unlike other types of JS-initiated requests, there is no way for users to be able to terminate pending fetchLater requests, as closing a tab will simply trigger sending all fetchLater requests on it.
While setting a quota for individual sites, we would also like to prevent (1) leaking cross-site activity and (2) abusing by creating additional frames.
@noamr @annevk @yoavweiss @nicjansma