- From: Mike West <mkwst@google.com>
- Date: Thu, 12 Jun 2014 17:17:52 +0200
- To: Sid Stamm <sid@mozilla.com>
- Cc: Sid Stamm <sstamm@mozilla.com>, "Hill, Brad" <bhill@paypal.com>, Jochen Eisinger <eisinger@google.com>, John Kemp <john@jkemp.net>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Adam Barth <abarth@google.com>
- Message-ID: <CAKXHy=e_B5ynwQ8ngNCTysYMKPWwKG4LtcFao1=wKCVmnOfEyA@mail.gmail.com>
I didn't at all mean "quiet down". I mean "file bugs that we can poke at in the future" and "make sure we're not crazy when we're defining things". Feedback === good. :) -mike -- Mike West <mkwst@google.com> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.) On Thu, Jun 12, 2014 at 5:16 PM, Sid Stamm <sid@mozilla.com> wrote: > Right Mike, agreed on all fronts. I'll quiet down. Draft looks good to > me. > > -Sid > > On 06/11/2014 11:57 PM, Mike West wrote: > > On Wed, Jun 11, 2014 at 10:31 PM, Sid Stamm <sstamm@mozilla.com > > <mailto:sstamm@mozilla.com>> wrote: > > > > Ok, sure, but I wanted to mention it to avoid ending up with a spec > > that is incompatible with that future. > > > > > > The spec currently defines the `rel='noreferrer'` attribute as > > overriding the page's referrer policy for a specific navigation. I don't > > think there's any reason that we couldn't define similar attributes > > which would override the page's referrer policy for other types of > > resource requests (even going in the other direction: > > `rel='alwaysreferrer'`?). > > > > I'd agree with Brad, though, that it's probably best to just get this > > out the door after ensuring that it accurately describes user agent's > > current behavior. There's plenty of time to invent new behavior once we > > have these basics pinned down in a way we generally agree upon. > > > > > > If we want to do something smarter than reverting to Never, would it > > make sense to rank the states and when resolving conflicts, pick the > > highest-ranked one? Just a thought. Maybe another future-destined > > idea. > > > > > > The current spec is pretty draconian in its conflict-handling, granted. > > It's not entirely clear what a reasonable ordering of states would be, > > however. For instance, is "Origin" higher or lower than "None When > > Downgrade"? > > > > An alternative would be to just let the last-set policy win. That might > > have some advantages for single-page apps, as the current behavior locks > > an app into one referrer policy forever. It's certainly imaginable that > > an app built upon pushState, etc might want different referrer policy > > for different pieces of the app. *shrug* > > > > I'd like to support those kinds of use cases. I'm not sure I want to do > > that in the first version of the document. :) > > > > -- > > Mike West <mkwst@google.com <mailto:mkwst@google.com>> > > Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 > > > > Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany > > Registergericht und -nummer: Hamburg, HRB 86891 > > Sitz der Gesellschaft: Hamburg > > Geschäftsführer: Graham Law, Christine Elizabeth Flores > > (Sorry; I'm legally required to add this exciting detail to emails. > Bleh.) > > > > >
Received on Thursday, 12 June 2014 15:18:41 UTC