Re: Fetch, MSE, and MIX

On Wed, Feb 25, 2015 at 10:11 AM, Brian Smith <brian@briansmith.org> wrote:
> 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.

Or, alternatively phrased, it would increase the opportunity costs and
make this less likely to be adopted.

I think the benefits should be weighed in hearing back from more of
the site operators here. I'm strongly in favour of security activism,
but it must be weighed with a careful evaluation of the opportunity
costs.

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

Well, the point of the proposal was to float and gather feedback about
what's reasonable before deciding on a concrete course there.

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

While I appreciate the distinction, I don't think it's an accurate
presentation. That is, mixed content protection is about preventing an
origin from being exposed to data that may not be authentic, and CORS
prevents an origin from being exposed to data it is not authorized
for. In that sense, both are about preventing an origin from being
exposed to data received over the network.

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

Aren't what you really exploring
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26533 in another name?
Should you have to create a <video> element first? Should you have to
append it to the document? I think 26533 is probably a better place to
expose that API shape.

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