Re: Early morning thoughts on referrers.

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?


From: Jochen Eisinger <<>>
Date: Monday, November 10, 2014 at 2:32 AM
To: Anne van Kesteren <<>>, Mike West <<>>
Cc: "<>" <<>>, Devdatta Akhawe <<>>, Brian Smith <<>>
Subject: Re: Early morning thoughts on referrers.
Resent-From: <<>>
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.


On Mon Nov 10 2014 at 10:01:36 AM Anne van Kesteren <<>> wrote:
On Mon, Nov 10, 2014 at 6:10 AM, Mike West <<>> 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.)


Received on Tuesday, 18 November 2014 04:24:13 UTC