Privacy, Spec should call out that the API discloses user settings that is a fingerprinting vector.

[sushraja-msft]

From https://www.w3.org/TR/security-privacy-questionnaire/#purpose

Does your feature expose information to origins? If so, how does exposing this information serve user needs? Are the risks to the user outweighed by the benefits to the user? If so, how?

With this API, we are exposing user preference that was set in the browser settings. This can contribute to fingerprinting. Is the risk outweighed by the benefits is something we should determine but the risk needs to be called out.

[alastor0325]

This is a great question. As we know, every user-agent has different ways to handle blocking autoplay. Allowing autoplay on foo.com doesn't mean that user explicitly set foo.com in their user setting. It could be

• a user-agent uses the user-gesture activation and a user clicks on foo.com
• a user-agent uses the user-gesture activation and will propagate the allow permission to all its child frames, then a user clicks on bar.com and foo.com is a child frame embedded inside bar.com
• a user-agent uses a special way (eg. chrome's media engagament index) which indicates media on foo.com would be allowed to autoplay
• a user explictly allow foo.com to autoplay by adding it to a user-agent specific setting list
• a user explicitly disallow foo.com to autoplay. But a user performs a supported behavior on the page (eg. user gesture activation, or click on certain media element) which allows foo.com to be allowed to autoplay.

There might still be more different situations depending on a user-agent's implementation. Considering so many different situations can happen on one result, I think it's very low risk that this API can be used for fingerprinting.

[alastor0325]

For the reference, MediaWG had discussed this issue on March last year.

In short, this API doesn't expose any new information to the web. It's just simplify how web developers can query the result without using different kind of workarounds. All the information they can know via the new API will be equal to what they can know now, which is performed by observing the media element's events and statues (eg. playing, timeupdate).

In addition, here is the privacy review I requested in case anyone is interested in.

[alastor0325]

In the MediaWG minutes I posted above, the conclusion is that there is no major concern about privacy for this API, because web developers can use current existing media element API to get the same result. It's also hard to mitigate privacy concerns in all cases for media for the current existing API.

Therefore, I'm going to mark this issue as closed.