See also: IRC log
<trackbot> Date: 19 October 2015
<mkwst> Kid has wonderful timing, sorry, need to run upstairs to get someone back into bed. :/
<dveditz> can anyone hear me on the phone?
<dveditz> misspoke, but thanks for confirming it's not just an empty void out there
<dveditz> http://www.w3.org/2011/webappsec/draft-minutes/2015-10-05-webappsec-minutes.html
<dveditz> minutes approved
<francois> TPAC is next week, the webappsec group is meeting thursday/friday and the plenary is wednesday
<dveditz> https://lists.w3.org/Archives/Public/public-webappsec/2015Oct/0057.html
<francois> only 4-5 people have signed up on the official agenda in gdocs
<francois> please fill in your name if you're planning on coming so that we know how to expect and how much space we have for observers
<rbarnes> link to this spreadsheet?
<dveditz> https://lists.w3.org/Archives/Public/public-webappsec/2015Oct/0057.html
<francois> rbarnes: it's in the list mail that dveditz linked to
<tanvi> rbarnes: ^^
<rbarnes> thanks
<francois> status of the feature: mike hasn't touched it since the last time
<francois> if someone wants to pick it up, feel free, it's not currently a priority for mike
<francois> pinning v. manifest: it's not clear which is the better model yet
<francois> mike will published a new "heartbeat" working draft for the spec
<francois> mike thinks it's probably worth doing, despite the controversy
<francois> david has an extension-based EPR prototype and was in the process of building it as a service worker
<francois> it could be done better inside the browser
<francois> since we could make more intelligent decisions
<francois> we need to decide as a group whether or not this is something that we want to put together
<francois> i.e. do we want to build things that restrict navigation
<francois> because it does break some forms of linking
<francois> it makes sense for applications to restrict their entry points but there's no way to prevent non-applications from abusing the feature
<rbarnes> that seems pretty bad
<rbarnes> (the evil nyt example)
<dveditz> rbarnes: devdattae
<dveditz> rbarnes: devdatta
<rbarnes> dveditz: ack, thx
<terri> Thanks, I'd forgotten what the controversy was
<terri> we're sort of interested in it for certain types of apps and I wanted to know what I might be stepping in if I started working on it.
<francois> chrome is not going to get to EPR in Q4 but might start in Q1
<francois> sites are already restricting their entry points using referrer checking
<dveditz> scribenick: francois
<dveditz> scribe: francois
<mkwst> jochen: Three open issues.
<mkwst> jochen: 1. Adding spec text about `referrerpolicy` attribute on `<a>`, etc.
<mkwst> ... Agreement about how to implement, but needs to get into the spec.
<mkwst> ... 2. `Ping-From` needs to be associated with a referrer policy.
<mkwst> ... Need to update this in HTML.
<mkwst> ... 3. Need to add spec text about CSS stylesheets.
<mkwst> ... How do they get a referrer?
<mkwst> ... CSS doesn't currently spec this. Doesn't interact with Fetch.
<mkwst> ... Talked with Tab. Asked for input.
<mkwst> ... Differences between Chrome and Firefox. Neither really consistent.
<mkwst> ... Chrome takes the referrer policy from when the stylesheet was created rather than when the resource is loaded.
<mkwst> ... Firefox takes the referrer from the stylesheet and the policy from when the resource is loaded.
<mkwst> ... Right now you can set the policy from CSP, which is strange from CSP's point of view, because it's non-restrictive in the `unsafe-url` case.
<tanvi> what about francois proposal on more policies? is that for v2?
<mkwst> ... mkwst proposed splitting it out into a separate header.
<mkwst> ... Do we need new kinds of policies? Change default behavior? Etc. Ongoing discussion.
<dveditz> scribenick: mkwst
jochen: My goal at the moment is to make the spec reflect reality, not radically change.
<dveditz> scribe: mkwst
jochen: Can be a goal, but at
this point for stylesheets we don't even have a spec that
explains anything.
... Let's explain before we attempt broader change.
dveditz: Is there a test
suite?
... Or just ad-hoc?
jochen: Bunch of layout tests in
Blink.
... Ran them on Firefox to discover differences.
... The layout tests I've looked at are only touching on some
of the specs, only looking at one level of indirection.
dveditz: Tests check for the referrer?
jochen: Stylesheet loads an
image, image is different color based on referrer.
... Also inspect network traffic.
... Modify URL with history API. Should get updated URL in
theory.
... Both Firefox and Chrome use the document's URL at the time
the stylesheet was created.
... Chrome uses the policy from that time as well, Firefox uses
the current policy at the time of the request.
... Anne argues that both should come at the point in time
where the resource is loaded.
... I think I agree, checking with Tab to make sure that this
behavior is consistent in CSS, doesn't break anything.
dveditz: We don't yet support meta CSP, can you change the policy?
dev: You support the <meta name> method.
dveditz: Kind of a mess that there are two ways to do that.
jochen: If I could go back in
time, I wouldn't have done the <meta> thing.
... Interacts strangely with the preload scanner.
... But <meta> is supported cross-browser, is actually
used.
dev: Same problem with content
encoding, right?
... Some folks can't modify the header. Service Workers tried
really hard to avoid headers.
jochen: Right. Can't talk about
the preload scanner in the spec, as it's an implementation
detail.
... Firefox will discard the initial response, whereas Chrome
will take the response from the memory cache, etc.
dev: That's weird. If the referrer has leaked, we're already beyond the point where discarding is useful.
jochen: Yup.
dev: Spec should talk about best practice for developers.
jochen: If you rely on <meta> to protect the referrer, the preload scanner will ruin your day.
dev: Firefox reads referrer policy during scan, right?
jochen: Kinda. <reexplains above>
dveditz: Well, the spec lists
different reasons why you might want to change the referrer.
Privacy is the first one.
... Might be some use to throwing away the content if the
referrer results in different content.
jochen: I would hope that a developer would send a header.
dveditz: Should probably add that
as a recommended practice.
... Security considerations section, which this document
doesn't appear to have.
jochen: Sure.
... Also, `referrerpolicy` attribute helps with the typical
case in which <meta> is injected to change the policy for
a specific navigation.
dveditz: Once Firefox closes the <head>, I'm pretty sure that you can't change the policy.
jochen: Works in Blink and Safari, it's what Google search uses.
dveditz: Should add to the spec?
jochen: Ideally, folks would use the header and `referrerpolicy` attribute, and not <meta>.
<ckerschb> ckerschb: confirms what deveditz says about <meta> referrer
rbarnes: Should we deprecate the <meta> tag?
jochen: It's the only thing in Safari. Kind of a hard sell.
dev: Should recommend using the header. Don't see what we achieve by deprecating.
(https://www.chromestatus.com/metrics/feature/timeline/popularity/243 shows the number of page views that reset the <meta> referrer policy dynamically after it's been set)
(~0.08% of page views)
<tanvi> link to francois' proposal with more finer grained referrer policies: https://lists.w3.org/Archives/Public/public-webappsec/2015Aug/0074.html
dveditz: Issues haven't been moved. Just noting in case folks are looking for them,
https://github-issue-mover.appspot.com/
^^^ is a nice tool to move issues from one repo to the other.
jochen: Reasonable to update the spec to define fallback behavior for unknown policies.
dev: Hooray.
dveditz: Will probably cancel the
call after TPAC (Nov 2nd). Will bump those to the next call
after that (Nov 16th).
... Will send a mail from TPAC about the call on Nov 2nd. Let's
see how it goes.
... Thanks! See you next time!