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

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

            Bug ID: 26332
           Summary: Applications should only use EME APIs on secure
                    origins (e.g. HTTPS)
           Product: HTML WG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Encrypted Media Extensions
          Assignee: adrianba@microsoft.com
          Reporter: ddorwin@google.com
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-media@w3.org

Most existing DRM systems use a [effectively] permanent unique identifier in
the client, often [based on value(s)] baked into the hardware. It seems likely
that such systems also do not effectively anonymize the identifier in the
license protocol.

Assuming this is true, EME enables providing a unique device/user identifier
(possibly permanent for a given device) to an unauthenticated application,
which may then transmit it over the Internet in the clear. This seems
unacceptable. Furthermore, tying permissions, such as those for an identifier,
to unauthenticated domains is potentially ineffective [1].

There are solutions and mitigations to this problem [2], but they will vary per
key system and it is difficult (and unlikely to be followed) to normatively
require one or more of them. The only normative and interoperable protection I
can think of is to require a secure origin (e.g. HTTPS) when using such key
systems.


There is a push to require secure origins/transport for new powerful new web
platform features [4], which would include exposing permanent hardware-based
identifiers. Restricting the origin/transport is being discussed for other
APIs, including WebCrypto [5]. The definition of secure origin and transport is
still being debated, but it seems likely some standard definition will emerge
and could be referenced by EME.


Failing on unsecure origins (e.g. HTTP) could take various forms. In all cases,
I think it makes sense to detect and handle this in MediaKeys::create().
Possible options:
1) EME APIs only work on secure origins: Always fail on HTTP, etc.
2) Key systems that use unique identifiers only work on secure origins: Fail if
the implementation of |keySystem| uses identifiers.
3) Key systems that do not have appropriate mitigations [3] only work on secure
origins: Fail if the implementation of |keySystem| uses identifiers and does
not have appropriate mitigations.

#1 is simple and consistent, but is perhaps too broad. For example, Clear Key
does not need HTTPS.
#2 will likely be equivalent to #1 for many implementations, but requires the
user agent vendor to proactively do the right thing. It is also perhaps too
broad.
#3 probably captures the right set of scenarios where the risk exists, but it
leaves a lot of room for judgement and incorrect decisions by user agents.

Assuming there are CDM implementations that fall into #3 (identifier with no
appropriate mitigations), applications would need to support HTTPS in order to
support those key systems. For applications supporting such key systems, there
would effectively be no difference among the three options. On the other hand,
#3 (if respected) provides incentive for CDM implementations to use appropriate
mitigations, some of which have additional benefits that a secure origin alone
cannot provide.

#3 also does not address the previously mentioned permissions issue [1], which
is still relevant to some degree even with such appropriate mitigations.


One might argue that this should be part of the non-normative Privacy
Considerations or a recommendation similar to the mitigations. However, I do
not believe this would result in a measurable improvement. Applications are
unlikely to voluntarily switch to HTTPS based solely on such a recommendation
(client privacy should not rely on the application anyway), and implementations
are unlikely to require secure transport because it will put them at a
disadvantage to other implementations. Therefore, it is likely that the only
way to actually address the issue is to normatively require secure origins in
one of the flavors listed above. #1 is the simplest way to ensure that
applications and implementations do the right thing.


[1] “Granting permissions to unauthenticated origins is, in the presence of a
network attacker, equivalent to granting the permissions to any origin. The
state of the internet is such that we must indeed assume that a network
attacker is present.” - [4]
[2] Examples include: encrypt the identifier using a server certificate and
salt, not using identifiers, providing unique identifiers per origin
[3] Appropriate mitigations might include: encrypt the identifier using a
server certificate and salt
[4]
http://lists.w3.org/Archives/Public/public-webappsec/2014Jun/thread.html#msg222
[5] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25972

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

Received on Monday, 14 July 2014 22:35:29 UTC