Re: [whatwg/fetch] Cross-Origin Read Blocking (CORB) (#681)

Regarding range requests:

Thanks for covering the overlap here, @jakearchibald!  I agree that CORB overlaps with the attack 4 defense, but only for certain content types, so your original plans still seem relevant.

> CORB's goal is to prevent bringing data into the content process, whereas I'm aiming to prevent exposing data to script. CORB is best-effort, with compatibility in mind, whereas I need to strictly avoid exposing opaque data to script.

Correct.

> CORB will filter opaque partial responses if they match particular content types. This prevents an audio/video element being used to bring data that's potentially sensitive into the content process.

Correct.

> #560 prevents Attack 4, where a <script> is given a partial response that may contain private data. CORB will make this a lot harder for particular content types, but #560 prevents this particular attack for all content types.

Correct.

> CORB recommends against multipart range requests. Currently range requests aren't specced from that API's point of view, but I'm trying to define it. I don't plan to use multiple ranges in a single response, and once specced, browsers shouldn't make kinds of range requests that aren't explicitly allowed.

Just to clarify, are you saying that multipart range requests wouldn't generate responses with multipart/byteranges content types after your changes?  In general or just for service worker?  We would love it if the content type reflected what was in the response, since we weren't eager about parsing the multipart response in the browser process to determine what was in it.  For now, we're just recommending against supporting it for sensitive data.

> I intend to make media elements reject responses that would result in a mix of opaque and visible data being treated as the same media resource. This prevents Attack 1.
>
> I intend to make media elements reject responses that would result in opaque data from multiple URLs being treated as the same media resource. This prevents Attack 2.
>
> I intend to make range supporting APIs fail if the partial response starts at an offset other than the requested range. This prevents Attack 3.
>
> In intend to make downloads fail/restart if content identifying headers change between requests. Such as total length in Content-Range, Content-Type, ETag, Last-Modified.

Sounds good to me (and orthogonal to CORB).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/681#issuecomment-381346349