Propose the following draft text, to be added as a new top level section or a sub-section of the Introduction. Note that this proposal is little more than an outline intended to be elaborated after further discussion in the TF.

X Security Considerations

This section is non-normative.

X.1 Security considerations for EME Implementers

User agents should take measures to prevent unauthorized access to initialization data, key data, or decrypted media data.

X.2 Security considerations for EME Users

While this API provides a means to develop applications that make use of protected media content, it does not, by itself, ensure that no unauthorized access occurs to initialization data, key data, or decrypted media data.

While the API in this specification provides a means to use keys, it makes no statements as to how the actual keying material will be stored by an implementation. As such, although a key may be inaccessible to web content, it should not be presumed that it is inaccessible to end-users.

Under X.1, suggest adding the following:

"In the context of using certain Key Systems, it is possible that Initialization Data, Key Data, or Media Data may contain active content [SECURITY GLOSSARY]. If a User Agent performs the interpretation or execution of such active content, then it should consider the threats, risks, and safeguards described in [ACTIVE CONTENT]."

[SECURITY GLOSSARY] Shirey, R., Internet Security Glossary, Version 2, RFC 4949, August 2007, IETF.

[ACTIVE CONTENT] Jansen, W, et al., Guidelines on Active Content and Mobile Code, Special Publication 800-28, Version 2, 2008, National Institute of Standards and Technology (NIST).

(In reply to comment #1)
The content of the subsections in comment #1 relate to key and content protection issues. That is very different from client security, which is the focus of the discussions that lead to this issue. We should focus the discussion in this bug on the latter. Note that [1] above is more similar to the former.

(In reply to comment #2)
Note: Comment #2 relates to bug 22901.

I think we should discourage execution of any content from the media data or JavaScript (i.e. licenses). There are too many bad things that can happen from running untrusted code, especially if the CDM is running unsandboxed.

Speaking of which, we should add a note that CDMs must be very careful to safely parse, decrypt, etc. media data and licenses. Also add a note that unsandboxed CDMs must be extra careful in all areas of security and probably recommend sandboxing in general.

Added placeholder -> https://dvcs.w3.org/hg/html-media/rev/9b1a977865d8

*** Bug 22901 has been marked as a duplicate of this bug. ***

Web MIDI has a section on security and privacy that might be a useful model.
http://www.w3.org/TR/webmidi/#security-and-privacy-considerations

Proposal:

X Security Considerations
 
This section is non-normative.
 
Key System implementations must consider initialization data, key data and media data as potential attack vectors and must take care to safely parse, decrypt etc. initialization data, key data and media data. User Agents may want to validate data before passing it to the CDM, especially if the CDM does not run in the same (sandboxed) context as the DOM (i.e. rendering). 

It is STRONGLY RECOMMENDED that key data and media data do not contain active content [SECURITY GLOSSARY].  If a Key System implementation supports the interpretation or execution of such active content then it is STRONGLY RECOMMENDED that User Agents make use of sandbox techniques to restrict the scope of access that the CDM has to the user’s device. In any case, User Agent and Key System implementers should consider the threats, risks, and safeguards described in [ACTIVE CONTENT].

User Agents are responsible for providing users with a secure way to browse the web. Since User Agents may integrate with third party CDM implementations, CDM implementors must provide sufficient information and controls to user agent implementors to enable them to properly asses the security implications of integrating with the Key System.

Note: unsandboxed CDMs (or CDMs that use platform features) and UAs that use them must be especially careful in all areas of security, including parsing of key and media data, etc. due to the potential for compromises to provide access to OS/platform features, interact with or run as root, access drivers, kernel, firmware, hardware, etc., all of which may not be written to be robust against hostile software or web-based attacks. Additionally, CDMs may not be updated with security fixes as frequently, especially when part of the OS, platform or hardware.
 
[SECURITY GLOSSARY] Shirey, R., Internet Security Glossary, Version 2, RFC 4949, August 2007, IETF.
 
[ACTIVE CONTENT] Jansen, W, et al., Guidelines on Active Content and Mobile Code, Special Publication 800-28, Version 2, 2008, National Institute of Standards and Technology (NIST).

The proposal claims the section is non-normative but uses normative RFC 2119 words ("must"). Is there a reason why the section cannot be normative? If there is, any chance of phrasing the text is not to use RFC 2119 words?

(In reply to Mark Watson from comment #7)
> Proposal:

I added this to the spec to make it easier to review:
https://dvcs.w3.org/hg/html-media/rev/cccd6d78bd9f

(In reply to Adrian Bateman [MSFT] from comment #9)
> (In reply to Mark Watson from comment #7)
> > Proposal:
> 
> I added this to the spec to make it easier to review:
> https://dvcs.w3.org/hg/html-media/rev/cccd6d78bd9f

I am confused by this section:
 "Key system implementations... User Agents may want to validate data"

Assuming the material is encrypted, how is this going to be generally possible? Even if it is - this may violate business agreements in place to prevent disclosure of keys. I think you should add something like "to the extent feasible", acknowledging that this is likely to be impossible.

I also have a comment on this section "User deletion of Key System storage".
I would recommend adding an informative note that such deletion may impact the playback performance and the UA could inform the user of that fact.

(In reply to Joe Steele from comment #10)
> (In reply to Adrian Bateman [MSFT] from comment #9)
> > (In reply to Mark Watson from comment #7)
> > > Proposal:
> > 
> > I added this to the spec to make it easier to review:
> > https://dvcs.w3.org/hg/html-media/rev/cccd6d78bd9f
> 
> I am confused by this section:
>  "Key system implementations... User Agents may want to validate data"
> 
> Assuming the material is encrypted, how is this going to be generally
> possible? Even if it is - this may violate business agreements in place to
> prevent disclosure of keys. I think you should add something like "to the
> extent feasible", acknowledging that this is likely to be impossible.

I could imagine a lot of data validation that could be possible. Initialization data may not be encrypted and media data may have unencrypted framing around the encrypted samples (e.g. Common Encryption). There may be length constraints on encrypted data that could be validated.

> 
> I also have a comment on this section "User deletion of Key System storage".
> I would recommend adding an informative note that such deletion may impact
> the playback performance and the UA could inform the user of that fact.

I agree. Could you raise a separate bug for that - I think we'll have trouble tracking multiple comments in this bug.

(In reply to Mark Watson from comment #11)
> (In reply to Joe Steele from comment #10)
> > (In reply to Adrian Bateman [MSFT] from comment #9)
> > > (In reply to Mark Watson from comment #7)
> > > > Proposal:
> > > 
> > > I added this to the spec to make it easier to review:
> > > https://dvcs.w3.org/hg/html-media/rev/cccd6d78bd9f
> > 
> > I am confused by this section:
> >  "Key system implementations... User Agents may want to validate data"
> > 
> > Assuming the material is encrypted, how is this going to be generally
> > possible? Even if it is - this may violate business agreements in place to
> > prevent disclosure of keys. I think you should add something like "to the
> > extent feasible", acknowledging that this is likely to be impossible.
> 
> I could imagine a lot of data validation that could be possible.
> Initialization data may not be encrypted and media data may have unencrypted
> framing around the encrypted samples (e.g. Common Encryption). There may be
> length constraints on encrypted data that could be validated.

I agree with those examples, but it might be useful to point out that some stuff may not be verifiable by the UA.
 
> 
> > 
> > I also have a comment on this section "User deletion of Key System storage".
> > I would recommend adding an informative note that such deletion may impact
> > the playback performance and the UA could inform the user of that fact.
> 
> I agree. Could you raise a separate bug for that - I think we'll have
> trouble tracking multiple comments in this bug.

Will do.

Updated the spec with ISSUE notes about this section needing more review as discussed at the F2F. Please open new bugs with any feedback instead of reopening this bug.
https://dvcs.w3.org/hg/html-media/rev/42d23ada7eca