Contact emails
cth...@chromium.org
Explainer
No information provided
Specification
https://wicg.github.io/background-fetch
Summary
Background Fetch requests will now require that the service worker's origin has the necessary Local Network Access (LNA) permission in order to send requests to local or loopback servers.
This aligns Chromium's implementation with the intent of the Background Fetch spec (that such requests go through the Fetch spec and have the same security policies applied to them, in this case Local Network Access checks). This prevents sites from bypassing LNA checks by using Background Fetch instead of regular Fetch.
For enterprises, you can use existing Local Network Access enterprise policies in the same way you previously would have for regular Fetch API requests from service workers (see [LocalNetworkAccessRestrictionsTemporaryOptOut](
https://chromeenterprise.google/policies/#LocalNetworkAccessRestrictionsTemporaryOptOut), [LocalNetworkAccessAllowedForUrls](
https://chromeenterprise.google/policies/#LocalNetworkAccessAllowedForUrls), [LoopbackNetworkAllowedForUrls](
https://chromeenterprise.google/policies/#LoopbackNetworkAllowedForUrls), [LocalNetworkAccessPermissionsPolicyDefaultEnabled](
https://chromeenterprise.google/policies/#LocalNetworkAccessPermissionsPolicyDefaultEnabled), and [LocalNetworkAccessIpAddressSpaceOverrides](
https://chromeenterprise.google/policies/#LocalNetworkAccessIpAddressSpaceOverrides)).
Blink component
Blink>BackgroundFetch
Web Feature ID
local-network-access
Motivation
This fixes a security issue where Background Fetch unintentionally bypasses security policies such as Local Network Access checks.
Initial public proposal
No information provided
TAG review
No information provided
TAG review status
Not applicable
Goals for experimentation
None
Risks
Interoperability and Compatibility
If the service worker's origin does not yet have the requisite Local Network Access permission, the background fetch request may fail. However, overall usage of Background Fetch is extremely low. We considered completely removing the ability for Background Fetch to make local network requests, which would be more disruptive. Treating Background Fetch requests the same as fetch() calls from a service worker context was deemed an appropriate middle ground.
Gecko: Shipped/Shipping (
https://github.com/mozilla/standards-positions/issues/1260) Firefox is shipping LNA but does not support the BG Fetch API
WebKit: No signal (
https://github.com/WebKit/standards-positions/issues/520)
Web developers: No signals
Other signals:
WebView application risks
Does this intent deprecate or change behavior of existing APIs,
such that it has potentially high risk for Android WebView-based
applications?
LNA checks are not enforced in WebView.
Debuggability
No information provided
Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
No
LNA is not enforced in WebView.
Yes
Flag name on about://flags
No information provided
Finch feature name
BackgroundFetchLocalNetworkAccess
Rollout plan
Will ship enabled for all users
Requires code in //chrome?
False
Tracking bug
https://crbug.com/455486148
Estimated milestones
| Shipping on desktop | 154 |
| Shipping on Android | 154 |
Anticipated spec changes
Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github
issues in the project for the feature specification) whose resolution
may introduce web compat/interop risk (e.g., changing to naming or
structure of the API in a non-backward-compatible way).
None. This brings Chromium's implementation into alignment with the intent of the Background Fetch spec (which delegates security policy enforcement to the Fetch spec).
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/6225598451154944?gate=6680716673941504