You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are some other W3C specs and proposals managing storage in general. And the EME spec should clarify the behavior of the Persistent Data related to those specs.
For example, Clear-Site-Data response header is a way for sites to clear data they've previously stored (most common example being on logout). The header can specify different directives, e.g. cache, cookies or storage, where the storage directive means to remove all DOM storage for the origin of the response URL, including storage mechanisms such as localStorage, IndexedDB, FileSystem API data etc.
Given the storage directive includes so many storage mechanisms, the question is whether EME persistent storage should be part of it.
The text was updated successfully, but these errors were encountered:
There are a few things that's special about EME persistent storage:
EME persistent storage is not a generic storage API. It's closely tied to the EME spec and the underlying CDM.
The clearing of persistent license data requires a specific sequence with the facilitation of the JavaScript player and license server. The player should call remove() to generate a "license-release" message, and use it to fetch a message that contains a record of license destruction acknowledgement. The CDM should only remove all stored session data associated with this object, including the sessionId and record of license destruction after this.
Some data stored by the CDM is not directly managed by the user agent. They could be managed by the underlying operating system, e.g. on Android by MediaDrm API. While the user agent will make every effort to clear the data, it's ultimately controlled by the OS.
Allowing Clear-Site-Data to clear EME persistent storage could be useful feature for sites to clear all data stored by the site, including EME persistent storage. But there might also be sites which want to clear other storage but not EME persistent storage. Because of (2), sites might want EME persistent storage not to be cleared by Clear-Site-Data header, to avoid losing persistent license data/record, assuming the session ID is stored separately, e.g. in cookies instead of in storage.
It seems potentially useful that the storage type could include EME storage. What is the use case for keeping EME data if a site sends Clear-Site-Data with storage? How does this play into the concern documented in the Incomplete Clearing of Data section in the privacy considerations?
There are some other W3C specs and proposals managing storage in general. And the EME spec should clarify the behavior of the Persistent Data related to those specs.
For example, Clear-Site-Data response header is a way for sites to clear data they've previously stored (most common example being on logout). The header can specify different directives, e.g.
cache
,cookies
orstorage
, where thestorage
directive means to remove all DOM storage for the origin of the response URL, including storage mechanisms such as localStorage, IndexedDB, FileSystem API data etc.Given the
storage
directive includes so many storage mechanisms, the question is whether EME persistent storage should be part of it.The text was updated successfully, but these errors were encountered: