15:11:18 <RRSAgent> RRSAgent has joined #webrtc
15:11:18 <RRSAgent> logging to https://www.w3.org/2020/09/15-webrtc-irc
15:11:23 <dom> Present: Bernard, Harald, Florent, Henrik, Guido, Youenn, Palak, Carine, Dom, Jianjun_Zhu, Riju, Francois_Beaufort, Eero_Hakkuinen
15:11:26 <dom> Chair: Harald, Bernard
15:11:38 <dom> Topic: ISSUE 47 RTP Header Extension Encryption
15:11:52 <dom> ... RTP data gets encrypted, but not headers in current implementations
15:12:26 <dom> ... encrypting headers has an RFC, but it is not correctly implemented, due to its high complexity and big impact on SDP bloat
15:12:51 <dom> ... this was discussed recently in AVTCore where the topic is handled
15:13:05 <dom> ... The WebRTC WG needs to consider an API to enable encrypting RTP headers
15:13:13 <dom> ... The proposal is a all-or-nothing switch in the API
15:13:20 <dom> ... either encrypt everything or nothing
15:13:33 <dom> ... The SDP representation will be defined in AVTCore
15:13:55 <dom> ... from an API perspective, we would add an rtpHeaderEncpryptionPolicy field to RTCConfiguration
15:13:57 <Patrick> Patrick has joined #webrtc
15:14:17 <dom> ... the backwards compat option is "negotiate" (fallback to unecnrypted)
15:14:34 <dom> ... and a new option "require" which throws if encryption is not possible
15:14:41 <Orphis> Orphis has joined #webrtc
15:14:49 <dom> ... there would also be a flag on Transceiver to indicate if encryption has happened
15:15:30 <dom> ... My proposal is that by default, "negotiate" is picked (for backwards compat) - later we could consider movign to "require" once there is broad adoption
15:15:41 <dom> s/... RTP data gets/Henrik: RTP data gets/
15:16:02 <dom> ... There was discussion of adding this on a transceiver-basis, but we thought we should keep it simple
15:16:15 <dom> Bernard: in particular, separate encryption can't be done when BUNDLing
15:16:36 <dom> Youenn: could we ask AVTCore of a negotiation per session rather than per m-line?
15:16:50 <dom> Bernard: our proposal would work either way
15:17:00 <dom> Present+ Patrick_Rockhill
15:17:42 <dom> Henrik: the AVTCore discussion may lead the flag to move from the transceiver up to the PeerConnection
15:18:00 <dom> Youenn: I like the config option and the rollout option
15:18:16 <dom> .. I'm skeptical at the transceiver flag if what we want is the whole thing to be encrypted
15:18:54 <dom> Henrik: with the negotiate policy, you may end up with one m-section having encrypted headers and others not
15:19:09 <dom> ... we could fail in that situation though
15:19:26 <dom> Harald: the encrypted negotiated flag belongs on the DTLS transport
15:20:01 <dom> RESOLVED: Add new option to RTCConfig, and add the flag to either PC or DTLSTransport based on AVTCore results
15:20:17 <dom> Bernard: AVTCore meeting is coming up - someone should volunteer a proposal
15:20:20 <dom> Topic: Media Capture
15:20:25 <dom> Subtopic: Issue 646
15:20:50 <dom> Youenn: we had a number of privacy discussions with the Privacy IG which we should try to drive to conclusion ahead of our meeting with them next month
15:21:01 <dom> ... Issue 646 is about making enumerateDevices return an empty list by default
15:21:19 <dom> ... the current behavior exposes 2 bits of info: whether there is at least a camera, and whether there is at least a microphone
15:21:28 <dom> ... after gUM resolves, we expose more info
15:22:03 <dom> ... the typical use cases to expose these 2 bits of info is to enable a Web app to provide a gUM UI only when it has supporting devices
15:22:22 <dom> ... we ran an experiment with returning an empty list, and it turned out not Web compatible
15:23:05 <jianjunz> jianjunz has joined #webrtc
15:23:19 <dom> ... The proposal is to keep current approach and allow UA to fake presence of devices to UAs who would want to remove fingerprinting
15:24:56 <dom> PROPOSED: behavior of enumrateDevices() doesn't change; the WG will consider adding non-normative guidance on fingerprinting
15:24:59 <dom> Henrik: I support this
15:25:01 <dom> Dom: +1
15:25:23 <dom> Henrik: the problem would go away with the new device picker approach
15:25:40 <dom> Youenn: not necessarily you might still want to make the picker trigger optional i nthe UI
15:25:46 <dom> RESOLVED: behavior of enumrateDevices() doesn't change; the WG will consider adding non-normative guidance on fingerprinting
15:25:52 <dom> Subtopic: Issue 640
15:26:14 <dom> Youenn: PING suggested we reveal only label on devices users have granted permissions to
15:26:37 <dom> ... the reason for exposing all labels is to allow for in-page picker
15:27:04 <dom> ... The proposal would be to keep the current consensus with guidance on sanitizing labels
15:27:27 <dom> ... For instance, Firefox & Safari sanitize the name of airpods (which often contains personally identifiable information)
15:28:07 <dom> ... we already have some indirection between labels and what gets shown to JS, we could go a bit further
15:28:10 <dom> Henrik: +1
15:28:27 <dom> ... I don't think we can remove labels as long as Web pages have to build their own pickers
15:28:50 <dom> ... once an in-chrome pickers become the new way, we can reconsider, but that seems a long way in the future
15:28:50 <dom> Bernard: +1
15:29:19 <dom> Henrik: it is true that it can be used for fingerprinting, but that's in a context where the app may already be able to see my face, so maybe not such a big deal comparatively
15:29:24 <dom> Youenn: there are counter examples
15:29:57 <dom> Harald: I don't find that argument compelling enough for a change
15:30:39 <dom> Henrik: a UA could also pick to expose only a subset of devices
15:31:11 <dom> RESOLVED: Keep exposing all devices past gUM resolution with some possible anti-fp guidance
15:31:16 <dom> Subtopic: Issue 645
15:31:42 <dom> Youenn: enumerateDevices expose all type of devices, even if the user has only allowed one type of device (e.g. only mics)
15:32:23 <dom> ... this could be reduced on a per device-type (e.g. gum(video=true) would only expose cameras)
15:32:36 <dom> ... possibly exposing associated mics (based on groupId)
15:32:50 <dom> ... I'm not fond of the additional complexity
15:33:24 <dom> Guido: Chrome only exposes cameras when only video is requested
15:34:10 <dom> ... it has been that way for a long time
15:34:37 <dom> Henrik: this shows this is Web compatible :)
15:35:10 <dom> Youenn: I think if we go that way, we should expose associated mics
15:35:37 <dom> Henrik: this may be confusing though - it may creates the impression that only one mic exists in that case (because you would believe you have all the info
15:35:41 <dom> Youenn: true
15:36:53 <dom> Dom: is Chrome's behavior allowed in the spec?
15:37:29 <dom> Youenn: no, it's only a global boolean that controls enumerateDevices() exposure
15:37:38 <dom> Dom: so something needs to change no matter what
15:37:52 <dom> Harald: where do we stand on the WebDriver spec for gum?
15:37:58 <dom> Youenn: waiting for adoption by the WG I believe
15:38:37 <dom> Dom: so how do we move forward?
15:38:49 <dom> Youenn: I'm happy to align with Chrome in our impl
15:39:57 <dom> ... my proposal on groupId was to align with how we deal with audiooutput where we expose a speaker once the mic is listed
15:40:59 <dom> RESOLVED: Adopt per-device type of enumerateDevice label exposure; follow up on current implementation status for possible extension based on groupId
15:41:02 <dom> RRSAgent, draft minutes v2
15:41:02 <RRSAgent> I have made the request to generate https://www.w3.org/2020/09/15-webrtc-minutes.html dom
15:41:10 <dom> Topic: Media Capture Image
15:41:16 <dom> Subtopic: Issue 243
15:41:31 <dom> Youenn: lot of discussions around Pan/Tilt/Zoom (PTZ) and how it is represented via constraints
15:42:12 <dom> ... when you install an app, you get granted permissions to access e.g. cam + mic
15:42:27 <dom> ... the only choice the user has is "install" or "not install"
15:42:55 <dom> ... another approach is to leave granular choice to the user with a base permission plus additional permissions
15:43:26 <dom> ... PTZ seems to fit better that model - default to "camera" permission, and allow upgrades to PTZ permissions
15:44:42 <dom> ... Taking getDisplayMedia as an example: you ask gDM(video: true) only allows sharing a video; if you add audio: true, it adds a "share audio" UI - but this remains the user's choice
15:44:52 <dom> ... [slide 17]
15:45:58 <dom> ... there is no discussion to allow failure on not providing audio
15:46:04 <dom> ... the same should work well for PTZ
15:46:07 <dom> ... [slide 18]
15:46:19 <dom> ... this has a big impact on how constraints would work for this in gUM
15:46:40 <dom> ... e.g. what happens with gum({video {pan: {exact: 10}})
15:47:15 <dom> ... if there is no PTZ device, this would reject with OverConstrained - this means increased a small fingerprinting increase
15:47:39 <dom> ... it's a known issue with gUM - while can't easily fix it, I hope we don't increase the scope as we would with PTZ
15:48:18 <dom> ... if the user has a PTZ, but doesn't pick it - should this still be OverConstrained?
15:48:43 <dom> ... it sounds like applying the getDisplayMedia model without requiring PTZ would work better
15:48:59 <dom> ... if so, that means skipping all PTZ-required constraints in gUM
15:49:16 <dom> Henrik: isn't the information exposed in any case in getSettings?
15:49:39 <dom> Youenn: there are discussions in sanitizing getSettings based on what permissions have been granted - we'll come back to this later
15:49:43 <dom> ... [slide 19]
15:50:07 <geheimnis`> geheimnis` has joined #webrtc
15:50:23 <dom> ... if the user has the option to grant PTZ access, but the UA doesn't have a device picker - in that case, the UA should prioritize picking a PTZ camera
15:50:38 <dom> ... the UA may have to fallback on a non-PTZ device in case of hardware error
15:51:56 <dom> ... the current spec doesn't give lower priority (via fitness distance) to PTZ constraints
15:52:21 <dom> ... my proposal is to ensure the PTZ cameras get picked when permission is granted
15:52:55 <dom> ... The result would be to add a ptz MediaConstraint (in addition to "video", "audio")
15:53:23 <dom> ... and uses that as a trigger to prioritizing ptz devices - and request permission only if there is such a device
15:53:47 <dom> ... pan, tilt and zoom would still be used as constraints for applyConstraints, but would be skipped in gUM
15:54:04 <dom> ... [slide 21]
15:55:43 <dom> ... This approach means no additional fingerprinting, allows PTZ position sanitization, it limits the complexity, is compatible with the future device-picker approach
15:55:53 <dom> ... it's very different from the current spec, but solves real issues
15:57:47 <dom> Henrik: couldn't we throw on attempting to set required constraints on PTZ? would only allow "ideal"?
15:58:05 <dom> Youenn: we could do that; I think ptz: true is simpler though
15:59:08 <dom> Riju:  [slide 24] we have an alternate proposal we submitted as a pull request, based on Jan-Ivar's input
16:00:01 <dom> Eero: the idea of the proposal is to align PTZ with other constraints in {video} with just boolean values rather than numeric values
16:01:52 <dom> Youenn: how would this work with UAs that have a different prompt from Chrome?
16:02:17 <dom> ... also, doesn't fix the issue with PTZ permission granted while the browser not picking a PTZ device
16:02:56 <dom> Henrik: I like the model of leaving choices to the user, but within the current model of gUM where the Web app makes the choice
16:03:33 <dom> ... what's the prompt that you envision? how would the UA asks about PTZ device in a way the user would understand?
16:04:09 <dom> Youenn: the UA could be to allow it only for advanced users, or only to sites with persistent camera access
16:04:50 <dom> ... if the user may have challenges understanding camera + PTZ prompt ("use and move a camera") vs camera without PTZ (just "use a camera")
16:05:03 <dom> ... it's likely that users will make mistakes
16:05:28 <dom> Henrik: what's the risk of granting PTZ permission?
16:06:05 <dom> Youenn: with PTZ, the preview of what you grant access to is different from what may be exposed over time
16:06:11 <dom> ... without the user being aware
16:06:25 <dom> Riju: note that PTZ is restricted to top level browsing context
16:06:42 <dom> Youenn: right, but there is no requirement to show the self-view over time
16:06:57 <dom> ... that's why PTZ needs a different privilege level
16:07:22 <dom> ... initially the plan was to keep it in the same permission, but we received feedback this needed a different permission which indeed makes sense
16:07:31 <dom> ... that makes it harder to re-use the usual gUM constraints model
16:08:15 <dom> Riju: one limitation is that PTZ is only limited to video - PTZ permission supersedes the simple camera permission
16:08:58 <dom> Youenn: I'm not saying the Chrome model is bad, but my suggestions is trying to make it future-proof and aligned with the changes we're considering for gUM
16:09:17 <dom> Francois: we're talking about the spec - the UA can show a notification when the camera moves
16:09:52 <dom> Henrik: but the notification only deals with cases when the user is paying attention to the browser - the risks exist also when the user isn't around
16:10:02 <dom> Francois: why did you pick this additional ptz boolean?
16:10:20 <dom> Youenn: it's modeled after the getDisplayMedia approach to audio
16:10:42 <dom> ... the idea is that it allows the user to opt-in to an additional privilege
16:10:49 <dom> ... it's beyond a constraint
16:10:59 <dom> Harald: to me, PTZ feels very much like a constraint
16:11:22 <dom> ... moving away from the original model makes it harder to understand the overall model
16:11:40 <dom> Henrik: yet, choosing a device feels pretty different from moving a camera - feels like different APIs
16:11:52 <dom> Youenn: they're exposed at different APIs (gUM vs applyConstraints)
16:12:44 <dom> Harald: I'm hesitant to add special rules and syntax
16:13:33 <dom> Dom: but how would we deal with the different permission level? constraints weren't built to deal with that
16:14:37 <dom> Youenn: as an implementor, I would want to show a different notification to the user before PTZ can be used
16:15:33 <dom> Youenn: my main point is that PTZ constraints should not be required
16:15:40 <dom> Henrik: I like that
16:16:09 <dom> Youenn: I don't care very strongly about the syntax / model, as long as we keep in mind the issues I mentioned on allowing UA flexibility, fingerprinting, non-required PTZ constraints
16:16:22 <dom> Guido: we could treat them all as "ideal" rather than "exact"
16:16:26 <dom> Youenn: +1
16:17:09 <dom> Henrik: I think disregarding the required aspects for PTZ would be enough to get us what we want
16:17:29 <dom> ... could we throw on required constraints for PTZ?
16:17:40 <dom> Youenn: is there consensus on not having required constraints on PTZ?
16:17:57 <dom> Harald: I'm not happy about special-casing
16:19:05 <dom> ... I like throwing Overconstrained when the dev ask for required PTZ
16:19:29 <dom> RESOLVED: throw Overconstrainted on requried values for PTZ and deal with sorting devices separately
16:21:29 <dom> Guido: we need to understand the intersection with advanced constraints
16:23:29 <dom> Subtopic: Issue 245
16:23:38 <dom> Youenn: a page can use a PTZ device with or without PTZ permission
16:23:53 <dom> ... if PTZ is granted, we should expose everything
16:24:25 <dom> ... if not, we should expose that a device has PTZ capabilities, but without detailed information (min/max, dynamic values)
16:25:23 <dom> Francois: this increases the fingerprinting
16:25:31 <dom> Youenn: but only after gUM permission has been granted
16:25:47 <dom> ... I think it's fine to expose some at that point
16:26:16 <dom> Carine: what's the use case?
16:26:40 <dom> Youenn: it gives the opportunity to the Web page to detect the availability of a PTZ device to expose a new PTZ-based feature
16:27:07 <dom> Henrik: fine with it
16:27:22 <dom> Dom: we should flag this for PING check given fingerprinting impact
16:28:08 <dom> RESOLVE: Sanitize PTZ capabilities/setting based on PTZ (the UA may expose additional PTZ info without PTZ permission) - subject to PING review
16:30:00 <dom> Carine: can PTZ be deactivated (like mute on mic)?
16:30:21 <dom> Youenn: we don't have support for that atm
16:30:35 <dom> Henrik: moving up from PTZ:false to PTZ:true would require re-prompting right?
16:30:40 <dom> Youenn: right
16:31:09 <dom> Youenn: let's raise "muting" PTZ as a separate issue
16:31:47 <dom> RRSAgent, draft minutes v2
16:31:47 <RRSAgent> I have made the request to generate https://www.w3.org/2020/09/15-webrtc-minutes.html dom
16:31:55 <dom> RRSAgent, make log public
16:33:47 <dom> s/RESOLVE:/RESOLVED:/
16:33:49 <dom> RRSAgent, draft minutes v2
16:33:50 <RRSAgent> I have made the request to generate https://www.w3.org/2020/09/15-webrtc-minutes.html dom
16:35:23 <dom> Meeting: WebRTC Virtual interim
16:35:26 <dom> RRSAgent, draft minutes v2
16:35:26 <RRSAgent> I have made the request to generate https://www.w3.org/2020/09/15-webrtc-minutes.html dom