Re: Early morning thoughts on referrers.

Perusing the notes and from my memory (others please correct):

 1) People liked the idea of "this is the referrer for everything on this page"
 2) That policy was felt simple enough to fit well in a declarative model, alongside the existing tokens

I don't recall that we made an affirmative resolution to add it.  I think, lacking any objections, you should propose text to the editors and we'll see if there are implementations when we move past CR.

-Brad

From: Devdatta Akhawe <dev.akhawe@gmail.com<mailto:dev.akhawe@gmail.com>>
Date: Monday, November 17, 2014 at 8:41 PM
To: Bradley Hill <hillbrad@fb.com<mailto:hillbrad@fb.com>>
Cc: Jochen Eisinger <eisinger@google.com<mailto:eisinger@google.com>>, Anne van Kesteren <annevk@annevk.nl<mailto:annevk@annevk.nl>>, Mike West <mkwst@google.com<mailto:mkwst@google.com>>, "public-webappsec@w3.org<mailto:public-webappsec@w3.org>" <public-webappsec@w3.org<mailto:public-webappsec@w3.org>>, Brian Smith <brian@briansmith.org<mailto:brian@briansmith.org>>
Subject: Re: Early morning thoughts on referrers.

forgive me, but I thought, on the call, there was agreement that the basic "use this same-origin URI as referer" is ok for the declarative mechanism?

cheers
Dev

On 17 November 2014 20:23, Brad Hill <hillbrad@fb.com<mailto:hillbrad@fb.com>> wrote:
Yes, we discussed this on the call.  Takeaways were:


  1.  The current behavior is what is already implemented in Webkit browsers.
  2.  We should only complicate a declarative policy mechanism so much.
  3.  ServiceWorkers seem like they might be a good fit for doing fine-grained control of referrer headers in an imperative manner.

Therefore, the group was inclined to leave the spec more or less as-is, at least for declarative purposes and CSP, and continue exploration of a more fully featured API for ServiceWorkers and Fetch.

Can everybody live with that?

-Brad

From: Jochen Eisinger <eisinger@google.com<mailto:eisinger@google.com>>
Date: Monday, November 10, 2014 at 2:32 AM
To: Anne van Kesteren <annevk@annevk.nl<mailto:annevk@annevk.nl>>, Mike West <mkwst@google.com<mailto:mkwst@google.com>>
Cc: "public-webappsec@w3.org<mailto:public-webappsec@w3.org>" <public-webappsec@w3.org<mailto:public-webappsec@w3.org>>, Devdatta Akhawe <dev.akhawe@gmail.com<mailto:dev.akhawe@gmail.com>>, Brian Smith <brian@briansmith.org<mailto:brian@briansmith.org>>
Subject: Re: Early morning thoughts on referrers.
Resent-From: <public-webappsec@w3.org<mailto:public-webappsec@w3.org>>
Resent-Date: Monday, November 10, 2014 at 2:32 AM

I'm not sure that introducing additional complexity into the referrer policy spec is worthwhile. I see the referrer policy as working around some short-comings for websites moving to https, but I don't think that referrers in general are such a great feature that we should make it more compelling to use.

best
-jochen

On Mon Nov 10 2014 at 10:01:36 AM Anne van Kesteren <annevk@annevk.nl<mailto:annevk@annevk.nl>> wrote:
On Mon, Nov 10, 2014 at 6:10 AM, Mike West <mkwst@google.com<mailto:mkwst@google.com>> wrote:
> As a strawman, let's break requests into two buckets: same-public-suffix
> and cross-public-suffix,

Why do we need to bring public suffix into this? That seems like a bad idea.

I agree with Brian that we want to differentiate subresources from
"navigation" (client fetches?). Service workers also need that
distinction, perhaps we should come up with some kind of definition
based on request contexts. (For that we also need to resolve that
dedicated worker question I posed a while back.)


--
https://annevankesteren.nl/<https://urldefense.proofpoint.com/v1/url?u=https://annevankesteren.nl/&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=jVV398LIUT3H%2FO4pIApxFevQTEeBV8C9ugbB3rreDzo%3D%0A&s=d51a2323dcef215c3ebf3e1fc231ae3595d67d15598264874a6ff1496b9d6f3c>