Meeting minutes
Autoplay Policy Detection Discussion
Issue 26 of Autoplay API: CFC
chrisn: No objections to the CFC
<cpn> https://
Issue 23 of Autoplay API: Preventing sites from proprtyng users on Autoplay
sushanth: Not sure the goal of this proposal; the current proposal would prevent MS from requesting from the user whether the user would like to allow autoplay
sushanth: The existing proposal allows the site to know that autoplay was blocked
sushanth: would like to know more about the proposal
alwu: web developers are struggling with how to detect autoplay
* this proposal is different than the play() promise exposed by the media element
… The current technique web developers use is to play an array of very small videos/images to detect what is available to play
… so the goal of the api is to improve that situation
sushanth: a website that wants to respect autoplay would add an explicit play button
… but the reality today is to trick users into allowing media playback
… So the feedback we get from users is to keep those sites from doing so
alwu: from my understanding, the problem with sites is a bad way of detecting
sushanth: if sites wanted to give the users a choice, they would have already.
frank: it sounds like there's two concerns:
… 1. the UA needs to make a decision about whether to allow autoplay, muted play, or otherwise
… 2. how can websites respond to what the UA is going to do, and how is this different than the existing play() mechanism
jernoble: are you thinking you'd always show a popup, or only for a subset of sites, asking whether to autoplay
… the current implementation of autoplay block is static, and the query would be called on every website
… which would lead to a popup checkbox on each site
… that's a justification for current behaviour
sushanth: what if a browser draws its own UI over the video before the play promise resolves?
… e.g., allow playback to proceed on a double-click
… concern is that this proposal prevents delaying the response
jernoble: frank's question, how should a well-behaved site respond?
… if user has declared it doesn't want autoplaying content with audio, blocks the ability of the page to do the right thing
… suspect this won't be a per-element request, generally "is this page allowed to play"
… that would block all elements on the page
… if a sensitive user agent wanted to implement what you describe, they could report that autoplay is allowed, then block the play promise
sushanth: would there then be W3C tests that would make a browser that did that non-compliant?
jernoble: haven't thought about that, interested in others views on that
… as an implementer, i wouldn't want to be constrained to a specific behaviour through implementing the autoplay API
… i don't think there's any "must" in the spec to say that you must not block play
… share your concerns about blocking novel ways to deal with annoying behaviour
sushanth: maybe this is autoplay behaviour rather than policy, for sites that want to customise UI based on user preference?
jernoble: sounds reasonable to me, could be done through a note in the spec. the response from the API is informative, not binding on what happens when you call play()
frank: I'm behind it not being binding
jernoble: suggest taking back to the issue, get input from others, so we have something site developers are happy with
chrisn: any particular questions for site developers
jernoble: frank's second question, if the answer you get is only informative, is that enough for the experiences you want to create?
sushanth: next issue is exposing more fingerprinting surface
https://
sushanth: querying the API you know the document activation is true, so it exposes the user's preference setting, a unique way of tracking the user
jernoble: is your risk scenario that the UA exposes a single preference for autoplay, or are you interested in per-site settings
sushanth: worried about exposing something about the user. people who are more technically advanced could change the setting
… in either case it maps directly to a setting
alastor: feels more implementation specific. we don't enforce that the result should surface the setting, e.g., browser activation, different result across frames, or other mechanism to block autoplay
… the result and setting can have a relationship, but how much depends on implementation
sushanth: agree that being in a frame you can't read out into the document. not so concerned about that aspect
… in future it may be possible to read that out and then leak information about a user
jernoble: have you thought about what a mitigation might be?
sushanth: the nature of the API seems to expose a preference, so not sure how to have the API without preference
jernoble: IIUC the current behaviour of the play promise is an indirect mapping, it also uses the document interaction status?
sushanth: yes. with the new API it removes the decoding piece
jernoble: from PING point of view, just because there are existing ways to surface information, that doesn't excuse new APIs
… this doesn't seem to be a net increase
… the existing play promise would allow you to detect the same information
… the only mitigation would be to not expose the autoplay policy at all, or always the exact same response
… if you always answer the same thing, user's can't complain what happens, as you're keeping the user's setting a secret
jernoble: from a webkit point of view, you could cc Tess, who's in the PING group, see if she has any mitigation suggestions
frank: mitigation seems difficult, you could wait for a timeupdate and then know. interested in mitigation, sad if there's not a good answer
jernoble: the timeupdate issue, it would make all custom playback controls impossible
… hard job to mitigate privacy concerns in all cases for media
chrisn: are the privacy concerns significant that we shouldn't expose this API?
sushanth: as long as the response can be faked and doesn't expose a user setting we should be fine. concern about being non-compliant
chrisn: alastor, so we could propose text along those lines, and get PING review?
alastor: sure
https://
sushanth: I think we've covered this issue, it's a preference, not required for compliance, so I think we're ok
<MattWolenetz> MSE srcObject topic: https://
MSE srcObject
matt: last September we heard back from the WG and the Mozilla that attaching a srcObject would be preferable to object URL
… have public feedback that they're getting metrics improvements
… for doing the srcObject attachment, some flexibility on how to specify
… to enable MSE in workers, I proposed having a handle object be constructable in a worker context, object is transferable, then can be assigned to the media elemnent srcObject
… would need update the attachment instructions to prevent a MSE objectURL from worker context
… don't want to precluding using a srcObject from a main thread MediaSource
… the idea is generate the handle object where the MediaSource is then transfter to the media element
… alternative is a lot more complex. allowing creation in a worker with transfer would allow this to happen faster
<MattWolenetz> https://
matt: want feedback from you, Jer. Got positive feedback on the Mozilla request for position
… want to make sure I'm not going in the wrong direction without your feedback
jernoble: apologies for not responding. I've come around on createObjectUrl vs srcObject
… should have an explicit object with ref-count that can be transferred across boundaries
… simplest possible implemntation
… the easiest from both UA and client perspective, I think you're on the right track
matt: that's helpful, thank you
… I've heard from origin trial participants, when is this coming, and to other user agents? be good to be able to give some indication
jernoble: issues around making things available off main thread, so it'll be a while to implement
… any other feedback?
chrisn: any input from player libraries such as dashjs?
matt: have input from Shaka player. It's a major change to enable in worker and transfer
… some players already do this, so it makes their work more performant
… i've heard positive feedback, not sure they'll immediately take this in
… support from other UAs would help this feature
Media Capabilities
cconcolato: created a test page for media capabilities: https://
TPAC 2022
chrisn: possible face to face meeting for TPAC 2022
… https://
cpn: WG Chairs have been asked to fill in a survey; about the interest within the WG in meeting F2F, for logistics reasons
… From my own perspective; don't know if travel will be possible. However, there are issues which would be better discussed in person
… If you are able to respond, please give a response on that issue w.r.t. your interest in meeting in person
… Depending on responses we may schedule on a hybrid in-person/virtual meeting, or a virtual one
cyril: I didn't know how to respond because there is no agenda yet; if the question was narrowly about covid-related reasons, I could answer today
cpn: I would say answer based on your ability to travel generally, under the assumption that the agenda would be relevant to you
cyril: Mile high video was great this year
Bernard: there has been some discussion of limiting time for WG meetings to a single hour; having an all day meeting would be a greater motivation
cpn: That's true and I've raised that same point. The question is whether it would be valuable to have face-to-face breakouts and bring those results back to the whole WG.
cpn: If we limit the discussions to only the whole WG, I agree it constrains the usefulness of meeting in person
cpn: please do leave a response on that issue and we'll use that as input to respond to the W3C
WebCodecs Registration CFC
cpn: The CFC for creating a registry for WebCodecs had only a single response, which Is a difficult answer to interpret
… if you feel strongly one way or another, please respond; without it, we'll proceed assuming there is consensus.
Bernard: Are we confirmed that the April meeting will cover Media Capabilities?
cpn: That depends on the availability of chrisc,
Bernard: If we start on a slide deck, that will trigger discussion