- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 15 Apr 2015 14:04:02 -0700
- To: Ryan Sleevi <sleevi@google.com>
- Cc: Anne van Kesteren <annevk@annevk.nl>, Domenic Denicola <d@domenic.me>, Matthew Wolenetz <wolenetz@google.com>, Aaron Colwell <acolwell@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, WHATWG <whatwg@whatwg.org>, Brad Hill <hillbrad@gmail.com>, "public-html-media@w3.org" <public-html-media@w3.org>
On 15 April 2015 at 13:50, Ryan Sleevi <sleevi@google.com> wrote: > 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. Yes, this is exactly the sort of thing we deal with in MediaStreams: you can render a cross-origin video stream to <video>, then capture the output of the video tag, thereby creating a new MediaStream. Same goes for rendering to <video>, then <canvas>. It's a little different for WebAudio, the decision was to not allow the cross-origin content to enter the graph. My only point was that we have a precedent for handling this exact sort of problem. > 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. Yes, I am agreeing with Domenic. BTW, do you care that it might be possible to learn the length of the data?
Received on Wednesday, 15 April 2015 21:04:31 UTC