[Bug 21869] Need clarity on stored keys for CDMs

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

--- Comment #8 from Joe Steele <steele@adobe.com> ---
(In reply to comment #7)
> Compared to what I said above, David Dorwin had an even better idea
> according to the latest meeting minutes.
> (http://www.w3.org/2013/06/18-html-media-minutes.html#item03)
> 
> To expand:
> If you want data to stay around on the client side beyond having it in RAM,
> have the CDM pass an encrypted data packet to the JavaScript application,
> how the JavaScript application store the encrypted packet in IndexedDB and
> then next time have the JavaScript application take the encrypted packet
> from IndexedDB and push it back to the CDM. This way, the privacy controls
> that browsers need to provide for IndexedDB anyway would automatically apply
> to data that CDMs want to keep around.

This is not quite the right approach. This will cause more CDM-specific code to
need to be written. I believe this imposes an unnecessary burden on the app
developer for no additional security or privacy. Consider the CDM to behave
like a local server, and this data to be cookie data. When a web app contacts a
server, it does not have to explicitly store each cookie that comes from that
server. It can inspect them and it can forbid them to be stored, but only if it
wants or needs to. This is the kind of API I would like to se for storage. 

I propose that to satisfy any perceived requirement for additional security, we
add a mechanism to register a storage permission handler which looks something
like this: Boolean AllowStorageHandler(DOMString path, Uint8Array data) 

It would be attached to the MediaKeys object like this:
MediaKeys.onallowstorage

This would be called whenever the CDM wants to store data. If no handler is
attached, the default handler would return True, allowing the data to be stored
like a regular cookie would be. If a handler is attached, then the application
can make the call. There does not seem to be a need for a parallel "AllowRead"
handler, since there is no use case I can think of where the app would allow
writing, but then subsequently choose to disallow reading.

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

Received on Monday, 15 July 2013 16:03:57 UTC