- From: Jochen Eisinger <eisinger@google.com>
- Date: Fri, 23 Dec 2016 08:51:59 +0000
- To: Brad Hill <hillbrad@gmail.com>, Evan J Johnson <e@ejj.io>, public-webappsec@w3.org
- Message-ID: <CALjhuic6LJJDrtA0kj_bcCFC9XaCWtZaHhz6bX-pbFHpqYO8Aw@mail.gmail.com>
What should I use as deadline date? On Thu, Dec 22, 2016 at 7:11 PM Brad Hill <hillbrad@gmail.com> wrote: > Great! This CfC successfully completed. Thank you for your patience. > Can you prepare a CR draft with a date of January 12th and we'll get it in > the publication queue? > > :) > > On Thu, Dec 22, 2016 at 7:01 AM Jochen Eisinger <eisinger@google.com> > wrote: > > The PR was closed, and I landed the updates to the "integration with CSS" > section (and a long tail of changes to the metadata section to make > specberus happy), and managed to push a new WD to > https://www.w3.org/TR/2016/WD-referrer-policy-20161222/ > > best > -jochen > > On Mon, Oct 17, 2016 at 11:07 PM Brad Hill <hillbrad@gmail.com> wrote: > > I am excited that Referrer Policy is ready for CR. One thing I'd like to > consider is some minor changes to the algorithms related to determine a > request's referrer in support of https://github.com/whatwg/html/pull/1917 > and https://github.com/whatwg/html/issues/1918, which suggest that > location.ancestorOrigins should also be redacted according to a parent > document's default referrer policy. > > I believe it would be enough to list the values of Request used in that > algorithm explicit inputs. I'll try and put together a PR for that today. > > On Mon, Oct 17, 2016 at 1:53 PM Evan J Johnson <e@ejj.io> wrote: > > Ah thanks Emily. I can see it's a hard question to answer now. Whatever is > processed last, but with one edge cases. If I understand the precedence is > (from highest to lowest): > > 0. ReferrerPolicy is no-referrer, or rel="noreferrer". > 1. Implicit, via inheritence. > 3. Any other referrerpolicy attribute that is not "no-referrer" > 4. Meta-tag. > 5.HTTP Header > > evan > > > > > On Sun, Oct 16, 2016, at 09:09 AM, Emily Stark wrote: > > Hi Evan, > If the browser recognizes the policy in a meta tag as a valid policy, then > it would override any policy set by a header for the document. This is > mentioned in > https://w3c.github.io/webappsec-referrer-policy/#unknown-policy-values > ("the value of the latest one will be used"), though I'd happily take > suggestions on how to make it clearer! > Emily > > On Sun, Oct 16, 2016 at 1:13 AM, Evan J Johnson <e@ejj.io> wrote: > > > Glad to see this is being finished! > > I'm curious the order of precedence of the 5 different ways to set a > referrer policy. > > This is very confusing in my opinion (something I will begin to say about > a lot of specs). The spec reads like the following is possible, unless I'm > missing something: > > 1. Blanket referrer policy set by header. > 2. Different referrer policy set by meta tag. > 3. Third policy as an attribute. > > I would assume the the most specific policy would win, in this case the > noreferrer attribute, but which policy wins out of 1 and 2? > > > evan > > > > > On Sat, Oct 15, 2016, at 09:18 PM, Emily Stark wrote: > > This is a call for consensus of the WebAppSec WG to request advancement of > Referrer Policy to Candidate Recommendation. > > The text for the proposed CR draft is to be the Editor's Draft at: > https://w3c.github.io/webappsec-referrer-policy/ > > This call for consensus will expire on 23-October-2016. Positive feedback > is encouraged and lack of feedback is considered "no objection". Please > send feedback to: public-webappsec@w3.org with a subject line beginning > with '[REFERRER]'. > > Thanks, > Emily > > > >
Received on Friday, 23 December 2016 08:52:41 UTC