W3C home > Mailing lists > Public > public-webappsec@w3.org > April 2015

Re: [whatwg] Fetch, MSE, and MIX

From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 15 Apr 2015 14:04:02 -0700
Message-ID: <CABkgnnVhP0PjsLEGOZus-mYwWSmwT+t0mm5GZ_xCbdj87cR-tg@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:48 UTC