How to gatekeep the EME "API to find existing sessions"?

[samuelweiler]

The charter is proposing an EME extension "to find existing sessions", and the link under that text points to an essentially-empty repo created three years ago. https://github.com/joeyparrish/encrypted-media-find-session

What is the WG's plan for how to limit access to that API?

(I'm calling this out separately because it's not really about capability detection nor negotiation - it's about exposing state that is more user-specific.)

[tidoust]

@joeyparrish or @gregwfreedman, could you shed some light on this?

[joeyparrish]

The repo looks empty because the "master" branch essentially is. But there's an explainer in the "draft" branch: https://github.com/joeyparrish/encrypted-media-find-session/blob/draft/explainer.md

The proposal never went beyond a draft state, and in early conversations in the WG, we decided it was a bad idea in its current form. My proposal was meant to address two cases:

1. Internal key rotation
2. Deduplicating MediaKeys sessions

The "Alternatives Considered" section of that original proposal lays out three other ideas that might be better solutions to one or both issues. None of these solutions exposes any "user-specific" state. One proposes to add a method which returns a boolean, one proposes to add a boolean return to an existing async method, and one proposes to update an algorithm to allow the CDM not to send a message if it chooses.

[samuelweiler]

Thanks @joeyparrish !

in early conversations in the WG, we decided it was a bad idea in its current form.

It sounds like we should drop this work item from the WG's Scope for the moment?

[joeyparrish]

I would like to instead develop a proposal based on one of the alternatives in the explainer doc.

[tidoust]

I would like to instead develop a proposal based on one of the alternatives in the explainer doc.

Could an update to the draft charter help clarify the intent? For instance, replacing "an API to find existing sessions" with "an API to reuse an existing session when possible"?

[samuelweiler]

Could an update to the draft charter help clarify the intent? For instance, replacing "an API to find existing sessions" with "an API to reuse an existing session when possible"?

That doesn't really address my concern.

I would prefer not to charter work to enumerate sessions without a story on how we're limiting access to that enumeration. I'm happy to consider adding in back in during the term of the charter, assuming such a story is developed.

[joeyparrish]

That doesn't really address my concern.

I would prefer not to charter work to enumerate sessions without a story on how we're limiting access to that enumeration.

@samuelweiler, enumerating sessions was just one solution to avoid duplicate sessions and wasted hardware DRM resources. The alternatives I pointed toward developing further would not require enumeration of any kind.

Were you primarily concerned about privacy or fingerprinting? Does this address your concerns?

[samuelweiler]

@joeyparrish I think it would help to know that the state was partitioned, e.g. by origin. I'm trying to avoid the cross-origin communication vector. Is the intent that we're only looking for sessions from the same origin? If so, and we make that constraint clear, I'd be fine with this in the charter.

[joeyparrish]

Ah, I see. Yes, the intent is that we allow an application to avoid creating unneeded (duplicate) sessions. You can read about the alternative solutions here: https://github.com/joeyparrish/encrypted-media-find-session/blob/draft/explainer.md#alternatives-considered

Here are the headings from that, to give you a quick sense of what I'm thinking of:

1. Allow generateRequest() not to send a 'message' event
2. Change generateRequest() to resolve with a boolean
3. Add a method to ask if a new session is needed

So in terms of information flow and access, we would either:

1. Get a call with init data, asking to generate a license request (existing method), then potentially ignore it if it would result in a duplicate session
2. Get a call with init data, asking to generate a license request (existing method), then potentially respond with a boolean "no" if it would result in a duplicate session
3. Add a new method that would take init data and respond with an (async) boolean to say whether or not the above method would result in a duplicate session

[tidoust]

@joeyparrish, my understanding from @samuelweiler comment is that he would like to make sure that a page with origin A cannot access sessions created in a page with origin B. Similar to the way an Indexed database is scoped to an origin for instance. I suspect that this is the case. My understanding reading the EME spec is that all identifiers are unique per origin (see e.g. session IDs and Use origin-specific and browsing profile-specific Key System storage), so presumably that is the case already?

In the end, what I need here is not a discussion on the merits of possible alternatives, but convergence on charter text that can describe the envisioned feature and give enough confidence that the feature can be specified in a way that can avoid cross-origin communication.

Would "an API to reuse an existing session within the same origin when possible" achieve that? Any better suggestion?

[joeyparrish]

My understanding reading the EME spec is that all identifiers are unique per origin

I believe that's true, yes.

what I need here is not a discussion on the merits of possible alternatives, but convergence on charter text
Would "an API to reuse an existing session within the same origin when possible" achieve that? Any better suggestion?

How about "a means to avoid creating duplicate sessions within the same origin"? We don't really need to do anything new with the existing sessions, just not create new ones.

I would also really like to address "a specified means of internal key rotation" or "key rotation without license exchanges" if possible during the lifetime of this charter.

I'm not sure if these are phrased properly for the charter, but this is how I think of them.

[tidoust]

How about "a means to avoid creating duplicate sessions within the same origin"? We don't really need to do anything new with the existing sessions, just not create new ones.

That looks good to me. I prepared #28 accordingly. @samuelweiler, how does that look?

I would also really like to address "a specified means of internal key rotation" or "key rotation without license exchanges" if possible during the lifetime of this charter.

Wait, is that part of the same feature? If so, that may warrant adjusting the text a bit more as the session reuse and key roration seem orthogonal to me. If not, that is going to be hard for this charter. New features for EME need to be explicitly listed in the charter, and introducing a new one is unlikely going to be a straightforward process. At a minimum, I would need strong support within the Media WG to introduce that in the charter, and we're already running late for this re-chartering.

[joeyparrish]

You're right. Key rotation is a separate feature. In the early days of the previous charter, I expected that both features could be handled by a single solution ("find existing sessions"), but I was advised by (IIRC) Jer Noble not to take that route.

If it doesn't make sense to have key rotation in the charter, then I can live with that. But it would be nice to be able to finally take care of that. Here are the open issues related to key rotation, both from 2015, which I think could reasonably be considered duplicates at this point:

• Allow for long-lived key encryption keys (aka "master" keys) to increase performance encrypted-media#53
• EME should support continuous key rotation per MPEG Common Encryption (ISO/IEC 23001-7) encrypted-media#132

[gregwfreedman]

@joeyparrish Since binary comparison of initData is imperfect, how about a static method that extracts keyId's from initData? Then just check each session's KeyStatuses for that keyId.

[joeyparrish]

That would work for me.

[samuelweiler]

#28 looks good to me. I strongly urge the WG to seek early privacy review of all three of these EME features as you make progress on them.

[joeyparrish]

Can do. Thanks!

[joeyparrish]

@samuelweiler, what's the process for requesting a privacy review on a feature or proposal?

[tidoust]

@samuelweiler, what's the process for requesting a privacy review on a feature or proposal?

See "Privacy" in https://www.w3.org/Guide/documentreview/#how_to_get_horizontal_review

[joeyparrish]

Perfect. Thanks, @tidoust!

[tidoust]

Discussed during today's Media WG call. I merged the PR accordingly. Continuous key rotation is to remain out of scope for now.

Closing the issue accordingly.