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.Received on Wednesday, 15 April 2015 20:50:32 UTC
This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:12 UTC