- From: Chris Needham <chris.needham@bbc.co.uk>
- Date: Tue, 9 Jul 2019 07:08:14 +0000
- To: "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
Dear all, The minutes from the Media & Entertainment Interest Group call on Tuesday 2nd July are available [1], and copied below. Many thanks to Joey and Mark giving an update on the new feature incubations for Encrypted Media Extensions. A recording of the conversation is available [2]. Kind regards, Chris (Co-chair, W3C Media & Entertainment Interest Group) [1] https://www.w3.org/2019/07/02-me-minutes.html [2] http://media.w3.org/2019/07/meig-2019-07-02.mp4 -- W3C - DRAFT - Media and Entertainment IG 02 Jul 2019 Agenda Attendees Present Joey_Parrish, Kaz_Ashimura, Mark_Vickers, Chris_Needham, Greg_Freedman, John_Luther, Steve_Morris, Mark_Watson, Will_Law, Tatsuya_Igarashi, Stuart_Espey, Kris_Walker, Patrick_Myers, Stephan_Pham, Barbara_Hochgesang, Francois_Daoust, Nigel_Megitt, Kumanan_Yogaratnam, Ali_C_Begen, Jer_Noble, Nicolas_Beddows, Jeff_Jaffe Regrets Chair Mark_Vickers, Chris_Needham, Tatsuya_Igarashi Scribe cpn, kaz Contents Topics Introduction EME vNext Incubation, Proposals and Status, July 2019 Persistent Usage Record Sessions HDCP Detection API Encryption Scheme Query Find Session API Persistent Usage Record Next call Summary of Action Items Summary of Resolutions <cpn> scribenick: cpn <kaz> http://media.w3.org/2019/07/meig-2019-07-02.mp4 Recorded video from this call # Introduction 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. # EME vNext Incubation, Proposals and Status, July 2019 https://www.w3.org/2011/webtv/wiki/images/c/c6/EME_vNext_Incubation_-_July_2019.pdf Joey's slides 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. # Persistent Usage Record Sessions https://github.com/WICG/encrypted-media Spec https://github.com/WICG/encrypted-media/issues Issues 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. # HDCP Detection API https://github.com/WICG/hdcp-detection/blob/master/explainer.md Explainer https://wicg.github.io/hdcp-detection/ Spec https://github.com/wicg/hdcp-detection/issues Issues https://www.chromestatus.com/feature/5652917147140096 Chrome Status 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. # Encryption Scheme Query https://github.com/WICG/encrypted-media-encryption-scheme/blob/master/explainer.md Explainer https://github.com/WICG/encrypted-media-encryption-scheme/issues Issues https://www.chromestatus.com/feature/5184416120832000 Chrome Status Joey: 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. # Find Session API 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. # Persistent Usage Record https://docs.google.com/presentation/d/1puC3ZTfuh7WFVuOxiYqVmcQdRcXutocN3Cw08pCzHoM/edit Mark's slides 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 # Next call 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!! Summary of Action Items Summary of Resolutions [End of minutes] Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log) $Date: 2019/07/09 06:36:56 $
Received on Tuesday, 9 July 2019 07:12:28 UTC