<cpn> scribenick: cpn
<kaz> Recorded video from this call
Mark_Vickers: Welcome to the IG call.
We'll be talking about EME v.Next. This started as a requirements
project in the IG
... The first version was co-authored by Microsoft, Google, and
Netflix.
... Today we have Mark Watson from Netflix, one of the EME authors,
and Joey Parrish from Google, who are working on some of the new
feature incubations.
Joey: I'm working on a couple of
minor features of EME v.Next
... I'll go through the feature incubations and update on status
for each one.
<Barbara> Will the slides be available after the call?
Joey: Netflix has been working on
Persistent Usage Record Sessions,
... and I have been working on HDCP Detection, Encryption Scheme
Query, Find Session API.
... In the future I'm planning to work on Internal Key
Rotation.
Joey: Mark will talk about
Persistent Usage Record. This was also known as Secure Stop.
... This keeps a record of the usage of a licence, to be sent to
the server when the session is closed.
... The text has been published. The full spec is in Mark's
repo
... No open issues, no new TAG review since initial EME.
... It's partially supported in Chrome 70. Session Type has been
added to Chrome, but not yet to the Widevine CDM, so it's not
useable yet, but groundwork has been laid.
Joey: The HDCP Detection API allows
an application to decide what HDCP level could be supported before
fetching content, so it can make a better decision up front.
... The explainer and spec text have been published. It's enabled
by default in Chrome 73.
... There are 5 open issues, including one from TAG review on
privacy implications.
scribe: The Encryption Scheme Query
allows an app to specify the encryption scheme when it's
negotiating a CDM instance.
... This is added to the configuration that's sent to
requestMediaKeySystemAccess()
... The explainer has been published, not yet written the spec
text.
... Chrome ran an origin trial with positive feedback, TAG review
had no cause for concern.
Joey: The Find Session API
was originally thought to do two main things. Deduplicate init data
or duplicate sessions,
... as the ? doesn't in general know what the init data represents,
it doesn't have any concept of a Widevine content ID, for example,
it just has to look at a binary blob of data and decide whether or
not to create a session.
... This was to allow the CDM to give feedback if you already have
a session, no need to create a new one.
... I thought it could also handle key rotation, but feedback from
FOMS said this was overloaded and too subtle. It's stuck in draft
state right now.
... I'll refocus this on session deduplication, and have a separate
proposal on internal key rotation.
... Any questions?
Stuart: About the Find Session API, would this be useful for interrogating what keys or key IDs are in the data?
Joey: Right now, no. For some init
data, it will either give you a session or null.
... It will let you know that you already have handled this init
data sufficiently, or not. As far as I know, there's no way to get
a full list of sessions or to get a particular set of keys.
... I don't recall if the key status is stored in the session, or
if it's given to you through the key status update events, will
check.
Stuart: So it enables you to decide whether or not to call createSession() again?
Joey: Exactly. In particular,
applications that can't parse the PSSH, which if you're trying to
do things generically is the case, they don't have a way to know
whether a particular PSSH or init data is necessary to create a new
session.
... For example, Widevine has content IDs, where a single content
ID maps to multiple keys: video key, audio key, etc.
... If you have init data for each different stream, that's a
different binary blob, but they all contain the same content ID,
you don't actually need multiple sessions.
... But there's no way for the application to understand that
without doing a deep parse of the init data.
... That's what this was intended to solve.
Mark_Vickers: Is there an overall goal for next-gen EME and MSE to eliminate or reduce the need to parse headers in JavaScript, or it just the case here?
Joey: This is the only case I've
found where this was needed. There are some minor interoperability
issues between DRM systems. For example, the need to extract part
of the message from generateRequest in PlayReady to then send to
the license server,
... compared to Widevine where it's sent directly without parsing.
There are some other minor interoperability issues like that, that
require parsing.
... This is the only one that doesn't go into the details of
specific DRM systems.
... On the earlier question, you can get key statuses and key IDs
from a session object, so the Find Session API would allow you to
find the specific key IDs associated with a session.
Mark_Vickers: You mentioned the TAG review for HDCP Detection, a privacy concern. Was that about fingerprinting? Many APIs have the same issue, e.g,. Encryption Scheme Query. What specifically is different between HDCP than encryption scheme detection?
Joey: The encryption scheme is a bit
less specific to the user, it's more about the platform. For
different browsers and operating systems, that combination will
determine what encryption scheme is available. So it's not really
any different to a UA parse.
... HDCP detection is about display capabilities, what type of
display is connected, which is more specific to the user. That's my
guess as to why the TAG raised this for one and not the other.
Mark_Vickers: The HDCP detection is a binary result?
Joey: Yes, you get a key status, either useable or output restricted.
Mark_Vickers: Not to minimise the fingerprinting problem, but I wonder how it applies to any API that returns state. Is there some overall guidance on APIs that return state? Maybe more of a TAG question.
Joey: I'm new to W3C and the process, would like to get the answer to that.
Jer: I think the reason TAG raised this for HDCP Detection as that it allows you to detect multiple key levels, there's multiple bits of information. There might be an increasing number of HDCP levels in the future, so there is an unbounded number of bits you can use for fingerprint detection.
Joey: As the API query is for a specific HDCP level, you could query for multiple levels, and map out one bit of data, i.e., the minimum threshold of HDCP support, and as HDCP is extended so it's potentially unlimited number of bits of fingerprint.
Mark_Watson: Also what I got from the
TAG response, there was a value judgement being made for what you
get in return for exposing the additional bits of fingerprinting
surface.
... For HDCP detection, it's an optimisation to allow players to
get to the higher quality faster. For encryption scheme detection,
it's different, if the content is encrypted in a particular way,
and if it's not supported by the browser, then you can't play it at
all.
Barbara: Has the Media WG started meeting yet?
<jernoble> Jer: is still getting approval to join the WG
Mark_Vickers: It has been formed, but not started meeting yet. On our last call, we heard that the WG chairs are deciding on their process and how they'll work. They confirmed there'll be a meeting at TPAC in Japan.
Mark_Watson: Persistent Usage Record
was part of EME v1, not included in the v1 spec, still under debate
at the time, and not two interoperable implementations, so it was
removed from v1.
... It's been stable since v1, there's a draft of a modified
spec.
... The purpose of the feature is a fraud detection scheme. It
provides an after-the-fact robust record of which keys were used,
the earliest and latest time they were used, and proof that those
keys are no longder present at the client.
... It allows you to correlate offline the key usage information
from the CDM with other application data you may have.
... Typically your application knows which users have accessed
which content, and when they were playing, based on messages
between JS code in the client and your application servers.
... Because those messages come from JavaScript in the client, it's
relatively easy to modify or suppress them.
... With Persistent Usage Record, because these messages come from
the CDM, it's relatively hard to modify. If you see some lack of
correlation between the information in the persistent usage record
and your other application data, you can detect that something
unusual is going on.
... The most likely way to interfere is to suppress the persistent
usage record altogether, and that can be detected with offline
analysis, where license keys for a particular account have a low
rate of persistent usage record compared to what you expect.
... The type of fraud you're able to detect with this would be
evasion of business rules, e.g., in the case of Netflix, the number
of concurrent streams depending on the user's account level.
... How does it work? There's a new persistent-usage-record session
type. In the previous spec there's temporary session type and
persistent-license session type.
... At the end of the session, you get a license release message
that contains the record of key usage. You can then use the update
method to confirm that that message has been persisted at the
server, and clear the persisted session data.
... The record of key usage will stay persisted on the device until
this exchange has taken place.
... This exchange can happen at the end of a session, or at the
start of a new browsing session.
... You can use the MediaKeySession.load() method with the original
session ID to retrieve the session with the record of key
usage,
... then the license release and update message exchange can take
place to provide it to the server.
... We need it for a new browsing session, for cases where the
original session ends abruptly during playback, could be due to
page close or loss of power or connectivity. You can pick up the
records later.
... There'll be some level of missing records, a heuristic you'll
need on the fraud analysis side to detect when the level of missing
records is expected due to these causes, and when is it might be
fraud.
... There are no licenses or keys persisted. So persistent usage
sessions behave like temporary sessions. It's about persisting the
record of key usage.
... Because the license keys are destroyed before the record of key
usage is provided, if you get the record of key usage at all, it
shows there key is no longer on the client.
... We require the accuracy of timing to be at worst 60
seconds.
... We don't specify anything about the robustness, not in scope of
the EME specification. It's DRM specific, as with the format of the
messages.
... There's no requirement that the browser interacts with the page
on page close. When the page is closed, all interaction with
JavaScript on the page stops. This why we can't force the record of
key usage exchange to happen on page close, and instead you have to
do it later.
... Status: it's in the incubation repo. It had a TAG review during
the v1 timeframe. Some controversy due to amount of work done on
page close, and we didn't have two interoperable implementations
then.
Mark_Vickers: A previous issue was that there weren't interoperable implementations, did something change regarding page close?
Mark_Watson: There were concerns at
the time around how much work the browser would need to do at page
close to persist the usage record.
... There are implementations that store every 10 seconds, that
mechanism can work. Then there's no requirement for extra work on
page close.
... To do this entirely in software without robust persistent
storage then you need to at least save the usage record to
disk.
... Google had concerns at the time, but in the end it was removed
because there weren't interoperable implementations.
Jer: We have an implementation in the most recent Safari technology preview. So thereis one hopefully interoperable implementation, so waiting for one more, from one of the other browser vendors.
Mark_Watson: The implementation we had before was in Edge, but I don't know it's current status.
Mark_Vickers: Joey, what's the implemntation status of the features you covered?
Joey: I'm not aware of the implementation status outside of Chrome.
Jer: We have Encryption Scheme Query
implemented in the Safari technology preview.
... We don't have HDCP Detection. We have fingerprinting
concerns.
Joey: The other features are too early for implementations.
Will: It seems that one of the most
important changes in EME v.Next should be an identical workflow
between the three main DRM systems in terms of player interactions.
I believe there are still some inconsistencies between how Widevine
and Playready are supported.
... Is a goal for EME v2 to iron out those differences, or is it
acceptable that there are still workflow differences?
Joey: I would like it better if it
were identical across DRM systems. I don't have that as a goal for
EME v2, personally.
... It gets complicated with the DRM providers. It goes beyond the
vendors, Widevine, Apple, and Microsoft because there are third
party providers that offer license services.
... We're talking about how the application has to interact with
the license server,
... we'd require a specific workflow between the servers and the
CDM. We mxight be able to achieve that when talking directly with
services from the DRM vendors,
... but it seems outside the scope of a UA specification.
... The situation now, where Playready requires some information to
be extracted from the message before being sent to the server,
that's no worse than what you do for the third party vendors.
... I think it would be nice for authors not to have to deal with
those details, but I don't have it as a goal, and maybe it's out of
scope for W3C.
Mark_Watson: I agree with Joey, there
are aspects to do with interactions with license servers, that
differ per DRM, that are out of scope.
... There are interactions with the page, across the API, where the
spec allows multiple ways of achieving the same end goal, e.g.,
having multiple keys be used.
... For a given piece of content, could be delivered in one sesson
or multiple sessions, etc.
... At present different browsers support different permutations
and combinations.
... If people find it problematic, please file issues. We'll look
at all open issues in the Media WG.
... If there are examples where the spec could be tightened up, or
if we can develop guidelines, that could be in scope.
Joey: I agree.
Stuart: One of the issues that should be tightened up is the robustness specification. This is CDM specific, yet part of the EME spec.
Joey: Personally, I'd like to see the
robustness part of the API removed. They were only implemented by
Widevine. The only values specified are the ones from Widevine, by
convention.
... There's only one platform where it can influence the choice of
CDM, that's Android.
... If what they're used being for today is a gating factor, to say
don't create a CDM if you don't meet these requirements, or for
Android to force a software CDM in the case of buggy hardware,
there are better ways to achieve that.
... I'd prefer to deprecate robustness settings and come up with
something better.
Mark_Watson: As with HDCP detection,
depending whether hardware or software CDM, you may have access to
different content. Being able to discover that before downloading
content is useful.
... The codecs available may be different, depending on whether
it's hardware or software CDM. Need to know that to decide when
downloading content.
Joey: That could be solved with key system identifiers. If the request fails, you can fall back to software, use a different configuration or serve different content.
Mark_Watson: That sounds like it could work. I don't have a strong opinion on solution.
Mark_Vickers: If you're commenting on
the new v.Next features, there are WICG repos for each.
... I suggest the issues we've brought up here should be filed, to
record them for the future.
<MarkVickers> Please file EME issues here: https://github.com/w3c/encrypted-media/issues
Greg: On robustness, for PlayReady we're using different key systems for hardware vs software and it works quite well. It could be a solution for identifying and controlling which CDM is used.
<kaz> scribenick: kaz
Chris: I have a general question. How
closely is EME tied to MSE?
... Something we've discussed on previous calls is low latency
video playback, using different distribution protocols, for low
latency, such as WebRTC DataChannel, and Peter Thatcher's recent
WebTransport proposal. Is EME amenable to these distribution
protocols?
Joey: I don't see any reason why EME
could not be used for that purpose, hypothetically.
... As far as I know, there's no way for those APIs to work in
concert today.
... EME would have you negotiate for a MediaKeys instance that
represents the CDM, and then attach that to an HTML5 video
element.
... As far as I know, there's no other API where you could attach a
MediaKeys instance.
... Hypothetically, a CDM could provide decryption services within
the browser to other systems, but that doesn't exist today in any
implementation.
<Barbara> WebCodec was also discussed. Impact
<cpn> scribenick: cpn
Mark_Vickers: What about Type 1, do any implementations invoke EME?
Joey: Yes. You can do that in Safari
with AirPlay, also in Chrome with single files, pointing the src to
a single mp4 or WebM file.
... I don't know how well supported that is today, but in the early
days that was supported by EME in Chrome. I don't know what the
status is in the spec.
Jer: Support for Type 1 is only available for HLS streams, not single files.
Joey: That's the case for Safari. In Chrome it was supported for a different use case, but also type 1.
Mark_Vickers: I thought it should logically work, not sure if it was something people wanted.
<Barbara> Would WebCodec that was discussed at the Web Game Workshop. Part of Media Working Group?
Mark_Vickers: Is there anything you call on from the M&E IG, e.g., requirements gathering or a project?
Mark_Watson: In terms of the process
going forward, if you're interested in understanding the features,
it's helpful to look at the tests.
... It's one of the best ways to learn and get into the details,
and helps us get the features working.
... Tests are in the EME directory in the WPT repo.
Mark_Vickers: Do we have good test coverage of the v1 spec? Do we need additional contributions for tests for EME v1?
Mark_Watson: We have a test for each
interaction model, but in many cases only one.
... There is an amount of coverage, incomplete, for every
permutation and combination of the way the API could be used.
... In practice, you have to stick closely to the interaction
model. There could be some cracks, things that satisfy the
specification but may not work in implementations.
<Barbara> Test is good. Thoughts on benchmark suite. WASM is starting to look at create a benchmark suite. Something to add over time.
Barbara: Also discussed at the Web games workshop last week, was WebCodec. It as positioned as something under development. How does it relate to the Media WG?
<kaz> scribenick: kaz
Chris: WebCodecs is a proposal from
Peter Thatcher to expose the web browser's media capability for
encoding/decoding
... It's a very early stage proposal, not yet accepted into WICG.
Peter now is looking for support to get it into incubation.
Barbara: I wanted to share with this group, as it's interesting.
Chris: It's a slightly different topic from EME itself, but it's very interesting, and I'd like to invite Peter to tell more details.
Barbara: The other thing for the
Media WG, is an evolution from the WASM team.
... They're starting to talk about a benchmarking suite, early
testing, how is everything working?
... Maybe over time is looking at these benchmarking suites, and
possible looking at what the WASM team is trying to uncover.
Mark_Vickers: Any other questions?
<Zakim> kaz, you wanted to ask both the speakers if it's possible to send their slides to the MEIG public list later
<MarkVickers> Join Media WG here: https://www.w3.org/media-wg/
<jeff> Mark++ for Media WG link
Kaz: Can we share the slides on the mailing list?
Joey: OK
Mark_Watson: OK
<cpn> scribenick: cpn
Mark: Next call is in a
month's time, topic to be decided.
... Thank you to Mark, Joey, and Jer. This was very useful.
... I encourage everyone to continue discussion in the GitHub
repos.
<cpn> I'm having audio issues. Suggest Media Playback Quality for next time?
<MarkVickers> Media Playback Quality would be great for next time
<MarkVickers> Thanks to Kaz for making the meeting run well!!