Closed Bug 1565199 Opened 5 years ago Closed 4 years ago

Ensure opaque response bodies cannot enter a COEP process

Categories

(Core :: DOM: Service Workers, defect, P1)

defect

Tracking

()

RESOLVED MOVED

People

(Reporter: annevk, Assigned: edenchuang)

References

Details

Attachments

(2 obsolete files)

Initially only windows and dedicated workers will be able to create COEP processes. We should ensure that when you get a reference to an opaque response via the Cache API in such a process we don't serialize the body of that response in that process. So the API remains identical, but what can be observed via sidechannel attacks changes.

This is also discussed at https://github.com/whatwg/html/issues/4764.

(A more difficult setup is probably required once we support COEP service worker processes as then you can get an opaque response and hand it to a non-COEP window via respondWith(). That will require more involved changes.)

Bugbug thinks this bug is a task, but please change it back in case of error.

Type: defect → task
Type: task → defect
Depends on: 1579992

There's 2 aspects to this bug.

  1. Make sure we never send opaque responses in an unsanitized form into a COEP process.
  2. What this means for the Cache.match() and Cache.matchAll() API surfaces.

I've spun off the latter to be bug 1603168. I think it makes sense for this bug to be about creating diagnostic assertions or similar safeguards at the IPC serialization boundary so that we get very obvious failures if any codebase changes start trying to do this.

Perry, perhaps 1 of comment 2 could be done after shipping, but it seems safer to cover it ahead of time.

Flags: needinfo?(perry)
Blocks: 1613061

(To be clear, this still blocks resab, just no longer directly.)

No longer blocks: resab
Assignee: nobody → perry
Flags: needinfo?(perry)
Assignee: perry → echuang
Priority: P2 → P1
Severity: normal → S3

It seems this is being addressed in bug 1642531.

Depends on: 1642531

Andrew, could you maybe double check that the logic we're adding for that bug addresses both aspects you mention in comment 2? That we have the relevant asserts in place to prevent opaque responses leaking in such a manner.

Flags: needinfo?(bugmail)
Attachment #9154157 - Attachment description: Bug 1565199 - P1 Remove the opaque responses for cache.match()/cache.matchAll() in COEP process → Bug 1565199 - Reject the opaque responses for cache.match()/cache.matchAll() in COEP process
Attachment #9154157 - Attachment is obsolete: true
Attachment #9155262 - Attachment is obsolete: true

The implementation of this bug is separated into Bug 1642531 and Bug 1603168.

Flags: needinfo?(bugmail)
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → MOVED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: