Sangwhan: still pending external feedback. At f2f we requested clarification whether it's only accessible from top level frame and have not heard back.

Dan: pinging?

Peter: we have pinging

Lukasz: wondering whether there is a risk of ... not limited to web browsers .. is it limited to the browser or ... operating systems. OS have lock screens.

Sangwhan: it does - if you grant this permission to multiple origins then you can use it for cross origin tracking - if the user goes idle on multiple origins at the samne time you could use it for tracking

Lukasz: usage patterns - conjunction with other APIs e.g. sensors

Alex: this is expressed as a permission - where browsers can decide what policy to apply - fuzziness is available. if the origins are currently running are collaborating with eachother in the same browser process they could build a wormhold scripting relationship in some browsers. e.g. iframe -> relationship -> different window (e.g. through serviceworker). Question here about what else is being exposed and how it's exposed to users is important.

Kanneth: would it idle immediately if the screen turns off?

Sangwhan: OS dependentent?

Lukasz: or use the keyboard or mouse for 1ms - is it idle.

Alex: it's user agent defined.

Lukasz: so different for each UA.

Alex: potentially different for each UA and for each OS - in some it's most approriate to use screen lock as a signal of idleness.

Lukasz: a link betwen browser and OS

Kenneth: browser knows that if there are 5 sites open looking for idle it doesn't have to tell them at the same time.

Alex: we should look at this and make sure that idleness is only being delivered to top level documents, only in secure contexts and documents withough visibility are not having the event delivered.

Kenneth: but if I have an app running int he background i may want people to know I am idle...

Alex: what is the visibility state of tab?

Kenneth: often not visible - not opened -

Alex: there's a question for the services if visibility is strong enough correlation with idleness

Sangwhan: I think it's 2 different flags.

Dan: ... tabs ... I' have notifications in another tab but should people there see me as idle

Kenneth: lot of people want to know if you're available. if you're in a meeting - that's a kind of idling - it's more like "im busy" - whether you're going ot answer an IM or not.

Peter: an "active idle" like a do not disturb or "distracted"

Lukasz: how should this work in private browsing modes and should user be able to disable it. Let's say slack asks for permission to use "idle"...

Alex: question we're being asked - if web platform exposes this, does it expose what develoeprs would need and does it fit with the rest of the platform.

Peter: looks like this is modeled on mution observer / interaction observer. is that right? .. you can pass in a theshold

Lukasz: what's the granularity of updates....

Alice: mutution observers vs. events trade-off: we suggest observers vs events. How would someone know when to use which.

Alex: observers tend ot be about the rate you're going to fire things. it's a good way to do complex configuration. Multiple parties to take a different view of the event stream. for lf stuff an observer is probably not great - event tends to be cleaner and easier. visibility state event vs intersection observers.

Peter: bunch of feedback - can someone(s) summarize?

Alex: i can summarize pieces I recall

Kenneth: I can do some

Carriage of Web Resource in ISOBMFF

Sangwhan: we need to set up a call with David.

Triage of unassigned issues

https://github.com/w3ctag/design-reviews/issues/341 - feature policy evolution - sangwhan

https://github.com/w3ctag/design-reviews/issues/342 - first party sets - david & dan

https://github.com/w3ctag/design-reviews/issues/343 - Verifiable Credentials Data Model 1.0 - hadley

https://github.com/w3ctag/design-reviews/issues/344 - Web Publications - dan

https://github.com/w3ctag/design-reviews/issues/345 - Audio books - david

alice: I took myself off because it seemed like there were enough people on it. Was a good discussion on there already.

sangwhan: My main concern has been addressed... Ken added a bunch of feedback, I haven't read that yet.

sounds of reading

sangwhan: This is about events vs. observers. That hasn't been resolved yet. This is still waiting on external feedback.

torgo: Should we bump this a week or two to wait for feedback? Ken may also not be able to make next week's call, so let's bump two weeks.

Kenneth: We gave a lot of feedback - events or observers - they are implementing the idea we raised. They still have some design questions. Not sure if we should close for now... wait for them to close back.

Sangwhan: i think we should remove the milestone and put it to pending extenral feedback.

Dan: suggest we put it to the f2f.

Sangwhan: i couldn't figure out whether it was supposed to be an observer or an event.

Further discussion on design principles to happen here

Hadley: relationship with generic sensor API?

Ken: this is very low frequency unlike generic sensor API.

Ken: We were OK with this last time we looked - now there is specificaiton.

Dan: is it part of DAS? Seems related to DAS.

Hadley: checking new charter.. it's not there.

Dan: So what is the trajectory for this work? Where does it go after WICG?

Dan: asking

Dan: so basically we need to take a deeper dive into this spec now that there is a spec.

Ken: I gave feedback in the first review - they seem to have implemented it.

Sangwhan: it's not as scary as you might think - but a question of usefulness. I can think of one use case -

Ken: they want it for the chat apps. That's a pretty compelling one.

Sangwhan: it's not the end of the world without it.

Yves: they want indication of are people looking at ads or not. It could be used for that as well.

Sangwhan: you could use intersection observer for that...

Yves: if you are on your mobile and there is a popup app and you drop your phone waiting for it to start then you will be "idle" so I think it would be used for that.

Dan: I think that's a privacy issue.

Sangwhan: as for the spec at hand I haven't looked at it yet - the updated one.

Dan: I can review for privacy

[bumped 2 weeks]

Ken: Only big difference is they adopted my API suggestions and added an idle detection permission.

Sangwhan: We discussed this earlier...

Dan: So they respoded to all your feedback...

Ken: Yes, looks like they took it all on and made all the changes we asked for.

Dan: Last comment from Reilly was in response to my question about venue/destination. Intended venue beyond WICG. "We don't have a particular destination in mind" as of Nov. 10.

... Could leave a closing comment saying we're happy you've addressed our feedback, and suggest a venue...

Ken: Seems like WebApps.

Sangwhan: I can leave that feedback.

Dan: Propose close, we can officially close it in plenary.