Re: [whatwg] Fetch, MSE, and MIX

On Wed, Apr 15, 2015 at 1:33 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 15 April 2015 at 13:22, Ryan Sleevi <sleevi@google.com> wrote:
> > I'm not sure how this would work/how it applies to the problem at hand -
> > perhaps this got conflated with another discussion of streams?
>
> No, what you describe is exactly what I meant.  And yes, it is a cross
> origin thing (not CORS, more like the absence of CORS).
>
> I implemented an analogous feature for MediaStream in WebRTC.  It
> turned out to be relatively easy, though it did require a lot of care.
>

I'm not sure I follow then - the entire point of fetch's no-cors mode is to
allow the resource to be fetched, and used, but without exposing the data.
That is, the stream data must be readable by the user agent in order to be
useful.

Or perhaps I'm misunderstanding, and your remark about reading
Response.body was discussing attempts directly by the script to access the
body? In which case, I think this would be Domenic's remark that it
shouldn't be possible to get a reader.

While that solves the direct script access to response.body/the stream, I
understood Anne's remark to be more about filtering/transitive operations
on the Stream, which might vend new Streams, and thus lose the security
protections.

For example, assume a hypothetical Base64StreamDecoder, which accepts a
Stream for input, and vends a Stream for output. While the script can't
directly access inputStream, nor can it get a reader from it, if it can get
a reader from the outputStream, then the security guarantees have been
defeated. That's the challenge, as I understood it, that Anne was
mentioning - that it is not just about making sure the Stream object is
safe, but that anything that consumes Streams and yields more Streams (or
any other form of data) check the Opaque-ness of the input before
generating the output.

This is true regardless of the mixed content loads (due to CORS), so it's
not a new problem by any means. Streams just make this more tricky, because
we will presumably have many APIs that accept Streams and then transform
data (for example, Audio/video filters, encoding/decoding, cryptography),
and they all have to be aware of the distinction. appendResponse() avoids
most of this challenge simply because we don't expect many APIs to be
dealing with response objects directly, and certainly not vending new
Response objects from input Response objects, beyond the limited case of
fetch.