Block platform verification and file IO in the CDM adapter if the CDM configuration disallows them.

ppapi/api/private/ppp_content_decryptor_private.idl

 /* Copyright (c) 2012 The Chromium Authors. All rights reserved.
  * Use of this source code is governed by a BSD-style license that can be
  * found in the LICENSE file.
  */
 
 /**
  * This file defines the <code>PPP_ContentDecryptor_Private</code>
  * interface. Note: This is a special interface, only to be used for Content
  * Decryption Modules, not normal plugins.
  */
 label Chrome {
-  M41 = 0.13
+  M43 = 0.14
 };
 
 /**
  * <code>PPP_ContentDecryptor_Private</code> structure contains the function
  * pointers the decryption plugin must implement to provide services needed by
  * the browser. This interface provides the plugin side support for the Content
  * Decryption Module (CDM) for Encrypted Media Extensions:
  * http://www.w3.org/TR/encrypted-media/
  */
 interface PPP_ContentDecryptor_Private {
   /**
    * Initialize for the specified key system.
    *
    * @param[in] key_system A <code>PP_Var</code> of type
    * <code>PP_VARTYPE_STRING</code> containing the name of the key system.
+   * @param[in] allow_distinctive_identifier Instruct the CDM to allow using a

[ddorwin, 2015/03/06 21:42:54]

Inform the CDM that it may use a...

This is more consistent with our CDM_8 plans. The fact that prevention in the
adapter is more of an implementation detail than part of the API.

Ditto below.

[sandersd (OOO until July 31), 2015/03/06 22:36:58]

Done.

+   * distinctive identifier.
+   * @param[in] allow_perisistent_state Instruct the CDM to allow storing

[jrummell, 2015/03/06 21:40:47]

s/peris/pers/

[sandersd (OOO until July 31), 2015/03/06 22:36:58]

Done.

+   * persistent state.
    */
   void Initialize(
       [in] PP_Instance instance,
-      [in] PP_Var key_system);
+      [in] PP_Var key_system,
+      [in] PP_Bool allow_distinctive_identifier,
+      [in] PP_Bool allow_persistent_state);

[dmichael (off chromium), 2015/03/06 22:32:31]

Are we trusting the plugin to do the right thing, or is this just advisory?
Meaning...  if a CDM goes rogue and decides to use a distinctive identifier when
it's not allowed, we're going to prevent that at the appropriate API (remote
attestation???), right? (Note that the CDM adapter is no protection; a CDM could
go around it and talk to Pepper directly if it wanted to. Putting protection in
the CDM adapter doesn't seem to prevent abuse at all. Either we trust the CDMs,
in which case the flags don't seem necessary at all. Or...  we don't trust the
CDMs, and we should be preventing the use of the relevant Pepper APIs, which we
can do at a more trusted level like the browser process.)

Assuming that's the case, does the CDM already know a priori whether it should
ask for a distinctive identifier? I would have guessed that a CDM either wants a
distinctive identifier  or it doesn't, and that this flag would not be
meaningful to the CDM (except for identifying the error case where it *wants*
the distinctive identifier but isn't allowed to get it).

So...  backing up, is it possible that we don't need this flag at all, and that
CDMs that want a distinctive identifier just tries to use the appropriate API?

(Similar questions for allow_persistent_state, I guess...  doesn't the CDM
already know if it will use persistent state? Or will CDMs actually make
decisions based off of this flag?)

Please let me know if I'm misunderstanding this.

[sandersd (OOO until July 31), 2015/03/06 22:50:52]

I've just updated the CL description to explain this a little bit, but I'll
answer in detail here.
This is advisory[ish]. Actual use of these APIs is determined by user permission
(for distinctive identifier) or browser state (incognito for persistent state,
but the plan is to add more restrictions).
Not really. The spec is intended to allow us to do all user permission prompting
before creating the CDM instance, and a possible outcome is that we disallow
access even though the user has granted permission. In this case we want to
block access even if the media requests it.
In summary, no. User permission is not sufficient (by the EME spec) to allow
these CDM features.
The CDM will make a decision based on the media, which can differ from the
negotiated configuration. An ugly thorn here is that the current CrOS Widevine
CDM will provide access to a distinctive identifier whenever it can; it always
attempts platform verification but doesn't necessarily fail to play media if
verification fails.

 
   /**
    * Provides a server certificate to be used to encrypt messages to the
    * license server.
    *
    * @param[in] promise_id A reference for the promise that gets resolved or
    * rejected depending upon the success or failure of setting the certificate.
    *
    * @param[in] server_certificate A <code>PP_Var</code> of type
    * <code>PP_VARTYPE_ARRAYBUFFER</code> containing the certificate to be used.
@@ skipping 243 matching lines @@
    * @param[in] encrypted_block_info A <code>PP_EncryptedBlockInfo</code> that
    * contains all auxiliary information needed for decryption of the
    * <code>encrypted_block</code>.
    */
   void DecryptAndDecode(
       [in] PP_Instance instance,
       [in] PP_DecryptorStreamType decoder_type,
       [in] PP_Resource encrypted_buffer,
       [in] PP_EncryptedBlockInfo encrypted_block_info);
 };