13:53:09 RRSAgent has joined #mediawg 13:53:09 logging to https://www.w3.org/2021/04/13-mediawg-irc 13:53:14 Zakim has joined #mediawg 13:53:19 RRSAgent, make logs public 13:54:05 jernoble has joined #mediawg 13:54:39 Meeting: Media WG Teleconference 13:54:46 Agenda: https://github.com/w3c/media-wg/blob/main/meetings/2021-04-13-Media_Working_Group_Teleconference-agenda.md 13:59:27 Chcunningham has joined #mediawg 14:00:08 chcunningham_ has joined #mediawg 14:01:40 Chair: Jer 14:02:08 present+ 14:02:12 Present+ Francois_Daoust, Jer_Noble, Chris_Cunningham, Francois_Beaufort, Matt_Wolenetz, Tommy_Steimel, Yoav_Weiss 14:02:34 present+ Mark_Watson 14:03:33 cpn has joined #mediawg 14:04:35 present+ Mounir_Lamouri 14:04:46 present+ Mounir_Lamouri, Greg_Freedman, Peng_Liu 14:05:05 scribenick: cpn 14:05:32 markw has joined #mediawg 14:05:47 pengliu has joined #mediawg 14:05:51 Topic: Web Codecs FPWD 14:06:13 Francois: Web Codecs has been officially migrated to the Media WG, and we've published as FPWD 14:06:23 ... This has triggered a call for exclusion of essential claims 14:06:47 ... Three documents: Web Codecs spec, Registry, and AVC registration 14:07:10 ... They'll become WG notes. If the process includes a better process for registries, we can adopt that 14:07:20 ... Plan is to keep the registration non-normative 14:07:35 ChrisC: Thank you Francois for guiding us through the process 14:07:49 Francois: Next step is to automate publication to /TR 14:08:01 ... Same as we've done with Media Capabilities and other specs 14:08:11 wolenetz has joined #mediawg 14:08:15 ... It needs some updates on the boilerplate, which should be done soon 14:08:17 present+ wolenetz 14:08:41 ChrisC: On registries, we currently only have an entry for AVC codec, but we expect other to be added such as VP9, AV1 14:08:59 Topic: New Media WG Charter 14:09:16 -> https://github.com/w3c/charter-media-wg/issues/16 clarify fingerprinting text; perhaps bring sec/priv text into alignment with template 14:09:16 -> https://github.com/w3c/charter-media-wg/issues/19 How to gatekeep the EME "API to find existing sessions"? 14:09:16 -> https://github.com/w3c/charter-media-wg/issues/20 capability negotiation, big picture 14:09:19 Francois: As part of rechartering, I ran horizontal reviews on the draft charter, per usual process 14:09:35 gregwf has joined #mediawg 14:09:38 ... Three issues were raised. A couple are privacy related against the current draft charter 14:09:53 ... Want to resolve them in a way that satisfies everyone, the WG and the privacy folks 14:10:01 jernoble_ has joined #mediawg 14:10:02 ... The first is #16, clarifying fingerprinting text 14:10:14 https://github.com/w3c/charter-media-wg/pull/22 14:10:20 ... There have been updates to the charter text, PR #22 14:10:37 ... I want to make sure you're ok with that text 14:10:54 ... It's easier to change now than when we run the call for review of the draft charter 14:11:46 ... The privacy folks are worried about the capabilities that the media specs expose, so they'd like to strengthen the wording in the charter, so that mitigation strategies will appear in the specs alongside the privacy issues 14:11:49 ... Any comments? 14:11:52 q? 14:12:08 ChrisC: The text looks good initially, would like to review later this week 14:12:32 Francois: Next is #19, on finding existing sessions in EME. Joey responded, to clarify intent 14:13:05 ... I don't think it affects the draft charter. I can close the loop with Sam on that 14:13:43 ... The last #20 is capability negotiation. I'm trying to understand what the privacy folks want to see in the charter, and in the specs themselves 14:13:56 ... They'd like the group to document architectural alternatives, to achieve the same thing 14:14:28 ... I'm not clear what those could be. There are different granualities per spec. For MC API it could be for each individual capability 14:14:42 ... There's suggested text in the issue. I'd like your feedback 14:15:04 ChrisC: I discussed with Sam the MC API issue that he raised 14:15:27 ... He'd prefer a design where you request N capabilities and the UA reports which one it likes best 14:15:38 ... We mention it in passing in the explainer, could write more 14:16:03 ... This is a late stage privacy review. MC API is widely implemented and used. We should incorporate changes and improvements where we have an opportunity 14:16:17 ... We don't have an opportunity to make a large breaking change at this stage 14:16:41 Francois: Sam would say it can't be too late, as it's going through horizontal review 14:16:49 q+ 14:17:09 ... I'm not surprised we get issues raised from privacy folks, that's to be expected 14:17:33 ... This is why WebRTC have added to MC API, push it to the Media WG 14:17:38 ... So a balance needs to be found 14:17:54 ChrisC: Are we being asked to add sections to the spec itself? 14:18:37 Francois: Not necessarily in the spec. The group has the choice of where to document alternatives, but Sam would like to see alternatives discussed and part of the exchange we have with privacy folks 14:18:44 ... I don't disagree it may be too late 14:19:15 ChrisC: I'm happy to continue talking with him about it, and document the alternative proposals 14:19:53 ... Web Codecs will have an interesting discussion around privacy. It's low level, not clear whether an alternative can be suggested. We'll need to work with Sam to understand how to address on a per spec basis 14:20:43 ... Francois: From a draft charter perspective, what I'm interested in is whether the group is fine to include Sam's suggestion, or propose something else? 14:21:16 ... The goal is to find a suitable solution, so that we don't have issues when we send an official call for review 14:21:16 ack wolenetz 14:21:48 Matt: I agree that documentation of discussion around these points is a good thing to have. There's a history in MSE of doing this in F2F and in GitHub issues 14:22:54 q+ 14:22:56 ... To what extent would this be done in the specs. Formal process for doing this? With respect to the idea of any capability that an app wants the UA to provide, simply having the UA to select a preferred option from a large set ... that form of API could be gamed easily by changing inputs slightly 14:23:19 ack jernoble_ 14:23:55 Jer: One of the fingerprinting mitigation strategies was rate limiting. You could imagine hitting a rate limit quickly for an individual query API like MC. A group based query would allow you to not hit the rate limit so quickly 14:24:14 ... So rate limiting would be more effective in the latter case, and still deal with the ability to change inputs slightly 14:24:34 ... AIUI, we're not being asked to change the design, more document alternatives 14:25:02 Francois: Documenting alternatives helps with making the choice, but here we've already chosen 14:25:24 ... In the MSE case, Sam is looking at new features, not the existing W3C rec 14:25:39 q? 14:26:24 Matt: The first feature, changeType, relates to capability detection, so the documentation needed to accommodate these requests could go with the first draft 14:26:50 ChrisC: I'd like to take a few more days to take a look at the proposed text