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

Re: [whatwg] Fetch, MSE, and MIX

From: Ryan Sleevi <sleevi@google.com>
Date: Wed, 15 Apr 2015 13:22:05 -0700
Message-ID: <CACvaWvZwa58_hm5Oi7204N3nCH1iyx0Hi_ikURFVHBm75Wcgzw@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.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 Wed, Apr 15, 2015 at 9:45 AM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 14 April 2015 at 22:16, Anne van Kesteren <annevk@annevk.nl> wrote:
> > None of that should be particularly hard, though I do worry that the
> > further we get away from Response, the more we might lose sight of
> > what we are trying to protect and make mistakes.
>
> Indeed, the risk of error is definitely a concern.  A similar practice
> (marking things with origins) happens all over the place in media
> code.  It requires discipline, but it isn't especially difficult.
>
> I believe that the easiest way to avoid this is to make an attempt to
> read Response.body raise a SecurityError if the origin is different
> (in Firefox terms, we would say "if the response principal is not
> subsumed by the script principal").
>

Martin,

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?

Fundamentally, the Response.body origin will be inherently different - the
scheme pairs will be different (as will, presumably, the ports), even if
the host is the same. That is, we're discussing https://www.example.com
sourcing media from http://www.example.com - different origins.

This is more akin to a CORS problem - that is, any use of
Opaque[Response,Stream] has to consider the CORS implications and not
expose the data.

The potential downside with OpaqueStreams is that the consumer of the
Stream needs to distinguish from Stream vs OpaqueStream if it vends any
information it consumes, and we presume there will be a number of Stream
consumers that also vend Streams themselves (thus running the risk of
CORS-exposure).
The potential downside with OpaqueResponse is that if we do OpaqueStreams
(for, e.g., CORS purposes), then appendResponse(response) is just a wrapper
for appendStream(response.body.asStream()), offering two ways to the same
path.

I mean, I share Anne's general concern, but I think whether or not we do
this for mixed content, it's a valid concern for CORS that has to be
solved, unless fech() streams aren't allowed to be used in no-cors mode.
Received on Wednesday, 15 April 2015 20:22:32 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:12 UTC