Re: Fetch, MSE, and MIX

Ryan Sleevi <sleevi@google.com> wrote:
> On Fri, Feb 20, 2015 at 1:45 PM, Brian Smith <brian@briansmith.org> wrote:
>> In your proposal, would the HTTP requests to fetch the media content
>> include cookies, session identifiers, HTTP auth, etc.? It seems for
>> the use case your proposal is trying to address, it would not be
>> problematic to strip the cookies and similar bits from the outgoing
>> HTTP requests. This would improve the security and privacy properties
>> of this proposal. For example, it would protect against the issues
>> with cookies not being always marked "Secure" and/or attacks that
>> allow the attacker to remove the "Secure" bit from a cookie. Would you
>> be willing to modify your proposal to do this?
>
> It follows the same fetch() rules as <audio>/<video> do.

In https://w3c.github.io/webappsec/specs/mixedcontent/#further-action
we've identified blocking cookies from mixed content <audio>, <video>,
and <img> as a future thing to consider. I think that, if UAs were to
go through with implementing your proposal, it would make more sense
to start off by stripping cookies and auth credentials so that we
minimize the compatibility impact when we do so for the rest of
optionally-blockable mixed content.

>  It does not
> seek to change them, in part due to the risk that the more artificial
> restrictions that are introduced for this case (however they may
> benefit security), the less likely we are to see any adoption
> whatsoever. That is, if you make HTTP page + HTTP MSE more attractive
> than HTTPS page + HTTP MSE (since we know some large sites need a
> large berth of time to move to HTTPS page + HTTPS MSE), then sites
> will continue to use HTTP page + HTTP MSE, and we'll be back to where
> we started.

Is anybody who is refusing to do video over HTTPS (i.e. Netflix)
demanding cookies be sent in such mixed content requests? AFAICT,
nobody has asked for cookies and auth credentials.

>> Since the point of this proposal is specifically to allow MSE, rather
>> than setting the type to "opaque," why not set the type to a new type
>> "SourceBuffer" that is restricted purely to constructing
>> SourceBuffers? Then we wouldn't have to worry about all the ways that
>> the more-general "opaque" type would allow responses to be (ab)used
>> that aren't intended/addressed by this proposal. Is there a reason
>> this shouldn't be done?
>
> This was considered extensively, but I don't think this is a
> reasonable concern. In part, we must _always_ be concerned with how
> "opaque" types are used, because of CORS. The issues that exist with
> "opaque" exist independent of any mixed content considerations, they
> apply to any cross-origin communication.

Mixed content protection protects the origin loading a resource,
whereas CORS protects the origin from which the resource is loaded.
That's a fundamental difference, and even though these concerns would
be addressed similarly now, I don't think it is prudent to assume it
will always be reasonable to treat them exactly the same, so it makes
more sense to have a separate type.

Also, as far as CSP is concerned, I think it would be a mistake for
these requests to have fetch type "fetch" if the responses are only to
be used for displaying video. I think we should find a design that
allows us to use fetch type "video" instead.

In particular, don't you agree it is safer and thus preferable to have this:

    connect-src: 'self'; video-src: http://example.com

instead of this?:

    connect-src: 'self' http://example.com

One way of doing this would be to add a fetchSource method to the
<video> element that is like window.fetch() except that it returns a
SourceBuffer instead of a response, and then specifying that the fetch
type for fetchSource is "video".

Besides improving the interaction with CSP, this fetchSource method
would also tie the fetch to a UI element (the <video> element), which
would be useful in the future for making it easier to create better
user interfaces for optionally-blockable mixed content protection in
the future.

Thoughts?

Cheers,
Brian

Received on Wednesday, 25 February 2015 18:11:29 UTC