Re: Fetch, MSE, and MIX

Ryan Sleevi <sleevi@google.com> wrote:
> This won't protect adversaries from knowing what content the user is
> actively watching, for example, but will help protect other vital
> assets - such as their cookies, session identifiers, user information,
> friends list, past viewing history, etc.

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?

> Allowing fetch() to return HTTP content sourced from HTTPS pages seems
> like it would re-open the XHR hole, but this isn't the case. As
> described in [14], all requests whose mode is CORS or
> CORS-with-forced-preflight are force-failed. This only leaves the
> request modes of "no-cors", "same-origin", "about"and "data". Because
> the origins are different between the document (https) and the request
> URL (http), the request mode will be "no-cors", and thus the returned
> Response object will be set to "opaque".

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?

> That is, I can always disclose content by a <video> or <img> tag
> directly.

According to Mozilla's telemetry, 98% of page loads do not have any
mixed content. That's too high to change the UI now (unless they're
really almost all ads), But, I think there are concrete things we can
do to make it so that we're comfortable blocking optionally-blockable
mixed content by default, with a different, easier, kind of UI than
what we use now for blockable mixed content. It's not worth getting
into the details here on all the things that would need to change or
what that UI would look like, but I think some change like that is
necessary to give users the secure-by-default browsing experience they
deserve. I think one key part of making those changes possible is
restricting the "optionally-blockable" category to concepts that all
users can be expected to understand: images and videos. This is why,
if the intent of this proposal is really to be video-specific, then it
is worth locking it down tighter so that it truly is.

Anyway, the last time I looked at what was happening with EME, it had,
or was on track to have, some really terrible and user-hostile privacy
misfeature and that it's now futile to try to fight EME having that
misfeature. So, I'm assuming that a major goal of this proposal is to
minimize the harm to users of that misfeature, by doing as Ryan said
and making EME HTTPS-only. If so, I'd recommend that this proposal be
bundled together with the HTTPS-only-EME proposal so they can be
agreed to as a single thing, so that the people who are trying to make
the best out of a bad situation don't get screwed in the future [1].

Cheers,
Moderate Brian

[1] http://www.bothsidesofthetable.com/2012/03/10/never-negotiate-piecemeal-heres-why/

Received on Friday, 20 February 2015 21:45:36 UTC