Define opaque-response blocking #1442
Conversation
annevk
added
security/privacy
|
@domenic thoughts on "ParseText" vs "create a classic script" + mock data? |
| <li><p>If <var>request</var>'s <a for=request>response tainting</a> is "<code>opaque</code>", | ||
| <var>response</var>'s <a for=response>status</a> is not a <a>redirect status</a>, and the | ||
| <a>opaque-response-safelist check</a> given <var>request</var> and <var>response</var> returns | ||
| false, then return a <a>network error</a>. |
There was a problem hiding this comment.
Perhaps we should make the redirect status check part of the algorithm?
|
So I think using ParseText here is pretty clean, especially since ParseScript seems to really prefer you giving it a Realm (even though it's used just for pass through). However there may be a slight issue here, which is that ParseText does early-error detection. I wonder if people really plan to do early-error detection (which IIUC involves pretty detailed JavaScript engine semantics) inside the network code where ORB is implemented. |
|
Does the spec cover the case where service worker synthesizing a response, so the synthesized response shouldn't be blocked by ORB if service worker's request passes? |
This is good enough for early review, but there are a number of issues that still need resolving: https://github.com/annevk/orb/labels/mvp. There are also some inline TODO comments. A PR against HTML is needed to ensure it passes the appropriate metadata for media element and classic script requests. We might also want to depend on HTML for parsing JavaScript.
|
Yes, if you look at https://whatpr.org/fetch/1442.html#http-fetch it currently handles service workers in step 5. Then in step 6, if there's still no response, it'll do a network fetch in substep 3. Then in substep 4 it'll do the opaque-response-safelist check. This is also clarified in a note at the end of step 6. |
This moves the check for empty MIME types before sniffing for JS + JSON. This brings it into alignment with the spec. (Which solves JS + JSON with proper parsing instead of sniffing, but also handles the empty MIME type check before doing so.) This is tested in WPT fetch/orb/tentative/unknown-mime-type.sub.any.js. The bug currently doesn't show, because our decision to inject en empty response hides the rejection from the test. Once ORB "v0.2" is enabled, the test breaks (without this fix). Spec proposal: whatwg/fetch#1442 Bug: 1178928 Change-Id: I0ed64ef0b66cccd6fdda0d3771b45e7dfc19a81d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4594337 Commit-Queue: Daniel Vogelheim <vogelheim@chromium.org> Reviewed-by: Titouan Rigoudy <titouan@chromium.org> Cr-Commit-Position: refs/heads/main@{#1154463}
This is good enough for early review.
TODO:
(See WHATWG Working Mode: Changes for more details.)
Preview | Diff