Meeting minutes
EME
Issue 583: Clarify definition and intent of "replacement algorithm" in update()
Xiaohan: There are two notes mentioning the replacement algorithm, but it's not defined anywhere in the spec
… It was possibly in early versions of EME. The context is, when update is called with a new key and the storage is at capacity, there's an eviction algorithm to replace the old with the new key
… Two issues. The replacement algorithm is unclear and undefined. But I do see a use case for eviction of older keys, either because we can't store that many keys, or we don't want the number of keys to keep growing without limitation
… We're talking about key rotation, and this can happen quickly, so we could accumulate a lot of keys in one session
… So I think a properly defined eviction behaviour would be my suggestion
… Any thoughts?
Marcos: Sounds good
Xiaohan: I can volunteer to send an update to see how it looks
Chris: Thank you
Issue 585: setMediaKeys() modifies observable state and internal flags "in parallel"
Xiaohan: setMediaKeys has many steps, run in parallel. In those, we manipulate the mediaKeys attribute, etc. My understanding is those are supposed to not happen on the main loop
… Typical spec language is to queue a task
Chris: Issue 562 points to a number of other places in the spec that might be affected
Xiaohan: Those are about resolving or rejecting promises
Marcos: You have to resolve it in a task, so need to queue a task
… I haven't had a chance to look through the code, but we should identify where the steps need to be moved out via RPC or lambda, for example
… Generally, if you look at WebIDL, you have promise resolvers and rejecters. At some point, you do main thread checks, then go "in parallel" (which means going to another thread). Then you need to re-queue to the main thread, as JavaScript runs single threaded
… Use the task queues, to resolve or reject the promise with a value
… EME is an older spec, so may have missed this
Chris: So we'll need to address these, starting with setMediaKeys, I suggest, then review the others in 562
Francois: Issue 562 focuses on promises, because those are the easy things for the bot to check, but really it's an invitation to review the algorithm
Marcos: We can't do the updates often as we have lots of other PRs, but now we only have one, so we could run a script. I have the infrastructure to do that
Xiaohan: Do you mean just setMediaKeys, or all of them?
Marcos: I'd need to check. My tooling analyses the browser code bases and compares whether the spec matches the implementation, and vice versa, and checks WPT
Chris: Do we have a task source?
Marcos: It should be the media element's
Chris: OK, so no need to create a new one
Marcos: It might be observable, but I'll have a look at which queue it runs on
Chris: The EME spec doesn't say which task source to use, so we'd need to set that
Xiaohan: In theory we can create the media keys without attaching to a media element. Does that affect this?
Marcos: Good point. Does anyone want to take this on? I can provide input
Xiaohan: I can work on that
Marcos: I can do an automated clean up
Chris: Thanks Marcos
Issue 558: Horizontal review status
Chris: Thanks Joey, we've got the security and privacy questionnaire done. Question in my mind is whether to request horizontal review from those groups
… Maybe we should do the in-parallel changes first, then maybe review the Notes for normative language, those may trip up the reviewers
Marcos: I have tooling we can to review
Joey: I can do a first pass too.
Chris: I think what's happening is we have different conformance classes: the UA, the CDM, the license key server, and some of those normative statements might apply to those
Marcos: I've done similar in Digital Credentials API
… tooling to review PRs
Chris: Happy to schedule a working session. Marcos and I meet on a Thursday
Chris: Let's do that once we have progress on the "in parallel" algorithm steps
Issue 570: Note loosening impl requirements is out of scope in SOTD
Chris: I added this to the agenda as there was a question raised on the actual concerns.
… This came during charter review.
… There was a comment from reviewers worried about loosening success criteria, around testing. Language had been dropped to follow the latest charter template.
… I don't think that there was any intent on our part to do anything differently.
… The intent is to make things as interoperable as possible.
Francois: The update was more to address another commenter, where there's a member-only discussion
… The general concern is that EME achieves a delicate balance, so whenever the group adds a new feature, there's a worry this balance might change
… and it might create new barriers to accessing media content
… The goal was to be clear that when we make changes, we document how it affects that balance
… And we're not trying to loosen any requirements in the existing Recommendation
… TAG also raised a comment in charter review along similar lines
TAG review on Media WG charter
Chris: This is being addressed, for example through the questionnaires that we're going through.
… And this will go back to the Privacy group for review.
Joey: If there are no actual objections, it's fine to approve the PR.
Xiaohan: Wondering about the possibility to discuss features that are not listed in the Charter.
Chris: Yes, we're really scoped by the Charter on Encrypted Media Extensions.
… The features we're considering are not significantly broadening the scope of how EME applies to content on the web in general.
… I'm not sure that adding this text is enough. I think we'll have these questions when we go through horizontal reviews.
… I think this issue should be addressed through chartering process.
Alicia: Not very happy with the change. I was getting the opposite impression, and that it could backfire. The way it's written, it suggests that there is going to be loosening of implementation requirements.
… May need to rephrase in a more positive sense.
Francois: It's not addressed at the charter level, as that takes a lot of time, as it's easier to add to the spec
Chris: Perhaps next step is for François and I to see how to adjust the language, and close the loop with Nick.
Chris: Very pleased to see the recent activity on the spec, thank you for the work!