[Bug 26332] Applications should only use EME APIs on secure origins (e.g. HTTPS)

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332

--- Comment #90 from David Dorwin <ddorwin@google.com> ---
(In reply to Mark Watson from comment #86)
> This thread, the TAG opinion and David's comment#82 all reflect the fact
> that there are multiple ways to address the privacy and security risks that
> have been raised.
> 
> We could add additional normative requirements to the specification, though
> this requires some discussion and may not solve all problems. We could
> require secure origins, though this also requires some discussion -
> including of the mixed content problem - and still may not solve all
> problems.

I don't think the fact that there may be other problems is an argument against
it. HTTPS doesn't solve phishing either, but it's still much better than
nothing.

> There may also be some middle ground, where a secure origin is required
> conditionally, depending on the properties of the CDM.
> 
> In practice, in many cases, the CDM and UA implementors together can address
> the issues raised here without secure origins. In these cases they should
> not be forced to anyway require a secure origin, given the high cost of such
> a requirement on content providers.

Unless all content providers support HTTPS, requiring it is not really an
option (i.e. "required conditionally") for user agents because it would result
in platform segmentation (into HTTPS-requiring and HTTP-allowing clients). Do
you have other suggestions on how to allow user agents to require secure
origins when necessary without segmenting the platform?

It's also hard to imagine a user agent implementation that supports user
permissions that should not require secure origins (at least for persisted
permissions). User agents implementing such permissions give users a false
sense of security and privacy, and specs should not imply that this is
acceptable. We should not make the same mistake as past permission-related
specs.

> We could even simply strengthen our security requirements by enumerating the
> issues and mitigations (including but not limited to secure origins) and
> requiring that implementations MUST address these: this would already be
> more than the rest of the web platform - any implementation could have
> buffer overrun vulnerabilities, for example, and we do not specify how
> browsers should address this security aspect - we just assume that they do.

Hopefully the design of the rest of the web platform does not make it more
likely there will be buffer overruns. EME exposes functionality that in many
implementations has such security and privacy issues by design. That’s very
different. This is also one reason I have little confidence that these issues
will be adequately addressed in the near future, especially without user agent
enforcement of normative requirements.

(In reply to Mark Watson from comment #88)
...
> A managed migration, at a reasonable
> pace with time for software and hardware optimizations to be developed and
> deployed, has a different, lower, cost.

I also mentioned facilitating a smooth transition in comment #82. Do you have
suggestions here?

The time it takes for this spec to progress through the process and for this
version of it to be implemented and become a large portion of such traffic will
naturally delay the impact somewhat. However, we should be clear to application
authors and implementors about our intent.

> Also, HTTPS is not a panacea and we are looking at - and in some contexts
> have deployed - other approaches as well.


(In reply to Joe Steele from comment #89)
...
> I think if we specify mechanisms rather than specifying outcomes, we will
> not end up with the outcomes we want. There is no consensus that the
> mechanism proposed (SSL/TLS) will address the concerns completely, or that
> this is the only mechanism that can address the concerns. We have a list of
> possible attacks and proposed mitigations. I think we would promote better
> user privacy and better security by adding this information to the spec,
> normatively if possible.

Do you have suggestions where and how we can (normatively) promote better user
privacy and better security in the spec? Regardless of the outcome of this bug,
that would be a good thing.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 17 October 2014 02:43:38 UTC