Meeting minutes
Web Codecs FPWD
Francois: Web Codecs has been officially migrated to the Media WG, and we've published as FPWD
… This has triggered a call for exclusion of essential claims
… Three documents: Web Codecs spec, Registry, and AVC registration
… They'll become WG notes. If the process includes a better process for registries, we can adopt that
… Plan is to keep the registration non-normative
ChrisC: Thank you Francois for guiding us through the process
Francois: Next step is to automate publication to /TR
… Same as we've done with Media Capabilities and other specs
… It needs some updates on the boilerplate, which should be done soon
ChrisC: On registries, we currently only have an entry for AVC codec, but we expect other to be added such as VP9, AV1
New Media WG Charter
Francois: As part of rechartering, I ran horizontal reviews on the draft charter, per usual process
… Three issues were raised. A couple are privacy related against the current draft charter
… Want to resolve them in a way that satisfies everyone, the WG and the privacy folks
… The first is #16, clarifying fingerprinting text
Issue #16: clarify fingerprinting text; perhaps bring sec/priv text into alignment with template
Francois: There have been updates to the charter text, PR #22
… I want to make sure you're ok with that text
… It's easier to change now than when we run the call for review of the draft charter
… 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
… Any comments?
ChrisC: The text looks good initially, would like to review later this week
Issue #19: How to gatekeep the EME "API to find existing sessions"?
Francois: Next is #19, on finding existing sessions in EME. Joey responded, to clarify intent
… I don't think it affects the draft charter. I can close the loop with Sam on that
capability negotiation, big picture
Francois: 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
… They'd like the group to document architectural alternatives, to achieve the same thing
… I'm not clear what those could be. There are different granualities per spec. For MC API it could be for each individual capability
… There's suggested text in the issue. I'd like your feedback
ChrisC: I discussed with Sam the MC API issue that he raised
… He'd prefer a design where you request N capabilities and the UA reports which one it likes best
… We mention it in passing in the explainer, could write more
… 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
… We don't have an opportunity to make a large breaking change at this stage
Francois: Sam would say it can't be too late, as it's going through horizontal review
… I'm not surprised we get issues raised from privacy folks, that's to be expected
… This is why WebRTC have added to MC API, push it to the Media WG
… So a balance needs to be found
ChrisC: Are we being asked to add sections to the spec itself?
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
… I don't disagree it may be too late
ChrisC: I'm happy to continue talking with him about it, and document the alternative proposals
… 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
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?
… The goal is to find a suitable solution, so that we don't have issues when we send an official call for review
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
… 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
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
… So rate limiting would be more effective in the latter case, and still deal with the ability to change inputs slightly
… AIUI, we're not being asked to change the design, more document alternatives
Francois: Documenting alternatives helps with making the choice, but here we've already chosen
… In the MSE case, Sam is looking at new features, not the existing W3C rec
Matt: The first feature, changeType, relates to capability detection, so the documentation needed to accommodate these requests could go with the first draft
ChrisC: I'd like to take a few more days to take a look at the proposed text
Default repo branch naming
Rename default branch repos to "main"
Francois: We're progressively migrating all our specs to use main instead of master as default branch name
… This affects some of our repos
… It's a small thing to help improve diversity and respect
… I'll implement the branch name change over time. It normally doesn't break much, you'll have to change the default branch name locally
Jer: That sounds straightforward
ChrisC: The change went smoothly for Web Codecs. The only gotcha was needing to update the Makefile, for Travis to publish from the branch
Francois: One thing that breaks is GitHub Pages, you have to disable then re-enable before it fixes itself
New actions in Media Session
Tommy: Our concern is that for browsers that haven't implemented the new actions, we throw an exception. This requires a try/catch block around the action handler
… It relates to use of an enum in the parameter. How to make it better for developers? Add an isActionValid() that returns a yes or no. Open to ideas
Jer: Sounds fimiliar from another spec, where adding to an enum caused exceptions. Solution was to use DOMString while also using enum in the spec
… We'll see if we can dig up the exact issue
Mounir: We couldn't use a string in the EME case. You get a promise if the request succeded
Jer: Might need to change the API to return something, rather than throw an exception
Yoav: The fact the API throws on unknown input seems not future compatible. If developers don't try/catch those calls, their code will break
… The ideal would be to add a feature detection mechanism so developers know the supported action ahead of time
… Change the API to not throw on unknown values and return a value to indicate action not taken
… Is this something other APIs are doing?
Matt: What is the expected variety of action types? Could they be independently named items on the object that could be detected?
… For the microphone and camera use cases, if there are multiple how would Media Session know which one?
Jer: For the latter question, Media Session is a simplification - goal is to give a single playback session. While it's possible to have multiple sessions, the UA wouldn't necessarily want to expose that
… Potential future API surface is to choose the camera or microphone. But we'll have the same problem of exceptions being thrown. Without some change it's hard to know if the action is accepted
… If we want to remove exceptions we'd want an alternative to know what's supported
Tommy: That clarifies things for me
Yoav: In terms of shipping the current new actions, ideally we'd decouple feature detection from shipping new actions
… What's the breakage risk of shipping with the current API shape?
Jer: Seems riskier to remove an action. That would break existing sites. The only break would be new sites, tested in a single browser, UAs not yet implementing would find those sites don't work any more
Mounir: IMO, that's bigger than previous actions we added (stop, skip, etc). I'd expect sites to check for presence of those methods
… Following Yoav's feedback, I looked at pages using the API. 50/50 split on use of try/catch around setActionHandler()
… Everyone who is launching Media Session today has all actions implemented, so not the best metric
… Jer, if Chrome were to ship this, would you be concerned about potential impact?
Jer: I believe Safari has experimental implementation. That realises the risk here
Mounir: I don't know the difference in risk
… If adding an action becomes a no-op, it would break the experience
Jer: If a developer could tell if an action was unsupported, what would they do instead?
Mounir: In the case of the new mute camera and mute microphone actions, we'd expect them to not use the features
… In Chrome, there'll be UI in PiP. Developers are used to use PiP for communication use cases, but want the ability to mute/unmute from PiP
… A site could refuse to use PiP if they don't have ability to mute/unmute
Matt: Would such an application, doing PiP integration , should there be a way to pro-actively detect instead of using exceptions?
Mounir: Not sure of the difference
Jer: I dont' think anyone's arguing not to have feature detection. Raise an issue on how to do feature detection without throwing exceptions
… The Media Session API isn't a guarantee about where the UI will appear, so I worry about introducing a contract we can't full
… Mounir, can we follow up offline?
Publishing FPWDs
Francois: We have other documents not yet published. People may be concerned that nothing happened, so why are they still in the charter?
Matt: For MSE, I definitely want to get canChangeType in from WICG. We have editors. What are the next steps? It's already shipped
Francois: There needs to be group resolution to publish
Matt: Should I just ask you, Francois, to start the CfC once I have upstreamed the text?
Francois: Yes, good plan
MarkW: If you need any help, please let me know
Matt: I'll look at it this week
FrancoisB: I noticed Webkit experimenting with a Media Session coordinator API, anything to share?
Jer: Not yet, but it will become clear when we do
Matt: Chrome implementation of MSE in Workers is stabilizing, expect to begin origin trials soon. Invite people to look at the feature, send comments to the spec issue, sooner than later
… Issue #175 in MSE repo
Jer: Anything else?
[none]
Jer: Look forward to seeing you at the next meeting
[adjourned]