23:46:09 RRSAgent has joined #mediawg 23:46:09 logging to https://www.w3.org/2019/09/18-mediawg-irc 23:46:15 RRSAgent, make logs public 23:46:21 Meeting: Media WG F2F - Day 1/2 23:46:41 Chair: Jer, Mounir 23:48:31 niwamoto has joined #mediawg 23:48:59 Present+ Mounir_Lamouri, Chris_Needham, Narifumi_Iwamoto, Richard_Winterton, Michael_Rosenzweig, Francois_Daoust, Paul_Adenot, Jer_Noble, Jean-Yves_Avenard, Mark_Foltz, Yongjun_Wu, Yikki_Kawamura 23:49:33 Present+ Youngsun_Ryu 23:50:23 Richw has joined #mediawg 23:53:02 Present+ Soju_Tanaka 23:53:26 yuki has joined #mediawg 23:56:07 cpn has joined #mediawg 23:57:00 present+ Greg_Freedman, Scott_Low 23:57:31 Youngsun has joined #mediawg 23:57:51 jernoble has joined #mediawg 23:58:28 takio has joined #mediawg 23:59:37 RRSAgent, this meeting spans midnight 00:00:37 scribe: tidoust 00:01:29 jer: Welcome. Looking at the agenda, any change requested? Couple of changes in the last couple of days. Low-latency video signaling was added today. 00:01:49 MasayaIkeo has joined #mediawg 00:01:52 mounir: I added WebCodecs, audiobooks, and I moved some things around for external folks to be able to join relevant sessions. 00:02:10 Present+ Chris_Cunningham 00:02:24 i/jer: Welcome/Topic: Agenda bashing 00:02:33 urata_access has joined #mediawg 00:02:43 Topic: WG boot up 00:02:47 Soju has joined #mediawg 00:03:12 jer: This is the first meeting of the Media WG. We don't really have a process or norms setup. We didn't want to settle on anything before we had a chance to discuss 00:03:17 present+ Mark_Watson 00:03:31 scottlow has joined #mediawg 00:03:46 jer: When will we have phone calls, F2F, email threads, github issues, etc? 00:04:00 scottlow: I personally like calls, good way to progress issues. 00:04:16 richard: I prefer video calls sometimes. 00:04:33 jer: Sure, that's through WebEx, video is possible. 00:05:07 richard: We had troubles with webassembly groups, went through Zoom. 00:05:24 markw has joined #mediawg 00:05:35 jer: Let's try to start with WebEx 00:05:39 chcunningham has joined #mediawg 00:05:57 narifumi: Guidelines for work mode, communications? 00:06:02 jer: We don't have them yet. 00:06:11 Present+ John_Riviello 00:06:32 markw: I would be in favor of not only have calls on topics, but also a regular cadence of calls. 00:06:34 GregFreedman has joined #mediawg 00:06:40 ... Good way to pop issues back to the top. 00:07:03 ... Calling for consensus on the calls. 00:07:22 mounir: The other side of that is that some groups punt discussions to calls. 00:07:34 ... Work in WICG went well without calls. 00:07:49 ... I could be open to a regular call but don't want to discuss everything. 00:07:53 markw: I agree with that. 00:08:24 cpn: Just would like the call not to overlap with Media & Entertainment IG monthly calls. 00:09:00 JohnRiv has joined #mediawg 00:09:05 mounir: Something we could do. Ada has a bot where you can do /agenda on an issue that adds an issue to the agenda. 00:09:41 ... I don't want to have everyone show up in a weekly call just because the time is booked on your calendar 00:10:19 markw: Yes, not weekly calls. Regular cadence is a way to process backlog and close issues when there's no activity or call for volunteers to address them. 00:10:57 richard: Cancellation when there are no agenda items can be good. 00:11:01 jer: Yes. 00:11:22 ... A monthly cadence seems good. I doubt we'll have nothing to talk after a month. 00:11:55 cpn: Useful to have a dedicated slot on the calendar instead of ad-hoc doodling. 00:11:59 mounir: definitely 00:12:43 ... Everyone here ok with a monthly call? And encourage ad-hoc discussions? 00:13:03 markw: You could have a slot for ad-hoc discussions. 00:13:26 mounir: Yes, encourage ad-hoc discussions, minute the discussions publicly 00:13:37 markw: Right, just make sure that everyone is invited. 00:13:47 mounir: Yes, good point. 00:14:14 markw: Want to emphasize the need to have a triage task during the monthly call. 00:14:18 jer: Yes. 00:14:34 richard: I don't want to take a lot of time on that because you have only one hour. 00:14:51 jer: Thinking about non assigned issues? 00:14:55 markw: yes 00:15:18 jer: So triage could be about assigning issues and not discussing issues in themselves. 00:15:25 ... What about F2F meetings? 00:15:41 ... We have a F2F at TPAC, is that enough? 00:16:03 mounir: Most of us go to FOMS. I don't know if we should use that as a second F2F opportunity. 00:16:24 jer: There's an opportunity to do a meeting. 00:16:32 Present+ Stephan_Steglich 00:16:53 mounir: It would be less exotic, but more convenient for people 00:17:25 markw: I think we should revisit in a couple of months whether we want to have another meeting. Good idea to coordinate with other event otherwise. 00:17:40 mounir: I'm sure 6 months after TPAC, a 1 day meeting is useful 00:18:24 ACTION: jer and mounir to talk to FOMS organizers about interest to co-host a Media WG F2F 00:19:33 https://github.com/w3c/media-capabilities/issues/131 00:19:58 scott: Note Greg's proposal on GitHub 00:20:27 markw: Question on how formal we want to be. We need to understand what the consensus is. 00:20:40 jer: Actions and resolutions are a good way to record the TLDR of meetings. 00:20:52 ... Question is do you want to do it for everything? 00:21:11 mounir: For GitHub issues, I think what works well is aggressively cc'ing people. 00:21:24 ... I don't see any reason to change that, no one complained about changes landed so far. 00:21:35 ... Are there concrete concerns? 00:22:00 scottlow: I don't think that Greg is concerned about anything in particular, just to have a way to track resolutions. 00:22:27 chcunningham: Some GitHub issues may be harder/longer than others 00:22:51 ... The HDR one is tricky for instance. Substantial addition to the spec. 00:23:22 ... I don't feel strongly that we have to formalize the process. 00:23:28 richw has joined #mediawg 00:23:59 scottlow: For new people coming to the group, it may be difficult to understand what's going on. 00:24:09 stepsteg has joined #mediawg 00:24:20 present+ 00:24:23 markw: Good wake up call to have in the issue is to say "I think this is good now" 00:24:45 mounir: Good to point people at pull request. 00:25:16 markw: There may be different alternatives without PR and you want to understant what the consensus is. Proposed resolution seems good. 00:25:21 jer: True. 00:25:34 ... I don't know if we can resolve that now. 00:25:36 yuki_ has joined #mediawg 00:26:00 ACTION: jer and mounir to create an issue on the media-wg repo about the resolution process 00:26:45 PROPOSED RESOLUTION: The Media WG will have monthly calls, and encourage ad-hoc meetings on specific issues 00:26:59 takumif has joined #mediawg 00:27:00 RESOLUTION: The Media WG will have monthly calls, and encourage ad-hoc meetings on specific issues 00:29:26 [Side discussion on versioning for MSE and EME and repos] 00:30:21 https://www.w3.org/2019/05/media-wg-charter.html 00:30:28 jer: Deliverables. I am not an expert on W3C process. We have a number of specs listed in the charter 00:31:29 ... [reviewing the charter] 00:32:21 ... Deliverables include Media Capabilities, Picture-in-Picutre, Media Session, Media Playback Quality, Autoplay policy detection, MSE, EME, all of them coming from the WICG. 00:32:49 ... In the future, we may adopt additional normative deliverables, after incubation in another group. 00:33:17 cpn: One idea we're floating around is to create a Media Community Group that could act as a companion to this group for incubation. 00:33:55 ... The thing we were talking about yesterday is whether we could reorganize the IG into a more CG structure and use that as a place to incubate. 00:34:24 jer: So that could be a potential home for some of the incubations listed in the charter as potential normative deliverable. 00:34:39 ... Did we fail to include some deliverable? 00:35:14 mounir: One additional comment. For MSE, we may extend with additional features. For EME, only 4 additional features listed in the charter, we cannot do more. 00:35:21 jer: Can we do maintenance? 00:35:23 mounir: Yes. 00:35:28 hober has joined #mediawg 00:35:51 chcunningham: I've been pushing a new attribute on the video element. More on HTML. 00:36:01 padenot: just cc everybody. 00:36:37 jer: Yes, we have a generic issue that by definition, some of our specs need to monkey patch HTML, We'll need to have joint session with HTML in te future. 00:37:04 markw: Do we have editors assigned for these deliverables? 00:37:25 mounir: Media Capabilities, chcunningham and I are editors. 00:37:39 ... Picture-in-Picture, François Beaufort and I are editors 00:37:51 s/te future/the future/ 00:38:17 ... Media Session has Becca Hughes and I as editors 00:38:59 ... Media Playback Quality, technically I'm the editor, but I just copied the text out of MSE. 00:39:18 ... Autoplay policy has no one, the plan was to have Paul and Becca. 00:39:43 ... MSE has Matt Wolenetz and folks from Microsoft are no longer there I think. 00:40:16 ... EME has David Dorwin and Mark Watson. David won't continue, but Joey Parrish will take over. 00:40:47 ... Now, let's revisit the list and see what changes we should be making 00:41:02 heejin has joined #mediawg 00:41:09 jer: Given your chairing responsibilities, should we replace you as editor with other? 00:41:47 mounir: Practically speaking, I will only do spec reviews. If people are concerned with my having two hats, no problem dropping from editing, but good to have 2 editors to ensure some peer review mechanism. 00:42:09 ... I am editing 0 spec by myself. 00:42:24 markw: We need to make sure that the other editor doesn't have the same expectation. 00:42:48 mounir: Sure. For Media Capabilities, chcunningham volunteers. Scott, do you want to have someone? 00:43:00 scottlow: Yes. We're interested. Greg would be the one. 00:43:30 PROPOSED RESOLUTION: Add Greg Whitworth as editor of Media Capabilities 00:44:06 RESOLUTION: Add Greg Whitworth as editor of Media Capabilities 00:44:21 mounir: For Picture-in-Picture, anyone interested to join? 00:44:34 jer: Apple is interested in implementing, but cannot take the task. 00:44:38 mounir: Then no change. 00:45:04 ... Media Session, I heard that Mozilla is shipping it, any interest to edit? 00:45:15 padenot: I need to check. I can't commit right now. 00:45:36 ACTION: padenot to check whether someone from Mozilla can become editor of Media Session. 00:46:15 mounir: For Media Playback Quality, I think chcunningham might be willing to edit. 00:46:38 chcunningham: Yes, I started to look into it. 00:47:00 mounir: One issue is that the HTML editors said that they would like to move the spec to HTML. 00:47:08 ... Anyone else on top of chcunningham? 00:47:38 jer: This is a small spec, it may be sufficient to have only one editor. And the editing role might be a pull request against HTML. 00:47:59 ACTION: mounir to swap his name with chcunningham as editor of Media Playback Quality 00:48:21 mounir: I think merging with HTML depends on the content of the spec. 00:48:28 jer: That can be a discussion in the spec. 00:48:42 ... Autoplay policy, are we happy with Becca and Paul? 00:48:54 [group nods] 00:49:14 mounir: For MSE, Matt is happy to continue. 00:49:31 scottlow: I may be able to have someone on our side, I need to check. 00:49:48 GregFreedman: I'm expecting to edit either MSE or EME 00:50:02 mounir: So we'll have someone from Netflix, and maybe someone from Microsoft? 00:50:05 markw: Correct. 00:50:18 mounir: And for EME, same thing for Netflix? 00:50:22 markw: Yes. 00:50:41 mounir: My undersanding is that Joey might be taking over David. 00:50:53 scottlow: Same action for me to look into possible candidates. 00:51:02 bdekoz_ has joined #mediawg 00:51:46 ACTION: markw and GregFreedman to figure out who edits which spec (MSE/EME) among themselves 00:52:03 ACTION: scottlow to check for possible editors for MSE and EME 00:52:49 [going back to agenda bashing] 00:53:03 jer: Anything more for agenda bashing? 00:53:39 scribenick: cpn 00:53:54 q? 00:53:55 francois: We should figure out which of these specs is ready to go to FPWD 00:54:37 ... important from a patent policy perspective 00:55:21 ... the call for exclusions covers anything that's in the spec 00:55:42 mounir: i think media capabilities is ready 00:56:04 ... also picture in picture and media session 00:57:12 francois: the next point that triggers IPR commitment is CR 00:57:53 scribe: tidoust 00:58:23 [side discussion on whether Media Capabilities is ready to go to FPWD, or whether HDR support needs to be baked in first] 00:59:41 kumekawa_ has joined #mediawg 01:01:09 ACTION: jer and mounir to send CfC for publication as FPWD of Media Capabilities, PiP and Media Session the week after TPAC 01:06:12 Joey_Parrish has joined #mediawg 01:14:09 Joey_Parrish has joined #mediawg 01:26:57 yuki has joined #mediawg 01:29:51 tidoust has joined #mediawg 01:30:28 soju has joined #mediawg 01:30:43 takio has joined #mediawg 01:31:43 jernoble has joined #mediawg 01:32:07 Joey_Parrish has joined #mediawg 01:32:11 Howdy 01:32:15 RRSAgent, draft minutes 01:32:15 I have made the request to generate https://www.w3.org/2019/09/18-mediawg-minutes.html tidoust 01:32:56 mdrimages has joined #mediawg 01:34:05 Topic: Encrypted Media Extensions (EME) 01:34:24 mounir: Before we start, in the agenda you had vNext and issues. 01:34:39 jer: Yes, it's about understanding what we want to see in the next version of the spec 01:34:55 mounir: OK, that's mostly for MSE, then, because we're constrained on EME. 01:34:58 jer: Yes. 01:35:50 markw has joined #mediawg 01:36:04 Riju has joined #Mediawg 01:36:35 ving has joined #mediawg 01:38:52 Present+ Joey_Parrish 01:39:20 scottlow has joined #mediawg 01:39:22 jer: We can talk about Persitent Usage Record sessions, HDCP detection, scheme capability detection, and existing session finding. 01:39:30 markw: And maintenance issue 01:39:54 JohnRiv has joined #mediawg 01:40:12 Joey_Parrish: [present context for session finding] 01:40:26 ... Discussion at FOMS was to separate the two issues 01:40:44 jernoble has joined #mediawg 01:40:55 mounir: Joey, can you confirm that you want to take editor's rolve over David? 01:41:00 Joey_Parrish: That's correct. 01:41:15 q? 01:41:23 Zakim has joined #mediawg 01:41:29 q? 01:41:45 Joey_Parrish: One other thing I'd like is to get rid of robustness strings. 01:42:21 ... Matches what Microsoft has done with com.microsoft.hardware / com.microsoft.software 01:42:27 ... There seems to be a better way to do that. 01:42:37 jer: I think that would be considered under maintenance issues. 01:43:07 ... Joey, can you file an issue on that? 01:43:23 mounir: Just to be explicit, we should be using the W3C repo for that. The WICG one should move away. 01:43:55 jer: The ability to push new keys on an existing session through some mechanism is captured in an issue, I think. The issue got punted for next release. Part of maintenance as well. 01:44:03 q+ 01:44:05 q- 01:44:18 Topic: Persistent Usage Record 01:44:26 jer: It was in the spec and got removed. 01:44:56 ... That's a way to have a record of playback to be stored and replayed cryptographically so that the application can verify that the key is no longer in use. 01:45:18 markw: The language has been sitting in the WICG repo. The charter says it's our starting point, so we should upstream that. 01:45:32 mounir: Mark, are you driving this? 01:45:42 ... Any concern with moving that to the main spec? 01:45:59 jya: I would prefer not to implement it 01:46:07 markw: I don't think that's mandatory. 01:46:47 mounir: We are talking about persistent usage record 01:47:29 markw: It's an after-the-fact mechanism for fraud detection. 01:47:46 richard: there shouldn't be objections, that's in the charter. 01:48:01 mounir: OK, seems Mark or Greg should prepare a PR. 01:48:32 markw: Yes, we were actually blocked on ReSpec issues. Now fixed. MSE and EME were built with old versions of ReSpec. 01:48:57 ... There may be work that we can do to switch to the latest version. 01:49:13 Joey_Parrish: Does this mean we're sticking to ReSpec and not Bikeshed? 01:49:42 markw: For the spec that already exist, I would stick to the same system. 01:49:56 ... I won't do the transition at least. 01:50:09 jer: Joey, you can use Bikeshed for new specs, no problem with that. 01:51:07 mounir: HDCP detection and encryption scheme capability detection are WICG repos. 01:52:14 ... HDCP detection can fill a lot of time, given TAG feedback, etc. so would move it to the end. 01:52:21 Topic: Encryption scheme capability detection 01:53:00 jer: Apple Fairplay team would only support CBCS scheme and others CENC. In the meantime, the schemes have been added to the same common file format 01:53:24 markw: The problem still exists. 01:53:49 jer: AV1 is on CBCS exclusively? 01:54:50 niwamoto has joined #mediawg 01:54:57 markw: As far as AV1 is concerned, it's an ongoing goal that all encryption patterns get supported. 01:55:09 niwamoto has joined #mediawg 01:55:12 ... It's understood, I think, that devices that support AV1 need to support all of them. 01:55:56 ... The portion you apply the pattern to has to be a multiple of 16 bytes chunks. 01:56:08 ... [details potential issue with that] 01:56:36 ... Whether we allow both approaches or require one or the other is an open discussion. 01:56:46 jer: Do you think that it has implications for the spec? 01:56:49 markw: I hope not 01:57:20 jer: Apple is interested in clarifying behavior. Any objection to adding to the EME spec? 01:57:43 cyril has joined #mediawg 01:57:45 Joey_Parrish: Chrome supports both CBCS and CENC. Just no way for an application to query that yet. 01:58:26 https://wicg.github.io/encrypted-media-encryption-scheme/ 01:58:31 stepsteg has joined #mediawg 01:58:33 ... Prepared an explainer. 01:58:54 ... It just adds one encryption scheme. Minor change. 01:59:06 ... Not entirely settled how default would work. 02:00:07 yongjun: CENC version 1 and version 3 have different requirements. In the deployment of Prime videos, we noticed problems. 02:00:15 s/an ongoing goal/a requirement/ 02:00:42 ... Version 1 requires 4 bytes, version 3 requires 5 bytes. It's not compatible. 02:00:58 ... Basically, we have two specs under ISO 23001-7:2016. 02:01:13 ... It's nearly impossible to backfill everything in the same implementation. 02:01:21 ... It's always a mix. 02:01:36 jer: Just wondering whether we can mandate a specific version of CENC with the string. 02:01:37 s/[details potential issue with that]/This is a lower level detail than the pattern, but there is a question about whether the 16x bytes to which the pattern is applied is aligned with the start or the end of the OBU. 02:01:58 chcunningham: Can we mandate both? 02:02:04 jer: We could, but won't help Amazon. 02:02:32 yongjun: The recommendation is to support everything. 02:02:45 igarashi has joined #mediawg 02:03:20 Joey_Parrish: We will be developing a polyfill that allows to query the version supported. 02:03:33 jer: Is the idea that you will try and fail to detect the version? 02:04:08 Joey_Parrish: No, apps hardcode what devices support, the polyfill would abstract that in a library 02:05:30 yongjun: It's a mistake in the CENC specification not to have been backward compatible. 02:06:41 niwamoto has joined #mediawg 02:06:44 Joey_Parrish: Rather than making a more specific query to seek the version of CENC, be more specific in the section that details CENC that all sections of CENC must be supported. 02:07:05 s/Joey_Parrish/jer/ 02:07:40 q? 02:07:53 yongjun: We don't have enough time to backfill everything. There's always a mixed catalog on the backend. 02:08:40 GregFreedman: It seems like if 90% of your catalog is CENC 3, it seems strange to be willing to support CENC 1 02:09:26 chcunningham: Was there a line somewhere that version 3 was a good thing to use when it got introduced, because it would be supported by EME? 02:09:34 yongjun: We always move to the latest version. 02:09:59 ... When we onboard new devices, we make sure that they support all versions. 02:10:24 markw: The capability problem is only in one direction there. 02:10:34 ... The newer spec has more bytes in the clear. 02:11:10 ... The older devices should not have an opinion provided that at least the first 4 bytes are encrypted. 02:11:31 ... The problem is that there are newer devices that require fewer bytes in the clear. 02:11:44 ... In practice, that only applies to H.265 streams and not H.264 02:12:01 yongjun: Microsoft Edge is like this, I think. 02:12:07 mounir: I think we are digressing here. 02:12:29 ... Maybe you should file an issue about this. Can you do it? 02:12:35 yongjun: Sure. 02:12:37 soju has joined #mediawg 02:12:56 s/fewer bytes in the clear/more bytes in the clear/ 02:12:57 ... This is super important for Microsoft Edge. 02:13:31 mounir: Is there something in the change that people have concerns about? 02:14:24 Joey_Parrish: For backward compatibility, if the encrypted schemes is not provided by the application, the behavior is mostly unspecified. No restriction. The way we would be able to detect support for the field itself, when the application calls getConfiguration, that should be in the configuration returned for media keys. 02:14:55 ... The idea is that a polyfill could be written to make simple calls to detect support for the field. 02:15:02 mounir: Everyone happy with that? 02:15:11 scottlow: Yes, as an implementer. 02:16:05 PROPOSED RESOLUTION: Joey_Parrish to prepare a PR to integrate encryption scheme proposal in EME (W3C repo) 02:16:29 RESOLUTION: Joey_Parrish to prepare a PR to integrate encryption scheme proposal in EME (W3C repo) 02:16:58 Topic: API to find existing sessions 02:17:18 mounir: My understanding from discussion at FOMS is that we need to get back to the drawing board. Not done yet? 02:17:42 Joey_Parrish: Right. The feedback I get from Jer is that the design was a bit overloaded as I wanted to cover two cases. 02:18:03 ... Example in Widevine, matching base on the content ID. 02:18:16 GregFreedman: I assume this is active session. 02:18:36 Joey_Parrish: Correct, active not expired session. In the case of key rotation, expired sessions would not show up. 02:19:18 ... Main purpose of that is that, as application developer, I don't have a deep understanding of sessions, which may lead to duplicate sessions, which can be an issue with CDN sessions. 02:19:30 jer: Seems reasonable as a future direction. 02:19:38 s/least the first 4 bytes are encrypted/least the first 4 bytes are unencrypted/ 02:20:53 Joey_Parrish: Key IDs are not commonly available on all devices. 02:21:00 GregFreedman: Right. No objection. 02:21:27 Joey_Parrish: Would an API that would give you back key ids instead of sessions be preferrable? I'm open to that. 02:21:50 GregFreedman: I don't feel strongly. It may be preferrable for inspection purpose. 02:22:56 Joey_Parrish: From initialization data to key IDs instead of from initialization data to sessions. I think I went for the latter because I wanted to cover key rotation, but agree based on feedback that it should be kept separate. 02:24:21 ... The only reason to have a session object is [missed]. Other than that, it's not useful. 02:25:15 richard: There's a limited number of sessions that you can have from an hardware perspective. Is there a way to tell the difference between expired sessions and sessions that exceed the number of available sessions? 02:25:35 jer: It seems to me that there is a better way [missed] 02:26:34 GregFreedman: From a diagnostic standpoint, key id would be more useful. I might know that the session is active, but I do like the idea of having the key ID. Whether or not you have an API to check active sessions is less important from my perspective but it's ok. 02:27:13 rrsagent, draft minutes 02:27:13 I have made the request to generate https://www.w3.org/2019/09/18-mediawg-minutes.html cyril 02:27:27 PROPOSED RESOLUTION: Expose an API to expose key ID information from initialization data in order to find existing session 02:28:27 Joey_Parrish: You could use the API to do the mapping. I don't have a WICG repo for this yet, only a personal repo. 02:28:41 tidoust: You don't need to have a WICG repo. 02:29:03 jer: It can be a PR against the W3C repo 02:29:35 yongjun: Format of key ID is different. CDM specific. 02:29:51 jer: Yes, ArrayBuffer in the spec. 02:30:19 markw: The Key ID is a container. 16 byte string 02:30:50 [discussion on key ID format] 02:31:04 yongjun: We should not infuse an additional format here, that's my point. 02:31:19 PROPOSED RESOLUTION: Expose an API to expose key ID information from initialization data in order to find existing session 02:31:29 RESOLUTION: Expose an API to expose key ID information from initialization data in order to find existing sessions 02:31:41 Topic: HDCP detection 02:31:42 chcunningham has joined #mediawg 02:31:45 s/The Key ID is a container/The Key ID format is defined by the container specification (e.g. CENC)/ 02:32:01 https://wicg.github.io/hdcp-detection/ 02:32:29 jer: Content may not be licensed for playback given HDCP support or not. 02:32:57 ... The proposal is to have an API to allow early detection of which HDCP levels are supported. 02:33:06 mounir: Joey_Parrish wrote a spec for that. 02:33:55 GregFreedman has joined #mediawg 02:34:01 Joey_Parrish: It's a mapping on MediaKeys that returns the version of HDCP. Privacy review suggests concern for fingerprinting. Mitigation is that it is user activated as part of MediaKeys. 02:34:55 jer: 9 different versions of HDCP that can be supported. Value depends on the connected display, so danger of exposing more unique info per user. 02:35:28 ... It's already possible to gather that information through trial and error. 02:35:42 km has joined #mediawg 02:35:59 ... And small number of Web sites that can use this since keys need to be got first. 02:36:10 https://github.com/w3ctag/design-reviews/issues/323 <= TAG feedback 02:36:34 markw: Granularity requirement is basically HD, 4D, perhaps to be refined to add a third one. 02:36:42 s/4D/4K 02:37:25 ... Slower time to start playback if you don't have such an early capability detection. 02:38:09 ... User consent is for EME at all. 02:38:45 yongjun: Dynamic detection is needed when user plugs another display. 02:39:18 jer: Two things can happen: unplug a device that supported HDCP requirement, plug a new one that supports HDCP requirement. 02:39:50 ... One solution would be to poll this API to detect changes. 02:40:12 mounir: Media capabilities has this idea of adding a change event on the window object, and you could perhaps use this. 02:40:26 ... I believe Mozilla implemented, do you have any feedback? 02:40:30 jya: I don't know. 02:42:00 chcunningham: CDM that enforces HDCP during the playback. Multiple screens, Widevine policy is I believe to report the lowest protection value when you have a highly-protected display and a low-protected display. 02:42:20 jer: Thing happens, because we receive user reports. 02:42:34 ... We take the same approach. 02:42:57 ... The user doesn't understand that a display that used to work no longer work after plugging another one. 02:43:45 markw: The general problem of reacting to user changes is not one that we see as a priority. We don't object to it, but it's not straightforward to make it a good user experience. 02:44:44 jer: One thing that someone like Brave or privacy-mode might do is to try to return a single value for HDCP support. 02:45:13 ... I would hate to get in a situation where you couldn't implement a privacy mitigation without breaking existing sites. 02:45:28 mounir: Mark, you said we could get down to 2-3 values. 02:45:32 ... Is that possible? 02:46:18 Joey_Parrish: Probably, except it probably depends on the specific contract requirements. Studios may update from 2.2 to 2.3, and this value would need to reflect that. 02:47:02 ... If a browser is faking this value for the benefit of privacy. It's effectively equivalent with fetching the value in advance and the user plugging in a display in between. 02:47:17 ... Any application that cannot handle that is going to break in corner cases in any case. 02:47:28 markw: Right, I wouldn't say it's equivalent. 02:47:50 ... Difference between a corner case and a case that always happen. 02:48:31 jer: The fingerprinting of media capabilities is significantly less for Apple because we run in a short number of hardware. But that's not the case for others. 02:48:54 ... The HDCP policy is different because it can change dynamically and dramatically at any time. 02:49:10 Joey_Parrish: We could add an "unknown" value that would allow not to lie. 02:49:33 jer: Returning "unknown" is already a signal compared to lying. 02:50:19 Joey_Parrish: Having implemented something similar in ShakaPlayer, you must start with SD and ramp up with keys you're going to receive. 02:50:48 ... With lying, tt wouldn't mean that you'd be stuck forever, we'd just do what we're already doing 02:50:56 s/tt wouldn't/it wouldn't 02:52:44 mounir: I assume EME is HTTPS only, only available on top. No reason for cross-origin iframes should use EME. EME is async API by default, so you can have a prompt. This call itself is aync, so you could have a prompt. Technically, everyone can get this information with Widevine, it's just a bit more work. 02:52:52 jer: Not the case for everyone, though 02:53:10 mounir: Right, but fingerprinting is not high risk. 02:54:06 ... I would add in the spec a note to explain what implementations could do if they don't want to increase the fingerprinting surface. 02:54:27 ... And we'd just get back to what we're doing that. 02:55:03 markw: Inform sites that rejecting this API is something that can always happen. 02:56:12 jer: Having the ability to reject this promise is good. Links to Privacy Budget discussion as well. The call may succeed at one time and fail at other times. 02:56:22 ... Language like that would be appropriate. 02:56:44 Joey_Parrish: Adding some language for fingerprinting mitigation is ok. 02:57:21 GregFreedman: Some HDCP versions are unsecure. 2.0 2.1, anything below 1.4, we'll never query for. 02:57:47 chcunningham: The privacy gains by doing the collapses is minimal. 02:58:37 markw: You could bucket those, no problem on our side. 02:58:54 jer: Any normative reference that we could have not to have to update the list? 02:59:04 mounir: We'd need a registry. 03:00:49 [discussion on registries at W3C, possible process updates, etc.] 03:01:32 ACTION: Joey_Parrish to add language to the privacy path 03:02:30 MasayaIk_ has joined #mediawg 03:03:22 rrsagent, draft minutes 03:03:22 I have made the request to generate https://www.w3.org/2019/09/18-mediawg-minutes.html cyril 03:03:31 GregFreedman: On Windows, I was told that the media foundation does not recognize 1.4 and reports 1.0 03:03:32 ACTION: Joey_Parrish to look into reducing the number of HDCP versions we expose to collapse to those actually used 03:03:57 Joey_Parrish: Fine with the action but I will need some guidance on what values are actually necessary 03:04:17 mounir: About the TAG issue, should we come back with a resolution? 03:04:43 jer: If we enact the actions, then I think we can get back to the TAG for a resolution on these issues. 03:04:47 mounir: Right. 03:05:59 [short discussion on maintenance issues] 03:06:42 Joey_Parrish: The two things mentioned earlier are key rotate and my suggest to kill robustness. 03:07:12 markw: There are a bunch of issues on the repo. Some of which may need to be dropped, or acted upon. 03:07:26 jer: Seems a good thing to do in a call. 03:07:52 ... About key rotation, internal clients of EME at Apple had issues with adding new keys. 03:08:07 ... Why generateKeyRequest cannot be used multiple times? 03:08:19 ... There seems to be hardware limitations. 03:08:44 ... We closed that early in the first version for lack of time. 03:08:59 ... I'll just re-raise the issue on GitHub, and we'll cover that later on. 03:09:18 ... About removing robustness, any significant pushback? 03:09:27 [none heard] 03:09:32 ving has joined #mediawg 03:10:22 Joey_Parrish: Issues could reasonably be addressed by introducing things such as .hardware or .software and other properties. 03:10:42 GregFreedman: I know we use robustness in practice, so need time to transition. 03:11:05 Joey_Parrish: Yes, long time starting with intent to deprecate. 03:11:50 mounir: Did you file an issue about that? 03:11:56 Joey_Parrish: Not yet, will do that. 03:12:23 mounir: We want to make sure that we can notify everyone else. 03:12:41 Topic: Low-latency