16:44:45 <RRSAgent> RRSAgent has joined #webappsec
16:44:45 <RRSAgent> logging to http://www.w3.org/2016/01/13-webappsec-irc
16:44:47 <trackbot> RRSAgent, make logs world
16:44:47 <Zakim> Zakim has joined #webappsec
16:44:49 <trackbot> Zakim, this will be WASWG
16:44:49 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
16:44:50 <trackbot> Meeting: Web Application Security Working Group Teleconference
16:44:50 <trackbot> Date: 13 January 2016
16:44:53 <wseltzer> wseltzer has changed the topic to: WebAppSec 13 January
16:52:47 <gmaone> gmaone has joined #webappsec
16:58:14 <ckerschb_> ckerschb_ has joined #webappsec
16:58:51 <francois> francois has joined #webappsec
17:00:02 <mkwst> present+ mkwst
17:00:12 <francois> present+ francois
17:00:16 <jww> jww has joined #webappsec
17:00:35 <bhill2> present+ bhill2
17:00:59 <bhill2> bhill2 has changed the topic to: https://lists.w3.org/Archives/Public/public-webappsec/2016Jan/0059.html
17:01:10 <dveditz> present+ dveditz
17:01:23 <jww> present+ jww
17:01:31 <terri> present+ terri
17:01:59 <estark> estark has joined #webappsec
17:02:27 <gmaone> present +gmaone
17:02:35 <jochen> jochen has joined #webappsec
17:02:35 <estark> present +estark
17:02:42 <bhill2> thanks for setting up the meeting, wseltzer
17:02:55 <jochen> can we do referrer policy first please?
17:03:00 <bhill2> sure
17:03:28 <jochen> thx
17:04:11 <ckerschb_> present+ ckerschb
17:04:28 <bhill2> TOPIC: Agenda bashing
17:04:33 <bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2016Jan/0059.html
17:04:36 <jochen> present+ eisinger
17:04:38 <freddyb> present+ freddyb
17:04:43 <mkwst> bhill2: Any suggestions for agenda items?
17:05:16 <mkwst> mkwst: If we have time, we could chat about intranet/internet thing.
17:05:19 <mkwst> bhill2: Ok.
17:05:24 <bhill2> TOPIC: Minutes approval
17:05:29 <bhill2> http://www.w3.org/2011/webappsec/draft-minutes/2015-12-16-webappsec-minutes.html
17:05:41 <mkwst> bhill2: Objections to approving the minutes?
17:05:49 <bhill2> TOPIC: Documents for next teleconference.
17:05:52 <mkwst> All: <crickets>
17:05:55 <mkwst> bhill2: Approved!
17:06:20 <bhill2> TOPIC: Outstanding Calls for Consensus and Comments
17:06:28 <tanvi> tanvi has joined #webappsec
17:06:32 <bhill2> SRI to Proposed Rec
17:06:33 <mkwst> bhill2: Topics for next time? Maybe the CORS thing if we don't have time today.
17:06:38 <bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2016Jan/0020.html
17:06:39 <mkwst> bhill2: SRI to PR?
17:06:46 <mkwst> bhill2: Objections to moving ahead?
17:06:54 <mkwst> all: <crickets>
17:07:04 <mkwst> bhill2: Huzzah. Approved, I'll send the transition request.
17:07:07 <bhill2> Mixed Content to Proposed Rec
17:07:09 <tanvi> present+ tanvi
17:07:16 <bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2016Jan/0021.html
17:07:19 <mkwst> bhill2: Might have been a bit premature.
17:07:28 <mkwst> bhill2: Only one implementation of `block-all-mixed-content`.
17:07:41 <mkwst> bhill2: Is it worth bothering to do that and `upgrade-insecure-requests`?
17:07:49 <mkwst> ... Will produce less breakage.
17:08:14 <mkwst> ... Hours away from turning on `block-all-mixed-content` for FB employees because I want to surface breakage early.
17:08:26 <mkwst> ... Upgrade might hide that kind of breakage. I don't want to hide it.
17:08:37 <mkwst> ... That's a development scenario, not a production scenario.
17:08:41 <mkwst> ... Might not be worth implementing.
17:08:56 <mkwst> ... It seems like it's the future, though, so maybe it's nice to let folks opt into that world.
17:09:02 <mkwst> ... Mozilla folks?
17:09:18 <mkwst> tanvi: I brought this up.
17:09:26 <mkwst> ... The FB scenario isn't something we've thought about.
17:09:33 <mkwst> ... Other than that, I don't see the use cases.
17:10:08 <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
17:10:18 <bhill2> ... appealing to have strict vs. a transient upgrade mode
17:10:29 <bhill2> ... understand notion they are similar in nature, one is like a subset of the other
17:10:41 <bhill2> ... not everyone may see different use cases
17:10:41 <mkwst> tanvi: Couldn't you do this with CSP?
17:11:01 <bhill2> mkwst: doesn't cascade into frames
17:11:09 <mkwst> tanvi: Dan?
17:11:18 <mkwst> dveditz: I thought we had implemented it. :)
17:11:26 <mkwst> ... I don't see why we wouldn't, but I don't feel strongly about it.
17:11:33 <mkwst> tanvi: I'll take this back to the team, and report back.
17:11:41 <mkwst> ... In the meantime, what do we do about CR/PR?
17:11:56 <mkwst> bhill2: Feature at risk without 2 implementations, I'll object to my own CfC.
17:12:03 <mkwst> ... We'll wait. Waiting is fun. We like waiting.
17:12:42 <mkwst> ... I would rather hear "No" from Mozilla so we can start the process of removing it, as there's some exciting IPR process there.
17:13:19 <mkwst> ... "Probably" is a particularly bad answer.
17:13:25 <mkwst> ... Certainty would be nice.
17:14:35 <mkwst> mkwst: Reporting requirements? Currently none. Might be useful enough to be a requirement.
17:15:04 <mkwst> bhill2: Would be great to have. Probably not essential for PR. I'd settle for things breaking.
17:15:35 <mkwst> tanvi: Cascade makes reporting interesting.
17:15:37 <bhill2> tanvi: one issue is when it cascades into frames - be reporting on foreign content
17:15:59 <bhill2> dveditz: can treat it like we do redirects
17:16:19 <bhill2> CSP3 to FPWD
17:16:28 <bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2016Jan/0034.html
17:16:52 <bhill2> UI Security - new major editors' draft
17:16:58 <bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2015Dec/0024.html
17:16:59 <mkwst> bhill2: Expires Friday. Might be a good time to read CSP3.
17:17:18 <mkwst> ... Would like feedback on UI Security before issuing a CfC to FPWD.
17:17:21 <teddink> teddink has joined #webappsec
17:17:28 <mkwst> ... Please read, and tell the group about it.
17:17:31 <tanvi> zakim, who is here?
17:17:31 <Zakim> Present: mkwst, francois, bhill2, dveditz, jww, terri, ckerschb, eisinger, freddyb, tanvi
17:17:33 <Zakim> On IRC I see teddink, tanvi, jochen, estark, jww, francois, ckerschb_, gmaone, Zakim, RRSAgent, bhill2, yoav, freddyb, mounir, tobie, timeless, Josh_Soref, dveditz, slightlyoff,
17:17:33 <Zakim> ... mkwst, terri, schuki, Mek, xiaoqian, trackbot, wseltzer
17:17:36 <mkwst> ... Let's move Referrer Policy up.
17:17:37 <bhill2> TOPIC: Referrer Policy
17:17:51 <teddink> Apologies for my tardiness - dialing in now.
17:17:58 <mkwst> jochen: Quick update. We hammered out `referrerpolicy` attribute on <link> and <img>.
17:18:09 <mkwst> ... Need to update published draft.
17:18:22 <mkwst> ... We're missing spec tests for that feature.
17:18:34 <mkwst> s/<link>/<a>/
17:18:47 <mkwst> ... Requests for other elements as well. <link> for instance.
17:19:10 <mkwst> ... Referrer policy delivered via CSP. Ran into some issues with things like redirects.
17:19:28 <mkwst> ... Now looking into a dedicated `Referrer-Policy` header which has clearly defined behavior in cases like this.
17:19:40 <mkwst> dveditz: Do you mean that redirects could change the policy as you redirect?
17:19:57 <mkwst> jochen: Consider `t.co`: if you go through that page, the default policy applies.
17:20:13 <mkwst> ... We need to deliver the policy together with the response.
17:20:34 <mkwst> dveditz: Why wouldn't you carry the original policy through the redirect chain?
17:20:48 <mkwst> jochen: What if you enter a URL into the address bar? No original policy.
17:21:02 <mkwst> ... That forces default policy.
17:21:13 <mkwst> dveditz: If there is a policy, we need to decide which policy wins, right?
17:21:38 <mkwst> 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.
17:21:52 <mkwst> ... Ok.
17:22:08 <mkwst> ... Still open: `ping-from` needs referrer policy definition.
17:22:24 <wseltzer> present+ wseltzer
17:22:29 <mkwst> ... CSS's integration with Fetch is poorly defined.
17:22:44 <mkwst> ... Will need to work with that group to understand/define the integration.
17:23:01 <mkwst> estark: One more open issue: JSON syntax for the `referrer-policy` header, maybe?
17:23:12 <mkwst> ... Initially specced as a string, but maybe we want to be more flexible for the future.
17:23:56 <mkwst> mkwst: One suggestion was to use a quoted string, which would be forward-compatible with a JSON syntax in the future.
17:23:56 <bhill2> mkwst: one suggestion is to use a quoted string vs. bare string which would keep familiar syntax but be forward compatible
17:24:03 <mkwst> estark: I like that idea.
17:24:12 <mkwst> bhill2: When would you like to publish a new working draft?
17:24:40 <mkwst> jochen: Soon. Both Firefox and Chromium would like to ship the `referrerpolicy` attribute, as least what we have now.
17:24:50 <mkwst> ... Requires spec tests to be present, but we should of course also update the draft.
17:25:06 <mkwst> bhill2: Two implementations that are going to ship, is it worth calling "level 1" done?
17:25:24 <mkwst> jochen: Anne proposed that we actually move most of this to the HTML spec. I dunno.
17:25:42 <mkwst> ... I'd rather finish the few remaining points and see where we go from there.
17:25:58 <mkwst> bhill2: Would be good to get a heartbeat update out, since there are large sites using this in important ways.
17:27:05 <mkwst> ... Reasonable stable spec is good for interop. Should publish a new WD update.
17:27:15 <bhill2> TOPIC: Subresource Integrity - starting work on Level 2
17:27:48 <mkwst> freddyb: Hi!
17:27:53 <mkwst> ... Long list of things we intend to do.
17:28:19 <mkwst> ... I think we ought to prioritize integrity policies. Have some interest inside Mozilla, which is helpful.
17:28:29 <mkwst> ... Would require integrity for a certain set of HTML elements.
17:28:46 <mkwst> ... Probably live in a different header, as far as I understood mnot's comments on the issue.
17:28:47 <francois> GitHub also expressed interested in SRI policies
17:29:13 <mkwst> ... Would probably also want to support <meta> so we don't require a header. Interesting for CDNs (GitHub Pages, for instance)
17:29:24 <mkwst> ... Other things: adding integrity to other elements.
17:29:37 <mkwst> ... That's a bit tricky, since we don't want to block on the complete download before we do the hashing.
17:29:41 <mkwst> ... Still needs research.
17:29:58 <mkwst> ... Other things: signatures? public key for a resource?
17:30:13 <mkwst> ... Might be other things: jww? francois?
17:30:41 <mkwst> bhill2: Would like to hear from UA implementers about things they're interested in implementing.
17:31:00 <mkwst> jww: From my perspective, I'm interested in what developers want. Signatures are one big thing. Downloads another.
17:31:14 <mkwst> ... Pretty open to seeing how folks are using SRI in the next months, and building off of that.
17:31:20 <mkwst> francois: Would echo jww's comments.
17:31:31 <mkwst> ... Important to see what might get adopted before we spec and implement features.
17:31:42 <mkwst> ... We've heard that GitHub wants the policy stuff freddyb talked about.
17:32:02 <mkwst> ... Also heard requests for support for images. Blocks progressive rendering.
17:32:08 <mkwst> ... Might be fine for some use-cases.
17:32:20 <mkwst> ... Would be helpful to have feedback from developers.
17:33:03 <mkwst> mkwst: Have you looked at agl's proposal for streaming? Merkle trees, etc? Long time ago.
17:33:17 <mkwst> freddyb: Seems like a good way to go. Don't remember the syntax.
17:34:11 <mkwst> jww: Talked with yoav about extracting SRI information to a central place in the page.
17:34:20 <mkwst> jww: Also. Caching. That's a big topic.
17:34:49 <mkwst> bhill2: Proxy vote on dev's behalf. He wants signatures. Dropbox is interested.
17:35:04 <mkwst> ... Also good to to talk to about streaming syntax, as a distributor of large files.
17:35:23 <mkwst> s/distributor/purveyor/
17:35:57 <mkwst> bhill2: 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.
17:36:04 <mkwst> ... Would be good to see a little more direction from editors.
17:36:15 <mkwst> ... Pick one or two things to drive a spike through.
17:36:48 <mkwst> ... 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.
17:37:27 <mkwst> https://mikewest.github.io/cors-rfc1918/
17:37:37 <bhill2> TOPIC: opt-in CORS-like policy for intranet/internet bridging requests
17:37:49 <bhill2> mkwst: sent out a doc a week ago, premise is that intranet is distinct from internet
17:37:55 <bhill2> ... browser should not give one direct access to the other
17:38:16 <bhill2> ... we've had a formal distinction by RFC 1918 for a decade, haven't acted on it as a browser community
17:38:32 <bhill2> ... large number of devices that believe they exist in a bubble that doesn't include the internet
17:38:43 <bhill2> ... false of course, browser is a confused deputy pivot point between these worlds
17:38:55 <bhill2> ... routers are particularly problematic, history of CSRF attacks
17:39:19 <bhill2> ... also pieces of software hosted on users computer and grant excessive privileges, e.g. yesterday's TrendMicro vuln disclosure
17:39:34 <bhill2> ... tried a year or two w/ Mixed Content to block this
17:39:45 <bhill2> ... treating RFC1918 as mixed content subject to blocking
17:39:58 <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.
17:40:00 <bhill2> ... objected to by developer community and removed
17:40:18 <bhill2> ... would like to revisit by using CORS preflight as an explicit opt-in for intranet resources
17:40:23 <bhill2> ... to talk to internet resources
17:40:29 <freddyb> jww: ah, right.
17:40:54 <bhill2> ... expect a new response granting access based on signalling the network type it is willing to talk to
17:41:06 <wseltzer> q+
17:41:26 <dveditz> q+
17:41:27 <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
17:41:47 <bhill2> ... what I'd like to know is whether this is a problem that the group is interested in addressing
17:41:53 <bhill2> ... and is this mechanism appealing?
17:41:57 <bhill2> ack wseltzer
17:42:08 <bhill2> wseltzer: thanks for bringing this up, seems interesting to me
17:42:27 <bhill2> ... will need some developer advice because people will say "this breaks my internal development workflow"
17:42:42 <bhill2> ... need ways to do testing of sites and services that show up on intranets in development
17:43:00 <bhill2> mkwst: need to support developers, but we will break things, too
17:43:13 <bhill2> q+
17:43:25 <bhill2> ack dveditz
17:43:48 <bhill2> dveditz: have long wanted to do this, initial attempts have been shot down because of breakage
17:43:56 <bhill2> ... maybe we can get past it as a bigger group.
17:44:05 <bhill2> ... RFC1918 is a hack and the problem predates this
17:44:36 <bhill2> ... would be nice if we can open the possibility that UAs can add e.g. enterprise management features to do this more explicitly
17:44:53 <bhill2> mkwst: one piece of feedback is that proxies are an interesting way to do this, e.g. with a PAC file
17:45:51 <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.)
17:46:00 <bhill2> ... maybe ask Eric Lawrence to weigh in
17:46:13 <bhill2> mkwst: also I would like help on how this works with IPv6
17:46:23 <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.
17:47:09 <bhill2> mkwst: happy to come back to more complex things once we get the simple ones done
17:47:46 <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
17:48:23 <bhill2> ... and DNS game playing can make this hard to implement, too
17:48:56 <bhill2> dveditz: I believe that Opera did this...
17:49:09 <bhill2> mkwst: they did this in Presto, do not do it today
17:49:37 <bhill2> dveditz: would be interesting to hear feedback from their users
17:49:49 <bhill2> q?
17:49:59 <bhill2> ack bhill
17:50:12 <mkwst> bhill2: Not to let the perfect be the enemy of the good, but:
17:50:34 <mkwst> ... CORS + MIX only halfway blocks this attack.
17:50:56 <mkwst> ... The attacks we're interested in can be accomplished with a redirect or navigation.
17:51:20 <dveditz> q+
17:51:24 <mkwst> ... The breakage we'd introduce by blocking navigation might be large. Much larger than treating it as mixed content.
17:51:49 <bhill2> mkwst: spec intends to cover navigation, that is both a concern and a challenge
17:52:04 <mkwst> dveditz: When we tried it, we blocked navigations. XHR was one way to do it, redirects were another.
17:52:16 <mkwst> ... That's when we ran into problems where machines in the intranet...
17:52:31 <mkwst> ... For a home user it worked well, more complex cases were less clearcut.
17:52:39 <mkwst> bhill2: I worry that this would break SAML and SSO systems.
17:53:03 <mkwst> ... I want to go to externalportalformybenitits.com, redirects internally for token, redirects back out.
17:54:29 <bhill2> mkwst: yes, but hopefully it will be easy for such systems to opt-in
17:54:47 <bhill2> ... an alternative midpoint is to use an interstitial and have the user click OK
17:54:56 <bhill2> ... gives us runway to talk to vendors and get the products fixed
17:55:55 <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
17:56:57 <teddink> Thanks!
17:57:03 <bhill2> zakim, list attendees
17:57:03 <Zakim> As of this point the attendees have been mkwst, francois, bhill2, dveditz, jww, terri, ckerschb, eisinger, freddyb, tanvi, wseltzer
17:57:10 <bhill2> rrsagent, make minutes
17:57:10 <RRSAgent> I have made the request to generate http://www.w3.org/2016/01/13-webappsec-minutes.html bhill2
17:57:15 <bhill2> rrsagent, set logs public-visible
17:57:18 <freddyb> bye :-)
17:57:32 <ckerschb_> ckerschb_ has left #webappsec
18:06:06 <bhill2> bhill2 has joined #webappsec
18:06:29 <bhill2> bhill2 has joined #webappsec