See also: IRC log
<bhill2> thanks for setting up the meeting, wseltzer
<jochen> can we do referrer policy first please?
<bhill2> sure
<jochen> thx
<bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2016Jan/0059.html
bhill2: Any suggestions for agenda items?
mkwst: If we have time, we could chat about intranet/internet thing.
bhill2: Ok.
<bhill2> http://www.w3.org/2011/webappsec/draft-minutes/2015-12-16-webappsec-minutes.html
bhill2: Objections to approving the minutes?
All: <crickets>
bhill2: Approved!
<bhill2> SRI to Proposed Rec
bhill2: Topics for next time? Maybe the CORS thing if we don't have time today.
<bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2016Jan/0020.html
bhill2: SRI to PR?
... Objections to moving ahead?
all: <crickets>
bhill2: Huzzah. Approved, I'll send the transition request.
<bhill2> Mixed Content to Proposed Rec
<bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2016Jan/0021.html
bhill2: Might have been a bit
premature.
... Only one implementation of `block-all-mixed-content`.
... Is it worth bothering to do that and
`upgrade-insecure-requests`?
... Will produce less breakage.
... Hours away from turning on `block-all-mixed-content` for FB
employees because I want to surface breakage early.
... Upgrade might hide that kind of breakage. I don't want to
hide it.
... That's a development scenario, not a production
scenario.
... Might not be worth implementing.
... It seems like it's the future, though, so maybe it's nice
to let folks opt into that world.
... Mozilla folks?
tanvi: I brought this up.
... The FB scenario isn't something we've thought about.
... Other than that, I don't see the use cases.
<bhill2> mkwst: there are projects inside google planning to turn this on as a "strict mode", want to make sure they don't have http content
<bhill2> ... appealing to have strict vs. a transient upgrade mode
<bhill2> ... understand notion they are similar in nature, one is like a subset of the other
<bhill2> ... not everyone may see different use cases
tanvi: Couldn't you do this with CSP?
<bhill2> mkwst: doesn't cascade into frames
tanvi: Dan?
dveditz: I thought we had
implemented it. :)
... I don't see why we wouldn't, but I don't feel strongly
about it.
tanvi: I'll take this back to the
team, and report back.
... In the meantime, what do we do about CR/PR?
bhill2: Feature at risk without 2
implementations, I'll object to my own CfC.
... We'll wait. Waiting is fun. We like waiting.
... I would rather hear "No" from Mozilla so we can start the
process of removing it, as there's some exciting IPR process
there.
... "Probably" is a particularly bad answer.
... Certainty would be nice.
mkwst: Reporting requirements? Currently none. Might be useful enough to be a requirement.
bhill2: Would be great to have. Probably not essential for PR. I'd settle for things breaking.
tanvi: Cascade makes reporting interesting.
<bhill2> tanvi: one issue is when it cascades into frames - be reporting on foreign content
<bhill2> dveditz: can treat it like we do redirects
<bhill2> CSP3 to FPWD
<bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2016Jan/0034.html
<bhill2> UI Security - new major editors' draft
<bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2015Dec/0024.html
bhill2: Expires Friday. Might be
a good time to read CSP3.
... Would like feedback on UI Security before issuing a CfC to
FPWD.
... Please read, and tell the group about it.
... Let's move Referrer Policy up.
<teddink> Apologies for my tardiness - dialing in now.
jochen: Quick update. We hammered
out `referrerpolicy` attribute on <a> and
<img>.
... Need to update published draft.
... We're missing spec tests for that feature.
... Requests for other elements as well. <link> for
instance.
... Referrer policy delivered via CSP. Ran into some issues
with things like redirects.
... Now looking into a dedicated `Referrer-Policy` header which
has clearly defined behavior in cases like this.
dveditz: Do you mean that redirects could change the policy as you redirect?
jochen: Consider `t.co`: if you
go through that page, the default policy applies.
... We need to deliver the policy together with the
response.
dveditz: Why wouldn't you carry the original policy through the redirect chain?
jochen: What if you enter a URL
into the address bar? No original policy.
... That forces default policy.
dveditz: If there is a policy, we need to decide which policy wins, right?
jochen: If you do a client-side
redirect (e.g. load the page, then navigate yourself) you also
get to choose the policy. We should take that into
account.
... Ok.
... Still open: `ping-from` needs referrer policy
definition.
... CSS's integration with Fetch is poorly defined.
... Will need to work with that group to understand/define the
integration.
estark: One more open issue: JSON
syntax for the `referrer-policy` header, maybe?
... Initially specced as a string, but maybe we want to be more
flexible for the future.
mkwst: One suggestion was to use a quoted string, which would be forward-compatible with a JSON syntax in the future.
<bhill2> mkwst: one suggestion is to use a quoted string vs. bare string which would keep familiar syntax but be forward compatible
estark: I like that idea.
bhill2: When would you like to publish a new working draft?
jochen: Soon. Both Firefox and
Chromium would like to ship the `referrerpolicy` attribute, as
least what we have now.
... Requires spec tests to be present, but we should of course
also update the draft.
bhill2: Two implementations that are going to ship, is it worth calling "level 1" done?
jochen: Anne proposed that we
actually move most of this to the HTML spec. I dunno.
... I'd rather finish the few remaining points and see where we
go from there.
bhill2: Would be good to get a
heartbeat update out, since there are large sites using this in
important ways.
... Reasonable stable spec is good for interop. Should publish
a new WD update.
freddyb: Hi!
... Long list of things we intend to do.
... I think we ought to prioritize integrity policies. Have
some interest inside Mozilla, which is helpful.
... Would require integrity for a certain set of HTML
elements.
... Probably live in a different header, as far as I understood
mnot's comments on the issue.
<francois> GitHub also expressed interested in SRI policies
freddyb: Would probably also want
to support <meta> so we don't require a header.
Interesting for CDNs (GitHub Pages, for instance)
... Other things: adding integrity to other elements.
... That's a bit tricky, since we don't want to block on the
complete download before we do the hashing.
... Still needs research.
... Other things: signatures? public key for a resource?
... Might be other things: jww? francois?
bhill2: Would like to hear from UA implementers about things they're interested in implementing.
jww: From my perspective, I'm
interested in what developers want. Signatures are one big
thing. Downloads another.
... Pretty open to seeing how folks are using SRI in the next
months, and building off of that.
francois: Would echo jww's
comments.
... Important to see what might get adopted before we spec and
implement features.
... We've heard that GitHub wants the policy stuff freddyb
talked about.
... Also heard requests for support for images. Blocks
progressive rendering.
... Might be fine for some use-cases.
... Would be helpful to have feedback from developers.
mkwst: Have you looked at agl's proposal for streaming? Merkle trees, etc? Long time ago.
freddyb: Seems like a good way to go. Don't remember the syntax.
jww: Talked with yoav about
extracting SRI information to a central place in the
page.
... Also. Caching. That's a big topic.
bhill2: Proxy vote on dev's
behalf. He wants signatures. Dropbox is interested.
... Also good to to talk to about streaming syntax, as a
purveyor of large files.
... All interesting cases. I like being driven by developer use
cases. I think these topics are things we've had sporadic
activity on the list now for a long time.
... Would be good to see a little more direction from
editors.
... Pick one or two things to drive a spike through.
... Everyone has their priorities. If you have a good idea of a
direction in which to lead the community, especially one which
you'd implement, please do so.
https://mikewest.github.io/cors-rfc1918/
<bhill2> mkwst: sent out a doc a week ago, premise is that intranet is distinct from internet
<bhill2> ... browser should not give one direct access to the other
<bhill2> ... we've had a formal distinction by RFC 1918 for a decade, haven't acted on it as a browser community
<bhill2> ... large number of devices that believe they exist in a bubble that doesn't include the internet
<bhill2> ... false of course, browser is a confused deputy pivot point between these worlds
<bhill2> ... routers are particularly problematic, history of CSRF attacks
<bhill2> ... also pieces of software hosted on users computer and grant excessive privileges, e.g. yesterday's TrendMicro vuln disclosure
<bhill2> ... tried a year or two w/ Mixed Content to block this
<bhill2> ... treating RFC1918 as mixed content subject to blocking
<jww> freddyb: I'll get back to work on the Bikeshed branch, but it's a little complicated because Dev and Francois (reasonably) requested that I do a pure conversion first without any textual changes, and my current branches has a number of (minor) changes.
<bhill2> ... objected to by developer community and removed
<bhill2> ... would like to revisit by using CORS preflight as an explicit opt-in for intranet resources
<bhill2> ... to talk to internet resources
<freddyb> jww: ah, right.
<bhill2> ... expect a new response granting access based on signalling the network type it is willing to talk to
<bhill2> ... I'm interested in experimenting in Chrome, need to look at network stack to see when and how we know about the network location
<bhill2> ... what I'd like to know is whether this is a problem that the group is interested in addressing
<bhill2> ... and is this mechanism appealing?
<bhill2> wseltzer: thanks for bringing this up, seems interesting to me
<bhill2> ... will need some developer advice because people will say "this breaks my internal development workflow"
<bhill2> ... need ways to do testing of sites and services that show up on intranets in development
<bhill2> mkwst: need to support developers, but we will break things, too
<bhill2> dveditz: have long wanted to do this, initial attempts have been shot down because of breakage
<bhill2> ... maybe we can get past it as a bigger group.
<bhill2> ... RFC1918 is a hack and the problem predates this
<bhill2> ... would be nice if we can open the possibility that UAs can add e.g. enterprise management features to do this more explicitly
<bhill2> mkwst: one piece of feedback is that proxies are an interesting way to do this, e.g. with a PAC file
<bhill2> bhill2: we should ask IE about this - very long history and lots of experience with this kind of thing (zones, proxies, intranet only settings, etc.)
<bhill2> ... maybe ask Eric Lawrence to weigh in
<bhill2> mkwst: also I would like help on how this works with IPv6
<teddink> I can also find folks in Edge (former IE, of course) as needed to help discuss the Zones issues, although Eric is a good resource as well.
<bhill2> mkwst: happy to come back to more complex things once we get the simple ones done
<bhill2> dveditz: from a spec thing would be nice to block the IP, at impl the layers were far apart and made it hard to block
<bhill2> ... and DNS game playing can make this hard to implement, too
<bhill2> dveditz: I believe that Opera did this...
<bhill2> mkwst: they did this in Presto, do not do it today
<bhill2> dveditz: would be interesting to hear feedback from their users
bhill2: Not to let the perfect be
the enemy of the good, but:
... CORS + MIX only halfway blocks this attack.
... The attacks we're interested in can be accomplished with a
redirect or navigation.
... The breakage we'd introduce by blocking navigation might be
large. Much larger than treating it as mixed content.
<bhill2> mkwst: spec intends to cover navigation, that is both a concern and a challenge
dveditz: When we tried it, we
blocked navigations. XHR was one way to do it, redirects were
another.
... That's when we ran into problems where machines in the
intranet...
... For a home user it worked well, more complex cases were
less clearcut.
bhill2: I worry that this would
break SAML and SSO systems.
... I want to go to externalportalformybenitits.com, redirects
internally for token, redirects back out.
<bhill2> mkwst: yes, but hopefully it will be easy for such systems to opt-in
<bhill2> ... an alternative midpoint is to use an interstitial and have the user click OK
<bhill2> ... gives us runway to talk to vendors and get the products fixed
<bhill2> mkwst: I don't see this as a separate spec, I think it would be a note here and actual text would go into Fetch, Websockets, etc. but not be a normative resource here
<teddink> Thanks!