You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current private network access check algorithm states the fetch client's policy container's IP address space should be compared against the connection's IP address space. This is all well and good when the fetch client has a correct policy container, as is the case for documents and most workers fetches (#82).
PNA checks are also supposed to apply to service worker soft update fetches so as to avoid a bypass. The current implementation in Chromium uses the last fetched (exact spec term unclear) service worker's policy container's IP address space as the client IP address space.
Unfortunately, the service worker soft update algorithm sets up a null fetch client, which entails that the PNA check cannot apply. This is a known issue (w3c/ServiceWorker#849, w3c/ServiceWorker#1447). Until it is resolved, this part of the spec is underspecified.
In the meantime, we should non-normatively explain what the correct behavior should be in spite of this shortcoming.
The text was updated successfully, but these errors were encountered:
The current private network access check algorithm states the fetch client's policy container's IP address space should be compared against the connection's IP address space. This is all well and good when the fetch client has a correct policy container, as is the case for documents and most workers fetches (#82).
PNA checks are also supposed to apply to service worker soft update fetches so as to avoid a bypass. The current implementation in Chromium uses the last fetched (exact spec term unclear) service worker's policy container's IP address space as the client IP address space.
Unfortunately, the service worker soft update algorithm sets up a null fetch client, which entails that the PNA check cannot apply. This is a known issue (w3c/ServiceWorker#849, w3c/ServiceWorker#1447). Until it is resolved, this part of the spec is underspecified.
In the meantime, we should non-normatively explain what the correct behavior should be in spite of this shortcoming.
The text was updated successfully, but these errors were encountered: