Expose unclosed and unremoved MediaKeySessions on MediaKeys

[dmlap]

It seems to me that having access to the non-removed, non-closed set of MediaKeySessions would be handy for EME application developers, and consistent with other media element extensions (activeSourceBuffers on Media Sources, for instance). I do not see any property that would provide access to the active media key sessions in my reading of the IDL. Is there a security concern with providing a list of active media key sessions?

[ddorwin]

What is the use case?

I believe the reason that sessions are not exposed from the MediaKeys object that created them is that this is something that the application can easily do with custom properties. The same applies for references from the MediaKeySession to the MediaKeys object that created it.

[dmlap]

Two main reasons: debuggability and library inter-op.

Programming being what it is, developers inevitably discover errors in production code and pop open the console to investigate the state of their application. With sufficient foresight, they may have exposed the set of active MediaKeySessions. Correctly doing so requires setting up keystatuschange listeners (I believe) which isn't too hard but it is possible to fumble. More importantly, if everyone is going to end up exposing MediaKeySessions because it's a vital piece of state when working with protected content, EME can save developers from copying and pasting that code all over the internet.

The library inter-op issue is more important in my mind. In modern web development, there are a lot of cooks in the kitchen. Analytics, advertising, browser incompatibilities, and organizational considerations often make video playback a collaborative effort. Having a standard location to introspect on playback of protected content allows those actors to coordinate at the spec level instead of integrating against each player individually.

[jdsmith3000]

I believe the proposal is to have a means for querying EME and obtain a list of currently active sessionIDs. These could have keys in various states. As a minimum case, it would include sessions that are currently active and not previously closed or removed. This list presumably could also include sessions not currently active, but also not previously removed (as might occur if a browser was abruptly closed during playback).

I could see a feature like this being used to:

1. Check for active sessions during playback, so that ones no longer needed could be actively removed.
2. On launch, check for sessions not previously closed so that they could be securely released.

Both of these are scenarios that the current EME specification considers application responsibilities, since they can be independently monitored by keeping an app record of sessionIDs. That is not viewed as very difficult, but there could be an argument made that providing a way to query sessions is a bit more robust.

[jdsmith3000]

It does seem clear that the scenarios that would be supported by this feature are possible today, and in fact, application tracking of sessions is generally assumed in several of our EME operations now. Our philosophy has been to unblock scenarios with minimal API layers, and then evolve the spec based on experience gained in its use. In the scenarios involved here, that has already been accomplished. That suggests this change not be adopted, at least until further experience with the API suggests it is needed.

[steelejoe]

I am not in favor of doing this unless it becomes clear from implementation experience that this would be helpful. I don't actually like the current mechanism and I would like to leave the door open for changing it in the future. Adding this might make that more difficult.

[ddorwin]

There was agreement in the telecon today (some of which is described by the previous two comments) not to add this functionality at this time.