Meeting minutes
ISSUE 47 RTP Header Extension Encryption
Henrik: RTP data gets encrypted, but not headers in current implementations
… encrypting headers has an RFC, but it is not correctly implemented, due to its high complexity and big impact on SDP bloat
… this was discussed recently in AVTCore where the topic is handled
… The WebRTC WG needs to consider an API to enable encrypting RTP headers
… The proposal is a all-or-nothing switch in the API
… either encrypt everything or nothing
… The SDP representation will be defined in AVTCore
… from an API perspective, we would add an rtpHeaderEncpryptionPolicy field to RTCConfiguration
… the backwards compat option is "negotiate" (fallback to unecnrypted)
… and a new option "require" which throws if encryption is not possible
… there would also be a flag on Transceiver to indicate if encryption has happened
… My proposal is that by default, "negotiate" is picked (for backwards compat) - later we could consider movign to "require" once there is broad adoption
… There was discussion of adding this on a transceiver-basis, but we thought we should keep it simple
Bernard: in particular, separate encryption can't be done when BUNDLing
Youenn: could we ask AVTCore of a negotiation per session rather than per m-line?
Bernard: our proposal would work either way
Henrik: the AVTCore discussion may lead the flag to move from the transceiver up to the PeerConnection
Youenn: I like the config option and the rollout option
… I'm skeptical at the transceiver flag if what we want is the whole thing to be encrypted
Henrik: with the negotiate policy, you may end up with one m-section having encrypted headers and others not
… we could fail in that situation though
Harald: the encrypted negotiated flag belongs on the DTLS transport
Resolution: Add new option to RTCConfig, and add the flag to either PC or DTLSTransport based on AVTCore results
Bernard: AVTCore meeting is coming up - someone should volunteer a proposal
Media Capture
Issue 646
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
… Issue 646 is about making enumerateDevices return an empty list by default
… the current behavior exposes 2 bits of info: whether there is at least a camera, and whether there is at least a microphone
… after gUM resolves, we expose more info
… 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
… we ran an experiment with returning an empty list, and it turned out not Web compatible
… The proposal is to keep current approach and allow UA to fake presence of devices to UAs who would want to remove fingerprinting
PROPOSED: behavior of enumrateDevices() doesn't change; the WG will consider adding non-normative guidance on fingerprinting
Henrik: I support this
Dom: +1
Henrik: the problem would go away with the new device picker approach
Youenn: not necessarily you might still want to make the picker trigger optional i nthe UI
Resolution: behavior of enumrateDevices() doesn't change; the WG will consider adding non-normative guidance on fingerprinting
Issue 640
Youenn: PING suggested we reveal only label on devices users have granted permissions to
… the reason for exposing all labels is to allow for in-page picker
… The proposal would be to keep the current consensus with guidance on sanitizing labels
… For instance, Firefox & Safari sanitize the name of airpods (which often contains personally identifiable information)
… we already have some indirection between labels and what gets shown to JS, we could go a bit further
Henrik: +1
… I don't think we can remove labels as long as Web pages have to build their own pickers
… once an in-chrome pickers become the new way, we can reconsider, but that seems a long way in the future
Bernard: +1
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
Youenn: there are counter examples
Harald: I don't find that argument compelling enough for a change
Henrik: a UA could also pick to expose only a subset of devices
Resolution: Keep exposing all devices past gUM resolution with some possible anti-fp guidance
Issue 645
Youenn: enumerateDevices expose all type of devices, even if the user has only allowed one type of device (e.g. only mics)
… this could be reduced on a per device-type (e.g. gum(video=true) would only expose cameras)
… possibly exposing associated mics (based on groupId)
… I'm not fond of the additional complexity
Guido: Chrome only exposes cameras when only video is requested
… it has been that way for a long time
Henrik: this shows this is Web compatible :)
Youenn: I think if we go that way, we should expose associated mics
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
Youenn: true
Dom: is Chrome's behavior allowed in the spec?
Youenn: no, it's only a global boolean that controls enumerateDevices() exposure
Dom: so something needs to change no matter what
Harald: where do we stand on the WebDriver spec for gum?
Youenn: waiting for adoption by the WG I believe
Dom: so how do we move forward?
Youenn: I'm happy to align with Chrome in our impl
… my proposal on groupId was to align with how we deal with audiooutput where we expose a speaker once the mic is listed
Resolution: Adopt per-device type of enumerateDevice label exposure; follow up on current implementation status for possible extension based on groupId
Media Capture Image
Issue 243
Youenn: lot of discussions around Pan/Tilt/Zoom (PTZ) and how it is represented via constraints
… when you install an app, you get granted permissions to access e.g. cam + mic
… the only choice the user has is "install" or "not install"
… another approach is to leave granular choice to the user with a base permission plus additional permissions
… PTZ seems to fit better that model - default to "camera" permission, and allow upgrades to PTZ permissions
… 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
… [slide 17]
… there is no discussion to allow failure on not providing audio
… the same should work well for PTZ
… [slide 18]
… this has a big impact on how constraints would work for this in gUM
… e.g. what happens with gum({video {pan: {exact: 10}})
… if there is no PTZ device, this would reject with OverConstrained - this means increased a small fingerprinting increase
… 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
… if the user has a PTZ, but doesn't pick it - should this still be OverConstrained?
… it sounds like applying the getDisplayMedia model without requiring PTZ would work better
… if so, that means skipping all PTZ-required constraints in gUM
Henrik: isn't the information exposed in any case in getSettings?
Youenn: there are discussions in sanitizing getSettings based on what permissions have been granted - we'll come back to this later
… [slide 19]
… 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
… the UA may have to fallback on a non-PTZ device in case of hardware error
… the current spec doesn't give lower priority (via fitness distance) to PTZ constraints
… my proposal is to ensure the PTZ cameras get picked when permission is granted
… The result would be to add a ptz MediaConstraint (in addition to "video", "audio")
… and uses that as a trigger to prioritizing ptz devices - and request permission only if there is such a device
… pan, tilt and zoom would still be used as constraints for applyConstraints, but would be skipped in gUM
… [slide 21]
… This approach means no additional fingerprinting, allows PTZ position sanitization, it limits the complexity, is compatible with the future device-picker approach
… it's very different from the current spec, but solves real issues
Henrik: couldn't we throw on attempting to set required constraints on PTZ? would only allow "ideal"?
Youenn: we could do that; I think ptz: true is simpler though
Riju: [slide 24] we have an alternate proposal we submitted as a pull request, based on Jan-Ivar's input
Eero: the idea of the proposal is to align PTZ with other constraints in {video} with just boolean values rather than numeric values
Youenn: how would this work with UAs that have a different prompt from Chrome?
… also, doesn't fix the issue with PTZ permission granted while the browser not picking a PTZ device
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
… what's the prompt that you envision? how would the UA asks about PTZ device in a way the user would understand?
Youenn: the UA could be to allow it only for advanced users, or only to sites with persistent camera access
… if the user may have challenges understanding camera + PTZ prompt ("use and move a camera") vs camera without PTZ (just "use a camera")
… it's likely that users will make mistakes
Henrik: what's the risk of granting PTZ permission?
Youenn: with PTZ, the preview of what you grant access to is different from what may be exposed over time
… without the user being aware
Riju: note that PTZ is restricted to top level browsing context
Youenn: right, but there is no requirement to show the self-view over time
… that's why PTZ needs a different privilege level
… initially the plan was to keep it in the same permission, but we received feedback this needed a different permission which indeed makes sense
… that makes it harder to re-use the usual gUM constraints model
Riju: one limitation is that PTZ is only limited to video - PTZ permission supersedes the simple camera permission
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
Francois: we're talking about the spec - the UA can show a notification when the camera moves
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
Francois: why did you pick this additional ptz boolean?
Youenn: it's modeled after the getDisplayMedia approach to audio
… the idea is that it allows the user to opt-in to an additional privilege
… it's beyond a constraint
Harald: to me, PTZ feels very much like a constraint
… moving away from the original model makes it harder to understand the overall model
Henrik: yet, choosing a device feels pretty different from moving a camera - feels like different APIs
Youenn: they're exposed at different APIs (gUM vs applyConstraints)
Harald: I'm hesitant to add special rules and syntax
Dom: but how would we deal with the different permission level? constraints weren't built to deal with that
Youenn: as an implementor, I would want to show a different notification to the user before PTZ can be used
Youenn: my main point is that PTZ constraints should not be required
Henrik: I like that
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
Guido: we could treat them all as "ideal" rather than "exact"
Youenn: +1
Henrik: I think disregarding the required aspects for PTZ would be enough to get us what we want
… could we throw on required constraints for PTZ?
Youenn: is there consensus on not having required constraints on PTZ?
Harald: I'm not happy about special-casing
… I like throwing Overconstrained when the dev ask for required PTZ
Resolution: throw Overconstrainted on requried values for PTZ and deal with sorting devices separately
Guido: we need to understand the intersection with advanced constraints
Issue 245
Youenn: a page can use a PTZ device with or without PTZ permission
… if PTZ is granted, we should expose everything
… if not, we should expose that a device has PTZ capabilities, but without detailed information (min/max, dynamic values)
Francois: this increases the fingerprinting
Youenn: but only after gUM permission has been granted
… I think it's fine to expose some at that point
Carine: what's the use case?
Youenn: it gives the opportunity to the Web page to detect the availability of a PTZ device to expose a new PTZ-based feature
Henrik: fine with it
Dom: we should flag this for PING check given fingerprinting impact
Resolution: Sanitize PTZ capabilities/setting based on PTZ (the UA may expose additional PTZ info without PTZ permission) - subject to PING review
Carine: can PTZ be deactivated (like mute on mic)?
Youenn: we don't have support for that atm
Henrik: moving up from PTZ:false to PTZ:true would require re-prompting right?
Youenn: right
Youenn: let's raise "muting" PTZ as a separate issue