Re: Fetch, MSE, and MIX

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. 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.

> 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.

So yes, I think the reason it shouldn't be done is it introduces
artificial complexity for a problem that will remain regardless.

Received on Friday, 20 February 2015 22:16:58 UTC