- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Tue, 15 Sep 2020 18:35:46 +0200
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
Hi,
The minutes of our call today (Sep 15 2020) are available at:
https://www.w3.org/2020/09/15-webrtc-minutes.html
and copied as text below.
Dom
WebRTC Virtual interim
15 September 2020
[2]IRC log.
[2] https://www.w3.org/2020/09/15-webrtc-irc
Attendees
Present
Bernard, Carine, Dom, Eero_Hakkuinen, Florent,
Francois_Beaufort, Guido, Harald, Henrik, Jianjun_Zhu,
Palak, Patrick_Rockhill, Riju, Youenn
Regrets
-
Chair
Bernard, Harald
Scribe
dom
Contents
1. [3]ISSUE 47 RTP Header Extension Encryption
2. [4]Media Capture
1. [5]Issue 646
2. [6]Issue 640
3. [7]Issue 645
3. [8]Media Capture Image
1. [9]Issue 243
2. [10]Issue 245
4. [11]Summary of resolutions
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
Summary of resolutions
1. [12]Add new option to RTCConfig, and add the flag to either
PC or DTLSTransport based on AVTCore results
2. [13]behavior of enumrateDevices() doesn't change; the WG
will consider adding non-normative guidance on
fingerprinting
3. [14]Keep exposing all devices past gUM resolution with some
possible anti-fp guidance
4. [15]Adopt per-device type of enumerateDevice label
exposure; follow up on current implementation status for
possible extension based on groupId
5. [16]throw Overconstrainted on requried values for PTZ and
deal with sorting devices separately
6. [17]Sanitize PTZ capabilities/setting based on PTZ (the UA
may expose additional PTZ info without PTZ permission) -
subject to PING review
Minutes manually created (not a transcript), formatted by
[18]scribe.perl version 123 (Tue Sep 1 21:19:13 2020 UTC).
[18] https://w3c.github.io/scribe2/scribedoc.html
Received on Tuesday, 15 September 2020 16:35:52 UTC