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

[Justin Uberti <[e-mail]>]

Being non-interactive, it's not clear that those cases require Mode 1
though; they should work well even in Mode 2. I also don't think that
suggesting "more appropriate means" is useful when we as a WG haven't been
able to come up with any.

Note also that between -02 and -03, we as a WG chose to remove a more
explicit discussion of getUserMedia, namely this para:

       The getUserMedia
       suggestion takes into account that the user has provided some
       consent to the application already; that when doing so the user
       typically wants to engage in a conversational session, which
       benefits most from an optimal network path, and lastly, the fact
       that the underlying issue is complex and difficult to explain,
       making explicit consent for enumeration troublesome.


If we're not going to talk about the upsides of the getUserMedia
mechanism, I don't think we should have a lengthy discussion of
downsides either.




On Thu, Apr 12, 2018 at 4:49 PM Lennart Grahl <[e-mail]>
wrote:

> 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
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>