Re: [tram] Path Forward for STUN ORIGIN

[Martin Thomson <[e-mail]>]

On 26 August 2015 at 13:59, Alan Johnston <[e-mail]> wrote:
> Hi Martin,
>
> This is a very interesting idea - thanks for raising it.
>
> Looking at the referrer-policy document, the proposal here is essentially a
> default global policy of "origin-only" except not quite as strict.

I was actually going to suggest that no-referrer be the default.  It's
the policy a lot of us wish we had for Referer.  Some of us configure
our browsers to do just that.

> The idea of the STUN or TURN URI suggesting the policy which would be
> enforced by the browser is an interesting one.

I wasn't suggesting that it be baked into the URI, but it is an
option.  Though in the same way that we no longer like to put
usernames and passwords in URIs, I don't think that including this
origin-policy attribute in there.

I was actually thinking that you would have an option on
RTCPeerConnection that set the policy.

> The referrer-policy document doesn't make any judgements on the various
> policy levels it defines. Is the "origin-only" policy considered privacy
> friendly in HTTP, or is it considered harmful?

That very much depends on where you stand.  "origin-only" is not
sufficient for some use cases, but is also too much information for
others.

> Do any browsers provide referrer-policy user interface controls?  If so, I
> wonder what the default setting would be?

Firefox provides control through about:config only, and in the most
obtuse fashion imaginable (you have to know what a value of 3 means).
The default policies vary depending on the different origins involved,
and whether they are secure (i.e.,https://) or not.  The defaults we
*want* are somewhat different to the ones that we *have* though.

> But if the HTTP experience is that the Referrer header field was just that
> it was a bad idea to begin with, then perhaps we should pay attention to
> that...

As I said, it is mixed.  Hence the suggestion to allow a measure of control.