See also: IRC log
Stefan run through the initial slides...
bernard talks us through the slides
Stefan: First two mediacapture-main issues, #350 & #359
Stefan: First out: Harald talking about #350
Harald: reason to reference
Permission API spec - to do like everyone else
...done fairly well, but not completely well
Harald: persistent vs.
temporary permissions. Permission to use again or not was
unclaer. Revocation was also unclear. Those two were or
problems.
... problem with Permission spec was that it is changing.
... Will go through three issues in sequence, hoping to get
agreement on them.
Harald:#1: what is temporary grant?
... e.g. use this camera once only
... do getUserMedia again on the same device. Prompted or
not?
... I think the spec now says track B gets permission without
prompt. Similar to clone track.
... three options A, B, C - see slide.
Justin: how do others do?
Harald: they do not have
temporary permission, and use revocation instead to take away
permission.
... therefore I put temporary permission in our spec.
Martin: geolocation implementations have temporary permission.
JiB: FF asks everytime, Safari
different.
... What interop problems are we solving by speccing this?
(unknow said something I did not catch)
<vivien> (slide 8)
Martin: tha tis what we got permission API for - the site can check
JiB: FF is updating permission UI
Harald: JiB you're proposing we do not to spec this out?
JiB: this is an area where
browsers add value
... and differentiate
Ekr: I'm not follow, A and C
seems to be the same.
... big problem is prompting, the site need to know
Justin: needs to be clear if gUM
on same device gives prompt.
... we need to decide if we want A or C minimum
JiB: Permission API allows checking if a prompt will be shown or not
Justin: we could have different policies in different browsers asa long as we can check
Harald+Martin: we seem to agree on A
Justin: Chrome implements B
Martin: no, Chrome is fine with A
Justin: I think we're good.
Conclusion: current spec OK!!
Harald: raise a nwe bug if you find it not determistic
Next slide
<vivien> (slide 9)
Harald: About registration so
site would know if permission was revoked
... we don't have text for that
... two alternatives
... A do nothing when revoked
... B stop all track and fire "ended" event on the tracks
JiB: Sounds fine, but I'm confused about the Permission API - does it talk about the site or about the user?
Harald: seems to be two ways to reack revoked: site, UA can learn new info that leads it to revoking
Adambe: Comment to JiB: we've had stop() on track were a site can revoke its own permission
Ekr: ....missed...
JiB: stop() only deals with temprary permission, not persisted permission
<dom> [use case for permission revokation for getUserMedia from the site: the site wants to take a profile picture, but just once; ask for permission, gets the picture, then revoke it]
<mt_____> revoke() resets all access to that origin
<mt_____> stop() just ends access to the track, if it's the last thing using that device, then the device can turn off
JiB: problem is that permission has a booleabn model, not none/temporary/persisted/
Harald: I think hearing that if permission is revoked tracks should stop.
Next slide: choosing from devices
Harald: permission spec separated
requesting permission and prompting user (to select right
device)
... I propose we change gUM to use the prompt the user
algorithm from the permission spec (and drop the distance
fitness stuff in gUM
JiB: is the intent to be neutral functionaluty wise?
harald: yes
JiB: not sure why we're creating
a dependcy on a spec that is still alive
... when in last call
Harlad: algorithm badly chosen word by me, its really an API
JiB: this does not anything like the request API
<vivien> (we are on slide 10)
JiB: we're going to ask for the resource, not fiddle with the settings. Makes sense?
Harald: yes, unfortunately
... I'll file a new Issue, and we will return to this
question.
JiB: OK with me. Question: what did we aim to solve with refering to Permission API?
Dom: one goal was to get revokation from the permission API
<mt_____> hta1: we can still use https://w3c.github.io/permissions/#prompt-the-user-to-choose; it doesn't imply a transition to "granted" in response to a positive result
Dom: still some open ends.
Martin: I think we can use the
permission promtp the user algorithm
... does not imply the permanent permission state would
change
<Erik_L> @vivien I can take the slides now if that is desired
JiB: we can spec it in gum
Martin: editorial question.
Shijun: permission per device type, not per deviceId.
Martin: good qusetion. Permission
spec vague on this point on purpose. Browsers differ.
... all up to how the browser interprets the signals from the
user.
Harald: when I patched the
permission spec I included the deviceId. The idea was to allow
using the permission API per device if the UA wants to.
... up ro UA.
Shijun: So Chrome would allow any camera to be used if there is permission to use one camera.
Harald: other issues (slide 11)?
<dom> ScribeNick: dom
<vivien> Erik_L, you are now presenter
<burn> shijun, there is some wording in the spec that the user needs to be made clear on whether the permission grant they give is per device or per device type, but the UA may choose either type as long as they are clear
Stefan: Browser is currently
required to clear deviceId if permission was not granted and
browsing session ended
... this was added from the PING review to reduce the
fingerprinting surface from device enumeration
... issue 359 proposes to change this MUST to MAY
... the argument being that this is similar to cookies and
should be treated the same
... from an architectural perspective, it adds complexity, and
likewise for implementation
mt: when we added this from PING
review, it was unclear what we meant by "browsing
session"
... since then, the definition seems to have converged towards
something that makes this very complex to implement
... and that complexity seems unnecessary
jib: I wrote the code martin
referred to
... I had to diverge from what the spec describes a little,
tracking across tabs and windows for the given origin
... so it's already more complex than "closing a tab" being the
end of a browsing session
... so if we keep the same as current, we would need to bring
further clarity
ekr: what's the argument for keeping the current text?
stefan: it brings a fingerprint surface
ekr: just like cookies
stefan: but cookies aren't
exposed the same way
...we would have to add text saying persisted deviceIds must be shown
when the user inspects cookies for a site, that they must be cleared
when cookies are cleared, and that if the user does not allow cookies
for a site then persisting deviceIds is not allowed for the site to make
them the same
ekr: that sounds like a great solution
mt: we could then provide the right UX for this
jib: should we then link the MAY to having deviceIds exposed just like cookies
stefan: that would work for me
justin: so the proposal is "MUST" by default, and a MAY if the browser provides a cookies-like UX
mt: I think we're describing
something a bit more engaged than this: e.g. if a site can't
store cookies, deviceIds can't persist
... if you clear your cookies, deviceIds get reset
ekr: the easiest way to implement this would be to create a pseudo-cookie for the device identifier
mt: I believe that's what some implementations do
ekr: although you wouldn't make it accessible through .cookies
stefan: I think we have 2 options: keep the MUST, or change to MAY and refer to cookie behavior
ekr: I think the 2nd is quite
clearly superior
... ie remove the MUST, and add text on cookie-behavior
... the current is not a useful feature
jib: note that as soon as you use
gUM, the deviceId becomes persistent, which is probably 99% of
cases
... but I would be happy with text making temp deviceId similar
to cookies
justin: remind me whta's the privacy issue?
stefan: the drive-by Web not
intending to use your camera but just doing device enumeration
to act as a cookie
... anyone willing to create a pull request to propose this
change?
mt: I tried several times and got yelled at, so can't do it
jib: I can give it a shot
... what behavior would we require for the MAY?
mt: my expectation is that during
a browsing session, these identifiers MUST be stable
... and the browser SHOULD persist them as long as cookies, and
MUST NOT keep them longer than cookies
... if a site is blocked from using cookies, I'm not sure what
we should do
... but we would need to say something about that
stefan: I think we need the same requirement that the deviceId can't be the same across browsing sessions
mt: or even across realms
... there are multiple ways
jib: anything about making the deviceIds being as visible as cookies? currently they're not
shijun: [missed]
mt: I don't think we should put UX requirements in
shijun: I think the current text
has a good balance between privacy and the usage scenario
... I don't think Chrome would satisfy the new
requirements
... and I don't they should need to since this is lower privacy
level
mt: not sure what you're suggesting; maybe you could provide a pull request to clarify?
shijun: I prefer to stay with the current text
<burn> shijun is saying that he wants the current text.
mt: my position is that if someone wants to implement the current text, that's fine with me
<burn> (the MUST clear text)
mt: so whatever text we produce should allow what the current spec mandates
jib: if we add the MAY, it would still allow the "hidden cookie" approach current browsers do
stefan: (in fact, in Chrome, clearing cookies doesn't clear deviceIds - you need to go through a different menu)
jib: selecting all "cookies"
filtered for a given site won't clear deviceIds indeed, neither
in FF nor in Chrome
... but clearing cookies for a site should work
stefan: can we proceed with jib providing a pull request, and we check that it allows the current spec behavior?
jib: I'm not sure I know what the
right language would be though
... but I can give it a shot
<vivien> Issue 644/PR 675: Attribute to turn on/off CN/DTX (Bernard Aboba)
Bernard: our goal is to allow to
turn on/off DTX immediately on RtpSender
... stefan noted that in some cases, DTX is always on
... harald asked about DTX being activable only if CN has been
negotiated
justin: I don't know how that would work
harald: the easy way out would be to define "no comfort noise" as "lower comfort noise level possible"
stefan: can I ask about use cases?
ekr: I thought this was about
Opus where you can't actually have CN
... where 911 require CN
Bernard: one way to solve this is to @@@
ekr: I think cullen had a strong opinion on this
Bernard: the other question is
whether anything is needed on receiver
... or it should always decode
<scribe> scribenick: stefanh
Just about the sender.
next slide
Current state of PR.
<vivien> (slide 15)
Bernard: see slide.
...question: what if getParam on a receiver, what will read out
for DTX?
... boolean on Enum?
Justin: we'll be sorry if we do
boolean, let's use Enum
... bike shed names
Bernard: next slide
<vivien> (slide 16)
Bernard: see slide
Bernard: use codec prefs to turn
on/off FEC etc.
... PR647 clarifies what is on slide 16, not changing
anything.
... comments?
... Pr683 proposes changes
... removes rtx from codecs[]
... next slide
<vivien> (slide 17)
Bernard: impact: creates problem, removes possiboility to take rtx in
or out
... rtx entry for each codec transmitted
Justin: if we hate how rtx works, why don't we change that instead of creating crazy apis? Use flex-rtx
Bernard: my rec is to not merge 683. OK?
Justin agrees
Bernard: next slide, issue 706 set direction
Bernard: JSEP 5.2.4 direction
attributes in offer
... what states are referred?
... next slide
... WebRTC 1.0 5.1: relation between setDirection and
active/inactive senders/receivers
... next slide: WebRTC 1.0 5.4
... next slide: all the above creates confusion, Peter put up a
proposal at github, see explanation i slide
...Proposal: remove references to WebRTC 10 5.1 and update JSEP
5.2.4
<Erik__L> -40 mins remaining
Justin: this makes sense
Bernard: next slide proposes
change to WebRTC 10 5.1.
... see slide for details
... makes sense?
XX: makes sense
Next slide, IdP. Martin to talk.
Martin: Issue 555: IdP needs
extra info from the user
... current spec is bad: Throws, DOM exception
... next slide has proposals
... Option 1: overload return value - not great
... Option 2 extra arguments to callback
... I prefer Option 1. What do people think?
PR to be written by Martin for Option 1.
Martin: Issue 678: identify the
receiver
... Cullen has been doing this in an inelegant way
...proposal: extend setIdentityProvider
...question: how to populate in certain situation (when it is
unknown)?
Ekr: Martin's proposal seems OK
Martin: the IdP will know who you are talking to, not a big problem
Ekr: FB works like this, feature rather than a problem
Bernard: Issue 685
... receive multiple RTP encodings (receive multicast)
... a case talked about in JSEP, but not described
... proposed to describe in JSEP
... any opinion
Justin: we've talked about this, and we think we should have a section describing simulcast that can referred to
Bernard: next slide
Bernard: Issue 692 liveness
checks
... what is meant? How many must fail to go to
disconnected
... next slide.
Justin: I think liveness checks refers to rtp packets not coming in
Peter: can be different things
Bernard: wow more complex than I understood
Varun: I think applications are looking for detection speeds in the order of 100ms
Justin: more on the "some
seconds" level
... we should have two different things: transport OK, and
packets being received. Different things.
Peter: we could reveal info on
consent checks and last time a packet was received.
... if we do that, what does disconnected mean? is it
needed?
Bernard: [missed]
Varun: I think revealing the timestamp in stats is enough, we may not need disconnected
Bernard: in ortc it means consent check has failed.
Justin: disconnect related to consent checks.
Harald: relates to next issue - circuit breaker
<vivien> webrtc-pc Issue 700
(different meanings of connection between circuit breaker and disconnected)
Bernard: anyone implementing circuit breakers?
Justin: we might consider to implement.
Liveness checks need more time, and we're out.
<Erik__L> yes my bad, 10 mins over
<vivien> [meeting adjourned]
<hta1> hm. can we make liveness checks an IETF topic and discuss it in Berlin?