- From: Brian Smith <brian@briansmith.org>
- Date: Fri, 20 Feb 2015 13:45:09 -0800
- To: Ryan Sleevi <sleevi@google.com>
- Cc: whatwg@whatwg.org, "public-webappsec@w3.org" <public-webappsec@w3.org>, public-html-media@w3.org
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