Hi site-isolation and worker people,
I fixed a security bug (
https://crbug.com/517484284) to block PDFs from having access to storage. I did this by adding a call to `
CanAccessDataForOrigin`. The unintended side effect is
http://b/528332884, where a shared worker now no longer has access to origin private file system (and I assume various other types of storage that it should have).
It seems to require both of these headers (from server.mjs in the repro)
'cross-origin-opener-policy': 'same-origin',
'cross-origin-embedder-policy': 'require-corp',
I do not have a good understanding of what these do in this case but this quote from the bug (which seems to be AI-written) seems important.
A worker process never commits an origin, so for a freshly created SharedWorker host CanAccessDataForOrigin(worker_process, page_origin) is false, and the new check denies OPFS. A DedicatedWorker is allocated in the creator frame's process (which has committed the origin), so it is unaffected.
Assuming this is actually correct, should ShWs be doing something different to ensure that their origin is correctly recognized by CanAccessDataForOrigin?
I have several other bugs in my inbox related to isolating PDFs (e.g.
https://crbug.com/517634450) and I fear that fixing them will break workers even further.
Thanks,
F