--- a/encrypted-media/encrypted-media-respec.html Wed Oct 15 09:51:50 2014 -0700
+++ b/encrypted-media/encrypted-media-respec.html Wed Oct 15 09:54:01 2014 -0700
@@ -1333,7 +1333,7 @@
<li><p>Let <var title="">initDataType</var> be the string representing the <a def-id="initialization-data-type"></a> of the Initialization Data.</p></li>
<li><p>Let <var title="">initData</var> be the Initialization Data.</p></li>
</ol>
- <p class="note">While the media element may allow loading of "Optionally-blockable Content" [MIXED-CONTENT], the user agent MUST NOT expose Initialization Data from such media data to the application.</p>
+ <p class="note">While the media element may allow loading of "Optionally-blockable Content" [[MIXED-CONTENT]], the user agent MUST NOT expose Initialization Data from such media data to the application.</p>
</li>
<li>
<p><a def-id="Queue-a-task-to-fire-an-event-named"></a> <a def-id="encrypted"></a> at the media element.</p>
@@ -1641,11 +1641,11 @@
<p>User Agent and Key System implementations must consider <a def-id="media-data"></a>, <a def-id="initialization-data"></a>, responses (i.e. data passed to <a def-id="update"></a>), licenses, key data, and all other data provided by the application as untrusted content and potential attack vectors.
They must use appropriate safeguards to mitigate any associated threats and take care to safely parse, decrypt, etc. such 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).
+ User Agents SHOULD 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).
</p>
- <p>Implementations should not return active content or passive content that affects program control flow to the application.
- For example, it is not safe to expose URLs or other information that may have come from media data, such as is the case for the Initialization Data passed to <a def-id="generateRequest"></a>.
- Applications should determine the URLs to use. The <a def-id="message-event-type-attribute"></a> attribute of the <a def-id="message"></a> event can be used by the application to select among a set of URLs if applicable.
+ <p>Implementations MUST NOT return active content or passive content that affects program control flow to the application.
+ For example, it is not safe to expose URLs or other information that may have come from media data, such as is the case for the <a def-id="initialization-data"></a> passed to <a def-id="generateRequest"></a>.
+ Applications must determine the URLs to use. The <a def-id="message-event-type-attribute"></a> attribute of the <a def-id="message"></a> event can be used by the application to select among a set of URLs if applicable.
</p>
<p>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 implementers must provide sufficient information and controls to user agent implementers to enable them to properly asses the security implications of integrating with the Key System.</p>
<p>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.</p>
@@ -1675,7 +1675,7 @@
<section id="privacy-fingerprinting">
<h4>Fingerprinting</h4>
- <p>Malicious applications may be able to fingerprint users or user agents by detecting or enumerating the list of Key Systems that are supported and related information. If proper origin protections are not provided this could include detection of sites that have been visited and information stored for those sites. In particular, Key Systems should not share key or other data between origins.</p>
+ <p>Malicious applications may be able to fingerprint users or user agents by detecting or enumerating the list of Key Systems that are supported and related information. If proper origin protections are not provided this could include detection of sites that have been visited and information stored for those sites. In particular, Key Systems MUST not share key or other data between origins.</p>
</section>
<section id="privacy-leakage">
@@ -1686,12 +1686,12 @@
Failure to do so could lead to information leakage to/from Incognito/Private Browsing sessions, across profiles, and even across different browsers, applications, and operating system user accounts.
</p>
- <p>To avoid such issues, user agent and CDM implementations should ensure that:</p>
+ <p>To avoid such issues, user agent and CDM implementations MUST ensure that:</p>
<ul>
<li>CDMs have a concept of a CDM instance that is associated 1:1 with a MediaKeys object.</li>
<li>Keys, licenses, other session data, and the presence of sessions are restricted to the CDM instance associated with the MediaKeys object that created the session.</li>
<li>Session data is not shared between MediaKeys objects or CDM instances.</li>
- <li>Session data is not shared with media elements not associated with the MediaKeys object that created the session. Among other things, this means a session's keys may not be used to decrypt content loaded by a media element whose <a def-id="mediaKeys-attribute"></a> attribute is not the MediaKeys object.</li>
+ <li>Session data is not shared with media elements not associated with the MediaKeys object that created the session. Among other things, this means a session's keys MUST not be used to decrypt content loaded by a media element whose <a def-id="mediaKeys-attribute"></a> attribute is not that MediaKeys object.</li>
<li>MediaKeys objects and the underlying implementation do not expose information outside the origin.</li>
<li>Persisted session data, if applicable, is stored on a per-origin basis.</li>
<li>Only data stored by the requesting origin may be loaded.</li>
@@ -1722,7 +1722,7 @@
<dt id="identifier-encryption">Encryption of user identifiers</dt>
<dd>User identifiers in Key System messages could be encrypted, together with a timestamp or nonce, such that the Key System messages are always different. This would prevent the use of Key System messages for tracking except by applications fully supporting the Key System.
- This may be implemented using a <a href="#server-certificate">server certificate</a>.
+ This MAY be implemented using a <a href="#server-certificate">server certificate</a>.
</dd>
<dt>Site-specific white-listing of access to each Key System</dt>
@@ -1747,7 +1747,9 @@
<p>While these suggestions prevent trivial use of this feature for user tracking, they do not block it altogether. Within a single domain, a site can continue to track the user during a session, and can then pass all this information to a third party along with any identifying information (names, credit card numbers, addresses) obtained by the site. If a third party cooperates with multiple sites to obtain such information, and if identifiers are not per-origin, then a profile can still be created.</p>
<p>It is important to note that identifiers that are non-clearable, non-origin-specific or hardware-bound exceed the tracking impact of existing techniques such as cookies or session identifiers embedded in URLs.</p>
- <p>Thus, in addition to the various mitigations described above, if a browser supports a mode of operation intended to preserve user anonymity, then User Agent implementers should carefully consider whether access to Key Systems should be disabled in this mode.</p>
+ <p>Thus, in addition to the various mitigations described above, if a browser supports a mode of operation intended to preserve user anonymity, then User Agent implementers should carefully consider whether access to Key Systems should be disabled in this mode.
+ For example, such modes MAY prohibit creation of <a>MediaKeySystemAccess</a> objects that are <a def-id="option-stateful"></a> or use a <a def-id="option-uniqueidentifier"></a> (either as part of the CDM implementation or because the application <a def-id="requirement-required"></a> them).
+ </p>
</section>
<section id="privacy-storedinfo">
@@ -1758,10 +1760,14 @@
<dl>
<dt>Origin-specific Key System storage</dt>
- <dd>User agents may require that some or all of the Key System's persistently stored data is stored in an origin-specific way. Session data, licenses, and keys that are persistently stored should be stored per-origin.</dd>
+ <dd>
+ Any data persistently stored by the CDM that might impact messages or behavior in an application- or license server-visible way MUST be stored in an origin-specific way.
+ Session data, licenses, and keys that are persistently stored MUST be stored per-origin.
+ See <a def-id="session-storage"></a>.
+ </dd>
<dt>User deletion of Key System storage</dt>
- <dd>User agents may present the user with a way to delete Key System storage for a specific origin or all origins.</dd>
+ <dd>User agents should present the user with a way to delete Key System storage for a specific origin or all origins.</dd>
<dt>Treating Key System stored data like cookies / Web Storage</dt>
<dd>User agents should present the presence of persistent data stored by Key Systems to the user in a way that associates it strongly with HTTP session cookies and/or Web Storage. This might encourage users to view such data with healthy suspicion.</dd>
@@ -1770,18 +1776,18 @@
<dd>User agents should treat data stored by Key Systems as potentially sensitive; it is quite possible for user privacy to be compromised by the release of this information. To this end, user agents should ensure that such data is securely stored and when deleting data, it is promptly deleted from the underlying storage.</dd>
</dl>
- <p>User agent and CDM implementations that allow the CDM to persist data should:</p>
+ <p>User agent and CDM implementations that allow the CDM to persist data:</p>
<ul>
- <li>Ensure it is restricted to the origin for which it was created.</li>
- <li>Ensure it is restricted to the current profile and does not leak to or from Incognito/Private Browsing sessions.</li>
- <li>Allow the user to clear it, preferably by origin.</li>
- <li>Treat it like other site data, including presenting it along with cookies, including it in "remove all data", and presenting it in the same UI locations.</li>
+ <li>MUST ensure it is restricted to the origin for which it was created.</li>
+ <li>MUST ensure it is restricted to the current profile and does not leak to or from Incognito/Private Browsing sessions.</li>
+ <li>Should Allow the user to clear it, preferably by origin.</li>
+ <li>Should treat it like other site data, including presenting it along with cookies, including it in "remove all data", and presenting it in the same UI locations.</li>
</ul>
</section>
<section id="privacy-secureorigin">
<h3>Use Secure Origin and Transport</h3>
- <p>In order to protect identifiers and other information discussed in previous sections, user agents may choose to only support the EME APIs and/or specific Key Systems (i.e. based on privacy and security risks) on secure origins.
+ <p>In order to protect identifiers and other information discussed in previous sections, user agents MAY choose to only support the EME APIs and/or specific Key Systems (i.e. based on privacy and security risks) on secure origins.
This is especially important if a user agent chooses to support a Key System implementation that exposes identifiers or other such information without effectively anonymizing it in transit (i.e. without <a href="#identifier-encryption">encrypting identifiers</a>).
</p>
<p>Regardless of user agent limitations, applications should use secure transport (e.g. HTTPS) for all traffic containing messages from the CDM (i.e. all data passed from <a def-id="message"></a> events and to <a def-id="update"></a>).</p>
--- a/encrypted-media/encrypted-media.html Wed Oct 15 09:51:50 2014 -0700
+++ b/encrypted-media/encrypted-media.html Wed Oct 15 09:54:01 2014 -0700
@@ -445,7 +445,7 @@
</p>
<h1 class="title p-name" id="title" property="dcterms:title">Encrypted Media Extensions</h1>
- <h2 property="dcterms:issued" datatype="xsd:dateTime" content="2014-10-15T16:47:23.000Z" id="w3c-editor-s-draft-15-october-2014"><abbr title="World Wide Web Consortium">W3C</abbr> Editor's Draft <time class="dt-published" datetime="2014-10-15">15 October 2014</time></h2>
+ <h2 property="dcterms:issued" datatype="xsd:dateTime" content="2014-10-15T16:52:30.000Z" id="w3c-editor-s-draft-15-october-2014"><abbr title="World Wide Web Consortium">W3C</abbr> Editor's Draft <time class="dt-published" datetime="2014-10-15">15 October 2014</time></h2>
<dl>
<dt>This version:</dt>
@@ -1651,7 +1651,7 @@
<li><p>Let <var title="">initDataType</var> be the string representing the <a href="#initialization-data-type">Initialization Data Type</a> of the Initialization Data.</p></li>
<li><p>Let <var title="">initData</var> be the Initialization Data.</p></li>
</ol>
- <div class="note"><div class="note-title" aria-level="3" role="heading" id="h_note_35"><span>Note</span></div><p class="">While the media element may allow loading of "Optionally-blockable Content" [MIXED-CONTENT], the user agent <em class="rfc2119" title="MUST NOT">MUST NOT</em> expose Initialization Data from such media data to the application.</p></div>
+ <div class="note"><div class="note-title" aria-level="3" role="heading" id="h_note_35"><span>Note</span></div><p class="">While the media element may allow loading of "Optionally-blockable Content" [<cite><a class="bibref" href="#bib-MIXED-CONTENT">MIXED-CONTENT</a></cite>], the user agent <em class="rfc2119" title="MUST NOT">MUST NOT</em> expose Initialization Data from such media data to the application.</p></div>
</li>
<li>
<p><a href="http://www.w3.org/TR/html5/webappapis.html#queue-a-task">Queue a task</a> to <a href="http://www.w3.org/TR/html5/webappapis.html#fire-a-simple-event">fire a simple event</a> named <code><a href="#dom-evt-encrypted">encrypted</a></code> at the media element.</p>
@@ -1956,11 +1956,11 @@
<p>User Agent and Key System implementations must consider <a href="http://www.w3.org/TR/html5/embedded-content-0.html#media-data">media data</a>, <a href="#initialization-data">Initialization Data</a>, responses (i.e. data passed to <code><a href="#widl-MediaKeySession-update-Promise-void--ArrayBuffer-ArrayBufferView-response">update()</a></code>), licenses, key data, and all other data provided by the application as untrusted content and potential attack vectors.
They must use appropriate safeguards to mitigate any associated threats and take care to safely parse, decrypt, etc. such 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).
+ User Agents <em class="rfc2119" title="SHOULD">SHOULD</em> 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).
</p>
- <p>Implementations should not return active content or passive content that affects program control flow to the application.
- For example, it is not safe to expose URLs or other information that may have come from media data, such as is the case for the Initialization Data passed to <code><a href="#widl-MediaKeySession-generateRequest-Promise-void--DOMString-initDataType-ArrayBuffer-ArrayBufferView-initData">generateRequest()</a></code>.
- Applications should determine the URLs to use. The <code><a href="#widl-MediaKeyMessageEvent-type">type</a></code> attribute of the <code><a href="#dom-evt-message">message</a></code> event can be used by the application to select among a set of URLs if applicable.
+ <p>Implementations <em class="rfc2119" title="MUST NOT">MUST NOT</em> return active content or passive content that affects program control flow to the application.
+ For example, it is not safe to expose URLs or other information that may have come from media data, such as is the case for the <a href="#initialization-data">Initialization Data</a> passed to <code><a href="#widl-MediaKeySession-generateRequest-Promise-void--DOMString-initDataType-ArrayBuffer-ArrayBufferView-initData">generateRequest()</a></code>.
+ Applications must determine the URLs to use. The <code><a href="#widl-MediaKeyMessageEvent-type">type</a></code> attribute of the <code><a href="#dom-evt-message">message</a></code> event can be used by the application to select among a set of URLs if applicable.
</p>
<p>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 implementers must provide sufficient information and controls to user agent implementers to enable them to properly asses the security implications of integrating with the Key System.</p>
<p>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.</p>
@@ -1990,7 +1990,7 @@
<section id="privacy-fingerprinting" typeof="bibo:Chapter" resource="#privacy-fingerprinting" rel="bibo:Chapter">
<h3 role="heading" id="h3_privacy-fingerprinting"><span class="secno">9.2 </span>Fingerprinting</h3>
- <p>Malicious applications may be able to fingerprint users or user agents by detecting or enumerating the list of Key Systems that are supported and related information. If proper origin protections are not provided this could include detection of sites that have been visited and information stored for those sites. In particular, Key Systems should not share key or other data between origins.</p>
+ <p>Malicious applications may be able to fingerprint users or user agents by detecting or enumerating the list of Key Systems that are supported and related information. If proper origin protections are not provided this could include detection of sites that have been visited and information stored for those sites. In particular, Key Systems <em class="rfc2119" title="MUST">MUST</em> not share key or other data between origins.</p>
</section>
<section id="privacy-leakage" typeof="bibo:Chapter" resource="#privacy-leakage" rel="bibo:Chapter">
@@ -2001,12 +2001,12 @@
Failure to do so could lead to information leakage to/from Incognito/Private Browsing sessions, across profiles, and even across different browsers, applications, and operating system user accounts.
</p>
- <p>To avoid such issues, user agent and CDM implementations should ensure that:</p>
+ <p>To avoid such issues, user agent and CDM implementations <em class="rfc2119" title="MUST">MUST</em> ensure that:</p>
<ul>
<li>CDMs have a concept of a CDM instance that is associated 1:1 with a MediaKeys object.</li>
<li>Keys, licenses, other session data, and the presence of sessions are restricted to the CDM instance associated with the MediaKeys object that created the session.</li>
<li>Session data is not shared between MediaKeys objects or CDM instances.</li>
- <li>Session data is not shared with media elements not associated with the MediaKeys object that created the session. Among other things, this means a session's keys may not be used to decrypt content loaded by a media element whose <code><a href="#widl-HTMLMediaElement-mediaKeys">mediaKeys</a></code> attribute is not the MediaKeys object.</li>
+ <li>Session data is not shared with media elements not associated with the MediaKeys object that created the session. Among other things, this means a session's keys <em class="rfc2119" title="MUST">MUST</em> not be used to decrypt content loaded by a media element whose <code><a href="#widl-HTMLMediaElement-mediaKeys">mediaKeys</a></code> attribute is not that MediaKeys object.</li>
<li>MediaKeys objects and the underlying implementation do not expose information outside the origin.</li>
<li>Persisted session data, if applicable, is stored on a per-origin basis.</li>
<li>Only data stored by the requesting origin may be loaded.</li>
@@ -2037,7 +2037,7 @@
<dt id="identifier-encryption">Encryption of user identifiers</dt>
<dd>User identifiers in Key System messages could be encrypted, together with a timestamp or nonce, such that the Key System messages are always different. This would prevent the use of Key System messages for tracking except by applications fully supporting the Key System.
- This may be implemented using a <a href="#server-certificate">server certificate</a>.
+ This <em class="rfc2119" title="MAY">MAY</em> be implemented using a <a href="#server-certificate">server certificate</a>.
</dd>
<dt>Site-specific white-listing of access to each Key System</dt>
@@ -2062,7 +2062,9 @@
<p>While these suggestions prevent trivial use of this feature for user tracking, they do not block it altogether. Within a single domain, a site can continue to track the user during a session, and can then pass all this information to a third party along with any identifying information (names, credit card numbers, addresses) obtained by the site. If a third party cooperates with multiple sites to obtain such information, and if identifiers are not per-origin, then a profile can still be created.</p>
<p>It is important to note that identifiers that are non-clearable, non-origin-specific or hardware-bound exceed the tracking impact of existing techniques such as cookies or session identifiers embedded in URLs.</p>
- <p>Thus, in addition to the various mitigations described above, if a browser supports a mode of operation intended to preserve user anonymity, then User Agent implementers should carefully consider whether access to Key Systems should be disabled in this mode.</p>
+ <p>Thus, in addition to the various mitigations described above, if a browser supports a mode of operation intended to preserve user anonymity, then User Agent implementers should carefully consider whether access to Key Systems should be disabled in this mode.
+ For example, such modes <em class="rfc2119" title="MAY">MAY</em> prohibit creation of <a href="#idl-def-MediaKeySystemAccess" class="idlType"><code>MediaKeySystemAccess</code></a> objects that are <code><a href="#widl-MediaKeySystemOptions-stateful">stateful</a></code> or use a <code><a href="#widl-MediaKeySystemOptions-uniqueidentifier">uniqueidentifier</a></code> (either as part of the CDM implementation or because the application <code><a href="#idl-def-MediaKeysRequirement.required">"required"</a></code> them).
+ </p>
</section>
<section id="privacy-storedinfo" typeof="bibo:Chapter" resource="#privacy-storedinfo" rel="bibo:Chapter">
@@ -2073,10 +2075,14 @@
<dl>
<dt>Origin-specific Key System storage</dt>
- <dd>User agents may require that some or all of the Key System's persistently stored data is stored in an origin-specific way. Session data, licenses, and keys that are persistently stored should be stored per-origin.</dd>
+ <dd>
+ Any data persistently stored by the CDM that might impact messages or behavior in an application- or license server-visible way <em class="rfc2119" title="MUST">MUST</em> be stored in an origin-specific way.
+ Session data, licenses, and keys that are persistently stored <em class="rfc2119" title="MUST">MUST</em> be stored per-origin.
+ See <a href="#session-storage">Session Storage and Persistence</a>.
+ </dd>
<dt>User deletion of Key System storage</dt>
- <dd>User agents may present the user with a way to delete Key System storage for a specific origin or all origins.</dd>
+ <dd>User agents should present the user with a way to delete Key System storage for a specific origin or all origins.</dd>
<dt>Treating Key System stored data like cookies / Web Storage</dt>
<dd>User agents should present the presence of persistent data stored by Key Systems to the user in a way that associates it strongly with HTTP session cookies and/or Web Storage. This might encourage users to view such data with healthy suspicion.</dd>
@@ -2085,18 +2091,18 @@
<dd>User agents should treat data stored by Key Systems as potentially sensitive; it is quite possible for user privacy to be compromised by the release of this information. To this end, user agents should ensure that such data is securely stored and when deleting data, it is promptly deleted from the underlying storage.</dd>
</dl>
- <p>User agent and CDM implementations that allow the CDM to persist data should:</p>
+ <p>User agent and CDM implementations that allow the CDM to persist data:</p>
<ul>
- <li>Ensure it is restricted to the origin for which it was created.</li>
- <li>Ensure it is restricted to the current profile and does not leak to or from Incognito/Private Browsing sessions.</li>
- <li>Allow the user to clear it, preferably by origin.</li>
- <li>Treat it like other site data, including presenting it along with cookies, including it in "remove all data", and presenting it in the same UI locations.</li>
+ <li><em class="rfc2119" title="MUST">MUST</em> ensure it is restricted to the origin for which it was created.</li>
+ <li><em class="rfc2119" title="MUST">MUST</em> ensure it is restricted to the current profile and does not leak to or from Incognito/Private Browsing sessions.</li>
+ <li>Should Allow the user to clear it, preferably by origin.</li>
+ <li>Should treat it like other site data, including presenting it along with cookies, including it in "remove all data", and presenting it in the same UI locations.</li>
</ul>
</section>
<section id="privacy-secureorigin" typeof="bibo:Chapter" resource="#privacy-secureorigin" rel="bibo:Chapter">
<h3 role="heading" id="h3_privacy-secureorigin"><span class="secno">9.6 </span>Use Secure Origin and Transport</h3>
- <p>In order to protect identifiers and other information discussed in previous sections, user agents may choose to only support the EME APIs and/or specific Key Systems (i.e. based on privacy and security risks) on secure origins.
+ <p>In order to protect identifiers and other information discussed in previous sections, user agents <em class="rfc2119" title="MAY">MAY</em> choose to only support the EME APIs and/or specific Key Systems (i.e. based on privacy and security risks) on secure origins.
This is especially important if a user agent chooses to support a Key System implementation that exposes identifiers or other such information without effectively anonymizing it in transit (i.e. without <a href="#identifier-encryption">encrypting identifiers</a>).
</p>
<p>Regardless of user agent limitations, applications should use secure transport (e.g. HTTPS) for all traffic containing messages from the CDM (i.e. all data passed from <code><a href="#dom-evt-message">message</a></code> events and to <code><a href="#widl-MediaKeySession-update-Promise-void--ArrayBuffer-ArrayBufferView-response">update()</a></code>).</p>
--- a/encrypted-media/encrypted-media.js Wed Oct 15 09:51:50 2014 -0700
+++ b/encrypted-media/encrypted-media.js Wed Oct 15 09:54:01 2014 -0700
@@ -168,6 +168,7 @@
'option-initDataType': { func: idlref_helper, fragment: 'widl-MediaKeySystemOptions-initDataType', link_text: 'initDataType', },
'option-videoType': { func: idlref_helper, fragment: 'widl-MediaKeySystemOptions-videoType', link_text: 'videoType', },
'option-stateful': { func: idlref_helper, fragment: 'widl-MediaKeySystemOptions-stateful', link_text: 'stateful', },
+ 'option-uniqueidentifier': { func: idlref_helper, fragment: 'widl-MediaKeySystemOptions-uniqueidentifier', link_text: 'uniqueidentifier', },
'keySystem-attribute': { func: idlref_helper, fragment: 'widl-MediaKeySystemAccess-keySystem', link_text: 'keySystem', },
// 'createMediaKeys': { func: idlref_helper, fragment: 'widl-MediaKeySystemAccess-createMediaKeys-Promise-MediaKeys', link_text: 'createMediaKeys()', },