Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling

[Lennart Grahl <[e-mail]>]

On 12.04.2018 14:41, Lorenzo Miniero wrote:
> On Thu, 12 Apr 2018 14:22:17 +0200
> Lennart Grahl <[e-mail]> wrote:
> 
>> On 12.04.2018 00:31, Sean Turner wrote:
>>>> On Apr 11, 2018, at 16:10, Adam Roach <[e-mail]> wrote:
>>>>
>>>> [as an individual]
>>>>
>>>> On 4/11/18 1:15 PM, Lennart Grahl wrote:  
>>>>> Since I haven't seen a satisfactory response so far, let me
>>>>> rephrase this as a question: Can anyone explain to me why that
>>>>> approach is not considered a valid alternative to getUserMedia?  
>>>>
>>>>
>>>> I think you're not getting a lot of response here because what
>>>> you're proposing is well within the bounds of what the current
>>>> document says. gUM is offered as a non-normative example, but
>>>> that's all it is. If you believe that document changes are in
>>>> order, perhaps a concrete proposal along the lines of "change the
>>>> text <x> to be <y> instead" or "add text <z> at the end of section
>>>> <q>" would produce more conversation.  
>>
>> Thanks, this and the response from Bernard is good feedback that I
>> should provide a more concrete proposal next time.
>>
>>> As the draft’s Shepherd trying to figure out how to bring closure
>>> on this issue, I like to offer a summary:
>>>
>>> There’s some discomfort with the use of the term “user consent” as
>>> well as the non-normative example provided for how to get it. The
>>> problem with changing the term to something else is "user consent"
>>> is a term of art; we can’t really qualify it with something like
>>> “informed”, because we’d need to explain what that means (and well
>>> GDPR …), and; frankly the term is used extensively in the other
>>> security draft that we pruned ip-handling from.  The problem with
>>> changing the non-normative example is that there don’t seem to be
>>> other attractive/realistic alternatives.
>>>
>>> What I’d like to do is remind everybody that we pruned this draft
>>> from the other security drafts to allow it to be updated faster
>>> because it’s about a much narrower subject.  With this in mind and
>>> Bernard’s long list of questions, I would like to propose that we:*
>>>
>>> 1) Add another sentence (from Tim) that indicates there are other
>>> alternatives:
>>>
>>>       Alternatively implementations can provide a separate
>>>       mechanism to obtain user consent.
>>>
>>> 2) Progress the draft out of the WG.*
>>>
>>> 3) Update/Obsolete this draft, when a much superior alternative
>>> emerges.
>>>
>>> spt
>>>
>>> * Also "hold your nose" if you’re sad about this proposal but are
>>> willing to begrudgingly live with the rough consensus; it’s rough
>>> and we noted this in the Shepherd write-up.
>>>
>>> ** Remember that during the IETF LC we (or somebody in the wider
>>> IETF community) might come up with something during the IETF LC.  
>>
>> I realise I've joined a tad late and it should be clear by now that I
>> have a strong reluctance when it comes to using getUserMedia for the
>> purpose of getting consent to use mode 1. But you are correct, it is
>> non-normative and I'm more irritated by the implementations that don't
>> provide an alternative than this document. Still, I would appreciate
>> if the sentence from Tim you mentioned in 1) will be added.
>>
>> Regarding 3): Like Bernard, I'm unsure how to determine a "superior
>> alternative" (especially in the context of a non-normative section).
>>
> 
> 
> Since there seems to be a call for proposed text:
> 
> 	The details of this consent are left to the implementation; one
> 	potential mechanism is to tie this consent to getUserMedia
> 	consent.  It should be noted, though, that getUserMedia
> 	consent is typically only required when users are supposed to
> 	share media content from their local devices. This may not
> 	always be the case, e.g., in scenarios where users will only
> 	be receiving media (e.g., a broadcast), or when
> 	PeerConnections are created for the sole purpose of setting up
> 	datachannels. Requiring getUserMedia consent when it's not
> 	really needed may end up discouraging users from establishing
> 	a media session, or getting unwarranted access to more
> 	information they meant to share. As such, alternative and more
> 	appropriate means for getting user consent for Mode 1 are
> 	suggested.
> 
> Probably overly verbose, but it voices my (and I think Lennart's)
> concern with the current text.

Likely a verbose version of https://github.com/juberti/draughts/pull/98.
But I appreciate and would agree with that since it clarifies that some
non-obvious use cases exists that we have found throughout the years
where getUserMedia is painful (if anything). I don't know if that's an
appropriate way of telling implementers about these use cases, though.

Cheers
Lennart