Subject: Re: [rtcweb] Review of ip-handling

From: Justin Uberti <[email-masked]>
Date: Tue, 4 Jul 2017 19:55:12 -0700

Thanks for the review. Most of these comments have been resolved in the
latest version of the document, https://tools.ietf.
org/html/draft-ietf-rtcweb-ip-handling-04, aside from the Section 3 and
RETURN issues, which I hope to address shortly.

On Tue, May 9, 2017 at 6:46 PM, Martin Thomson <[email-masked]>
wrote:

> In Section 3, please don't imply that WebRTC is only for privacy.  At
> a minimum "Being peer-to-peer, WebRTC represents a technology that
> could improve privacy,"  Though I'd avoid this sort of statement
> altogether.  One interesting side effect of unintermediated or
> peer-to-peer communications is that there is now network-level
> metadata showing who was communicating.  There is a direct flow
> between peers.  The privacy gain (no single middleman with access to
> communications metadata) becomes a potential loss (passive network
> observers can see who was talking more easily).
>
> I think that Section 3 could be more simply stated as:
>
> Provide a framework for understanding the problem so that controls
> might be provided to make different trade-offs regarding performance
> and privacy concerns with WebRTC.  Using that framework, define
> settings that enable peer-to-peer communications each with a different
> balance between performance and privacy.  Finally, provide
> recommendations about settings that provide reasonable performance
> without also exposing addressing information in a way that might
> violate user expectations.
>
> In Section 4, the mention of RETURN isn't really necessary and it will
> stall progress of this draft.  The framing of RETURN ensures that it
> falls into the "proxy" definition quite neatly, so it will work
> without changing this draft.  Though RETURN would reduce the
> performance downsides of the higher-numbered modes - significantly -
> it doesn't really need a special mention here.
>
> I'm not very enthusiastic about this bullet in Section 5:
>
>    o  Future versions of browsers may present an indicator to signify
>       that the page is using WebRTC to set up a peer-to-peer connection.
>       Applications MUST only use WebRTC in a fashion that is consistent
>       with user expectations.
>
> The indicator thing is kinda speculative; based on my experience with
> these things, I'd say that the chances that we did that would be close
> to zero.  Also, the MUST here is completely toothless to the point
> that I think it's dangerous.  Applications will care to the extent
> that they care, and yelling at them isn't going to influence that one
> iota.
>
> Also, since the whole point of this document is to establish a
> framework for thinking about this specific problem, I think that it's
> safe to remove this sentence.  I would remove the entire bullet point.
>
> Nits:
>
> Many of the references need to have a space after the closing bracket.
>
> Remove the reference to 8.8.8.8.  It's actually a good example, but
> it's not necessary and it is likely to cause some people's heads to
> explode.  As much as I might personally enjoy that, it's not my
> document; you might be better avoiding this.
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>