Sangwhan: it's a very small thing. On mediakeysession which is an object inside eme there is an attribute called 'closed' and this adds a reason to why it was closed

Dan: what's the user need? In service of need? Is this shown to the user?

Sangwhan: usually to do error handling for the application to reinitialise the eme stack. You would have a couple of errors.. it's an enum, internalerror, closedbyapplication, etc, comes back from the content decryption module. Also resourceevicted. The content decryption module dpeends on hardware for example and ran out of memory and had to release the resources or stuff like that. This would be information usable in terms of the video streaming application knowing what to do next if the decryption failed or if it's closed. This doesn't add more damage.

Dan: I've marked it as small delta..

Sangwhan: there's a tricky bit.. I think EME doesn't have a working group?

Dan: Media Working Group

Yves: yes

Sangwhan: I'm okay with this. Can write a closing comment. I'm not sure if this is an actual attack... the state change can leak information across origins. But there's a bunch of other stuff that could trigger this so I'm not sure if it's a big issue.

Dan: One of the things we kept talkinga bout intially with the EME review was that it can leak information to you because the content decryption module is a black box it can have access to information like your location and that can..

Sangwhan: it is not supposed to but yes

Dan: that lead to the whole discussion about wanting some kind of statement a waiver about security and privacy experts auditing how these systems work and that should be considered an exception, they should not be prosecuted under the digital millenium copyright act, and there ended up not being that covenant, it wasn't part of EME even though TAG recommended that it should, is there something similar to that where this nformation could reveal something about the user across origin, or is thsi purely mechanics?

Dan: Also worth noting our feedback from 2017 on this issue.

Sangwhan: imagine the gamepad API.. some implementations broadcast the input to all tabs because it's an event. In this event you could listen to gamepad input and match up a user by listening to the gamepad events, if a user presses right multiple origins will get that. This is the same kind of mechanism that will happen. Multiple things are using the EME stack and the CDN goes bonkers and everything shuts down for the same reason it could identify the user, I'm not sure if that's a realistic or useful attack surface.

Dan: maybe ask that?

Sangwhan: I don't think it's preventable. It's in 2.1 in S&P - information will be exposed indirectly to some websites. [reads] I don't think it's a huge issue to be honest.

(Setting aside all debate about whether or not EME should exist in the first place, since the cat is out of the box. For that bit, please refer to our [feedback from 2017](https://github.com/w3c/encrypted-media/issues/389).)

Given that this is a small incremental change to an existing spec that improves developer ergonomics, we are happy to see this move forward. Thanks for bringing this to our attention.

Noticed that the EME spec doesn't have a S&P section - think it would be worth adding something there (not just for this feature, but for EME as a whole) if possible.