20:49:10 <RRSAgent> RRSAgent has joined #webappsec
20:49:10 <RRSAgent> logging to http://www.w3.org/2013/08/13-webappsec-irc
20:49:13 <Zakim> Zakim has joined #webappsec
20:49:23 <bhill2> zakim, this will be 92794
20:49:23 <Zakim> ok, bhill2; I see SEC_WASWG()5:00PM scheduled to start in 11 minutes
20:49:30 <bhill2> rrsagent, set logs public visible
20:49:52 <bhill2> Meeting: WebAppSec WG Teleconference, 13-Aug-2013
20:49:57 <bhill2> Chair: bhill2, ekr
20:50:15 <bhill2> Agenda: http://lists.w3.org/Archives/Public/public-webappsec/2013Aug/0032.html
20:56:51 <Zakim> SEC_WASWG()5:00PM has now started
20:56:53 <Zakim> + +49.898.393.0.aaaa
20:57:11 <neilm> neilm has joined #webappsec
20:57:19 <gmaone> gmaone has joined #webappsec
20:58:00 <Zakim> + +1.303.229.aabb
20:58:01 <Zakim> - +1.303.229.aabb
20:58:01 <Zakim> + +1.303.229.aabb
20:58:06 <bhill2> zakim, aabb is bhill2
20:58:06 <Zakim> +bhill2; got it
20:58:28 <bhill2> zakim, aaaa is mkwst_
20:58:28 <Zakim> +mkwst_; got it
21:00:25 <Zakim> +neilm
21:00:51 <wseltzer> regrets+ Wseltzer
21:01:06 <Zakim> +[Google]
21:01:42 <bhill2> wendy, is that a joke, or have you recently moved?
21:01:54 <dveditz> dveditz has joined #webappsec
21:02:35 <Zakim> +??P4
21:02:50 <gmaone> Zakim, ??P4 is gmaone
21:02:50 <Zakim> +gmaone; got it
21:02:53 <Zakim> -neilm
21:03:14 <Zakim> +neilm
21:03:25 <wseltzer> bhill2, I just moved, and my "11 am" Verizon appointment turned into 4:30 pm
21:03:37 <Zakim> +[Mozilla]
21:03:54 <bhill2> zakim, Mozilla has tanvi and garrettR
21:03:54 <Zakim> +tanvi, garrettR; got it
21:04:02 <Zakim> +[Mozilla.a]
21:04:12 <grobinson> grobinson has joined #webappsec
21:04:16 <tanvi> tanvi has joined #webappsec
21:04:22 <tanvi> Zakim, who is here?
21:04:22 <Zakim> On the phone I see mkwst_, bhill2, [Google], gmaone, neilm, [Mozilla], [Mozilla.a]
21:04:24 <Zakim> [Mozilla] has tanvi, garrettR
21:04:24 <Zakim> On IRC I see tanvi, grobinson, dveditz, gmaone, neilm, Zakim, RRSAgent, bhill2, bhill, jeffh, timeless, trackbot, mkwst_, odinho, tlr, wseltzer
21:04:31 <bhill2> zakim, Google has DaneshIrani
21:04:31 <Zakim> +DaneshIrani; got it
21:04:40 <Zakim> + +1.415.596.aacc
21:04:58 <ekr> ekr has joined #webappsec
21:04:58 <bhill2> zakim, aacc is puhley
21:04:58 <Zakim> +puhley; got it
21:05:04 <ekr> zakim, who is here?
21:05:04 <Zakim> On the phone I see mkwst_, bhill2, [Google], gmaone, neilm, [Mozilla], [Mozilla.a], puhley
21:05:06 <Zakim> [Google] has DaneshIrani
21:05:07 <Zakim> [Mozilla] has tanvi, garrettR
21:05:07 <Zakim> On IRC I see ekr, tanvi, grobinson, dveditz, gmaone, neilm, Zakim, RRSAgent, bhill2, bhill, jeffh, timeless, trackbot, mkwst_, odinho, tlr, wseltzer
21:05:15 <ekr> I am not sure if I am Mozilla or Mozilla.a
21:05:17 <ekr> Doubt it matters
21:05:22 <bhill2> agenda: http://lists.w3.org/Archives/Public/public-webappsec/2013Aug/0032.html
21:05:26 <bhill2> zakim, Mozilla.a has ekr
21:05:26 <Zakim> +ekr; got it
21:05:51 <puhley> puhley has joined #webappsec
21:07:01 <Zakim> +[IPcaller]
21:07:17 <bhill2> zakim IPcaller is dveditz
21:07:22 <dveditz> thx
21:07:24 <bhill2> zakim, IPcaller is devditz
21:07:24 <Zakim> +devditz; got it
21:07:27 <bhill2> argh
21:07:37 <jww_and_abarth> jww_and_abarth has joined #webappsec
21:07:58 <bhill2> scribenick: mkwst_
21:08:04 <jww_and_abarth> We're trying to dial in but are being told that our pin is invalid. Anyone else having trouble?
21:08:13 <bhill2> 92794
21:08:22 <bhill2> zakim, who is here?
21:08:22 <Zakim> On the phone I see mkwst_, bhill2, [Google], gmaone, neilm, [Mozilla], [Mozilla.a], puhley, devditz
21:08:24 <Zakim> [Google] has DaneshIrani
21:08:24 <Zakim> [Mozilla] has tanvi, garrettR
21:08:24 <Zakim> [Mozilla.a] has ekr
21:08:24 <Zakim> On IRC I see jww_and_abarth, puhley, ekr, tanvi, grobinson, dveditz, gmaone, neilm, Zakim, RRSAgent, bhill2, bhill, jeffh, timeless, trackbot, mkwst_, odinho, tlr, wseltzer
21:08:29 <bhill2> we should still have a few lines available
21:08:33 <Zakim> +Adam
21:09:06 <jww_and_abarth> okay, seems like we're dialed in via Adam's cell
21:09:14 <bhill2> zakim, Adam has jww
21:09:14 <Zakim> +jww; got it
21:09:34 <bhill2> Topic: Agenda Approval
21:09:40 <bhill2> http://www.w3.org/2013/07/16-webappsec-minutes.html
21:09:51 <mkwst_> bhill2: Approve minutes?
21:09:55 <mkwst_> bhill2: Approved!
21:10:04 <bhill2> Topic: Action items in tracker
21:10:09 <bhill2> https://www.w3.org/2011/webappsec/track/actions/open?sort=owner
21:10:14 <Danesh> Danesh has joined #webappsec
21:10:33 <mkwst_> bhill2: ACTION-141, abarth.
21:10:49 <mkwst_> abarth: Talked to Anne. Don't quite see eye-to-eye.
21:10:57 <mkwst_> abarth: Issues around workers.
21:11:03 <mkwst_> abarth: Will discuss further.
21:11:14 <mkwst_> bhill2: ACTION-143, erorr handling behavior.
21:11:37 <mkwst_> abarth: not yet.
21:11:53 <mkwst_> bhill2: ACTION-144
21:12:00 <mkwst_> abarth: Same as ACTION-141, blocking 141.
21:12:21 <mkwst_> bhill2: ACTION-145, done?
21:12:25 <mkwst_> abarth: Done!
21:12:33 <neilm> neilm has joined #webappsec
21:12:34 <bhill2> trackbot CLOSE ACTION-145
21:12:34 <trackbot> Closed ACTION-145.
21:12:52 <Zakim> +[GVoice]
21:12:55 <Zakim> -Adam
21:12:56 <mkwst_> bhill2: ACTION-124, did that yesterday.
21:13:14 <mkwst_> bhill2: New repository next to the CSP one for CORS (on GitHub).
21:13:32 <mkwst_> bhill2: Added tests for various statuses that should be treated as success.
21:14:08 <mkwst_> bhill2: 308 is implemented interoperably, as well as 20x codes.
21:14:09 <neilm_> neilm_ has joined #webappsec
21:14:11 <bhill2> trackbot CLOSE ACTION-124
21:14:11 <trackbot> Closed ACTION-124.
21:14:17 <mkwst_> bhill2: Look good to go for moving to PR.
21:14:28 <mkwst_> bhill2: Leave next two open.
21:14:41 <bhill2> trackbot CLOSE ACTION-147
21:14:41 <trackbot> Closed ACTION-147.
21:14:42 <mkwst_> bhill2: neilm proposed hash text to the list, done.
21:15:38 <mkwst_> bhill2: ACTION-135, probably not going to happen. troessler is moving from the W3C to Google.
21:15:40 <bhill2> trackbot CLOSE ACTION-135
21:15:40 <trackbot> Closed ACTION-135.
21:15:47 <mkwst_> bhill2: troessler is amazing, btw.
21:17:17 <mkwst_> bhill2: dveditz and mwest haven't done their work.
21:17:33 <bhill2> action to bhill2 get patent release on referer control proposal from LAFS authors
21:17:33 <trackbot> Error finding 'to'. You can review and register nicknames at <http://www.w3.org/2011/webappsec/track/users>.
21:17:34 <mkwst_> mikew: Do I need to wait for the referrer policy to be proposed on the list?
21:17:46 <bhill2> action bhill2 get patent release on referer control proposal from LAFS authors
21:17:47 <trackbot> Created ACTION-148 - Get patent release on referer control proposal from lafs authors [on Brad Hill - due 2013-08-20].
21:17:52 <mkwst_> bhill2: I'll follow up with them to ensure they propose it under the patent policy.
21:18:16 <mkwst_> bhill2: Agenda bashing.
21:18:48 <mkwst_> bhill2: Anything?
21:18:59 <mkwst_> mikew: Maybe the stack stuff re: the JavaScript API?
21:19:03 <bhill2> Topic: New script hash proposal
21:19:04 <bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Aug/0031.html
21:19:06 <mkwst_> bhill2: Sure, we can touch on that.
21:19:40 <mkwst_> neilm: Has anyone had a chance to look at the proposal?
21:19:51 <mkwst_> bhill2: Might have been simpler not as a diff.
21:20:08 <mkwst_> neilm: Ok. I think I addressed all the comments that came up, and went against some of the choices we made.
21:20:34 <mkwst_> neilm: Willing to discuss each and all of them. UTF-8, for instance.
21:20:53 <mkwst_> neilm: All valid JavaScript code falls into UTF-8, anything else is data, and shouldn't be in a script tag.
21:21:31 <mkwst_> abarth: Issue in DOM Core. the contents of the script tag are represented as a sequence of ... ?
21:21:44 <mkwst_> abarth: not all those sequences can be represented in utf-8.
21:21:55 <mkwst_> abarth: if you do that, you'd always fail the hashes, which is fine with me.
21:22:07 <mkwst_> abarth: think of it as a pipeline.
21:22:27 <mkwst_> abarth: bites on a wire. encoding document is in transcode those bytes into code points.
21:22:44 <mkwst_> abarth: put those code points into the DOM, where they're just a string of 8 bit items.
21:22:57 <mkwst_> abarth: javascript can screw with those items as will.
21:23:02 <mkwst_> abarth: weird edge case.
21:23:27 <mkwst_> abarth: might be able to simply say that those don't run if we use hashing.
21:23:39 <mkwst_> dveditz: one script modifies another before it's hashed?
21:23:59 <mkwst_> abarth: script is half-represented in the dom before execution. another script can manipulate before execution.
21:24:48 <mkwst_> abarth: using utf-8 is fine. just say that if the thing you're checking fails to decode as utf-8, it should autofail the hash test.
21:25:16 <mkwst_> deveditz: only perform the hash after the script is in the DOM? not the literal bytes?
21:25:28 <mkwst_> abarth: there's a moment in the spec where the script is executed.
21:25:40 <mkwst_> abarth: at that moment, we'd want to capture the data in the DOM and check the hash.
21:25:56 <mkwst_> neilm: I offered a bytes on the wire option.
21:26:01 <mkwst_> abarth: that's hard.
21:26:33 <mkwst_> abarth: bytes stream slowly, half-built tag. just data in the dom that can be manipulated, which means that what you execute might not be what you got over the wire.
21:26:53 <mkwst_> neilm: might also be easier for developers if we use the DOM representation.
21:27:03 <mkwst_> abarth: replacement characters, for example.
21:27:36 <mkwst_> neilm: proposed only supporting SHA-256.
21:27:59 <mkwst_> neilm: crypto agility is a problem, but maybe not a big enough problem to override the simplicity.
21:28:13 <mkwst_> neilm: rfc6920, no truncation, drop content-type.
21:29:01 <mkwst_> neilm: if you're producing dynamic javascript, we can't save you. might be reasonable to allow truncation.
21:29:32 <mkwst_> ???: regarding agility, perhaps SHA-256 at minimum?
21:29:55 <mkwst_> ???: "Support this as a minimum, perhaps in the future support something better."
21:30:08 <bhill2> who was speaking before ekr?
21:30:13 <mkwst_> ekr: mistake not to support some kind of agility
21:30:25 <mkwst_> dveditz: syntax needs to be extensible.
21:30:39 <mkwst_> neilm: syntax is extensible, lots of complexity with multiple hashes.
21:30:47 <mkwst_> neilm: matches one hash but not the other, etc.
21:30:58 <mkwst_> neilm: perhaps only support only one hash type per policy?
21:31:01 <mkwst_> tanvi: makes sense.
21:31:22 <mkwst_> dveditz: what happens if the policy specifies a hash that the user agent can't deal with?
21:31:37 <mkwst_> neilm: fail closed. if you can't support it, you can't validate it, and you can't execute it.
21:32:02 <mkwst_> bhill2: CDN + developers = multiple hashes in a policy is likely to happen in the wild.
21:32:18 <mkwst_> dveditz: how do multiple headers work?
21:32:34 <mkwst_> dveditz: match each policy? in that case, we'd fail one of the policies.
21:33:09 <mkwst_> dveditz: at least if we're trying to shoehorn this into script-src.
21:33:36 <mkwst_> bhill2: how to deal with unsafe-inline and script-hash?
21:33:50 <mkwst_> bhill2: does a different directive name make that easier to deal with?
21:34:25 <mkwst_> ???: source expression has a lot of benefits. is a clear representation.
21:34:37 <mkwst_> dveditz: we do have to worry about forwards compat.
21:35:14 <mkwst_> neilm: if there's a hash, we'd discard unsafe-inline in browsers that support that.
21:35:20 <mkwst_> dveditz: two headers?
21:35:32 <mkwst_> abarth: per-policy basis.
21:35:56 <mkwst_> abarth: for a given policy, we'd ignore unsafe-inline if nonce/hash is present.
21:36:02 <mkwst_> ???: <echo>
21:37:00 <mkwst_> ???: if hashes/nonces only whitelist inline resources, then there's no usecase. if they can annotate external resources, then there's a usecase.
21:37:50 <mkwst_> mwest: nonces are useful for passing ability to inject script to third parties.
21:38:15 <mkwst_> tanvi: script hash might be useful for external content. may want to ensure that the script you're pulling is the script you thought it was.
21:38:29 <mkwst_> dveditz: is the web ever going to have a content integrity spec?
21:38:57 <mkwst_> dveditz: perhaps we should simply do that rather than making script-hash do that work.
21:39:11 <mkwst_> bhill2: we have that in our charter.
21:39:27 <mkwst_> bhill2: start simple, would suggest to kill unsafe-inline when hash/nonce is present.
21:39:41 <mkwst_> dveditz: still juggling nonce and hash.
21:40:05 <mkwst_> bhill2: strong preference to do only one. hash seems to have more going for it.
21:40:15 <mkwst_> bhill2: will need a more formal CfC.
21:40:44 <mkwst_> dveditz: hash is more verbose. nonce is easier to screw up (forgetting to randomize, reusing), does make it possible to pass capability to third-party.
21:41:06 <mkwst_> dveditz: they only have to be passed the nonce, rather than them passing the hashes to you.
21:41:18 <mkwst_> abarth: settle on a script-hash proposal, implement it, see if folks like it.
21:41:35 <mkwst_> abarth: users like twitter can give us feedback. twitter sounds like it would prefer hashes.
21:41:44 <mkwst_> abarth: google has some internal customers that we could also ask.
21:41:52 <mkwst_> neilm: would love to experiment.
21:42:14 <mkwst_> abarth: i worry that hashing looks great, but will be difficult to implement, bloat headers, etc.
21:42:25 <mkwst_> abarth: would be good to experiment to see how it works in the real world.
21:42:40 <mkwst_> bhill2: moving on, let's skip to suborigin proposal.
21:42:46 <bhill2> Topic: Suborigins Proposal
21:42:47 <bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Aug/0020.html
21:42:48 <mkwst_> jww: hi!
21:43:05 <mkwst_> jww: suborigin policy.
21:43:35 <mkwst_> jww: idea is to add a primitive to the browser to allow hosts to separate origins to compartmentalize their applications.
21:43:41 <mkwst_> jww: per-page suborigins.
21:43:52 <mkwst_> jww: http response header will give you the name of a suborigin.
21:44:01 <mkwst_> jww: 4th component of a traditional origin.
21:44:20 <mkwst_> jww: could be a CSP directive, could be a separate header.
21:44:39 <mkwst_> jww: suborigins can communicate with other origins via CORS or postMessage.
21:44:52 <mkwst_> jww: no permissions that a normal page would have. similar to an iframe sandbox.
21:45:17 <mkwst_> jww: same set of limited things they could access, but named, so easy to communciate with.
21:45:27 <mkwst_> jww: could add permissions over time if that makes sense.
21:45:56 <mkwst_> jww: document online: http://www.chromium.org/developers/design-documents/per-page-suborigins
21:46:09 <mkwst_> tanvi: would adding a name to a sandbox solve the problem?
21:46:31 <mkwst_> abarth: outer page can force a sandbox. don't want outer page to be able to name the suborigin.
21:46:48 <mkwst_> jww: only way to enter a sandbox is via an http header. server only.
21:46:59 <mkwst_> dveditz: would have to not honor it if in a meta tag.
21:47:41 <mkwst_> bhill2: alternative strawman, sandbox directive ... <echo>.
21:48:25 <mkwst_> bhill2: concern with suborigin is that it's an additional string. flash, java, plugins, and http that isn't the DOM don't respect it.
21:49:09 <mkwst_> bhill2: might be able to solve it in a different way that doesn't break plugins' expectations.
21:49:36 <mkwst_> bhill2: new field changes expectations for existing projects.
21:50:05 <mkwst_> jww: 1. plugins and etc. don't know about suborigins. that's why we're starting off without plugins in the suborigin (similar to sandbox).
21:50:57 <mkwst_> jww: 2. we talked about wedging suborigin into the origin as it stands. afraid of how this would (from a UX perspective) work in the address bar for instance.
21:51:17 <mkwst_> jww: could inadvertently expose to the user, which they wouldn't understand.
21:51:56 <mkwst_> bhill2: sandbox origin is never exposed to the user.
21:52:05 <mkwst_> tanvi: would cookies be extended to have a suborigin flag?
21:52:24 <mkwst_> jww: we said no cookies in the suborigin, would have to communicate with main origin to get cookies.
21:52:48 <mkwst_> dveditz: cookies are tricky. if you don't honor cookies, things will break.
21:53:06 <mkwst_> abarth: cookie http header != document.cookie JavaScript API.
21:53:27 <mkwst_> abarth: iframe sandbox still sends HTTP header. javascript API is blocked.
21:53:34 <mkwst_> abarth: something like that might make sense here too.
21:53:46 <mkwst_> tanvi: cookies specific to suborigin?
21:53:57 <mkwst_> dveditz: already don't follow same-origin policy.
21:54:40 <mkwst_> mwest: cookies sent with request, can't determine that beforehand if the page would respond with a suborigin.
21:54:53 <mkwst_> abarth: similar to sandbox. just adds ability to name the sandbox.
21:55:37 <mkwst_> mwest: that's valuable. was only able to do something similar with message ports. suborigin seems cleaner.
21:55:52 <mkwst_> tanvi: browser would treat request as same-origin, right?
21:56:23 <mkwst_> tanvi: cookie sent, treated as that origin.
21:56:34 <mkwst_> abarth: this is more about how to treat the response from the server.
21:56:41 <mkwst_> abarth: very client-side based mechanism.
21:57:59 <mkwst_> mwest: if this is something we're interested in, i'd like to see it as a csp directive rather than bloating the header space.
21:58:13 <mkwst_> jww: sure i can put together a proposal.
21:58:29 <mkwst_> dveditz: backwards compat?
21:58:41 <mkwst_> dveditz: old client will ignore it.
21:58:55 <mkwst_> dveditz: frames would be able to talk in old clients.
21:59:02 <mkwst_> deveditz: new clients would be protected.
21:59:15 <mkwst_> jww: right.
21:59:37 <mkwst_> mwest: similar to iframe sandbox in that regard.
21:59:49 <mkwst_> dveditz: how does this impact postMessage.
21:59:59 <mkwst_> dveditz: named suborigins?
22:00:06 <mkwst_> jww: would need to specify suborigin.
22:00:23 <mkwst_> jww: suggested something in the proposal, don't feel too strongly about it, but we'd need to include somethin.
22:00:54 <mkwst_> bhill2: that's why i think combining it with today's origins might be a good idea, rather than rippling the change through the whole platform.
22:01:21 <mkwst_> bhill2: out of time, perhaps we can get to the other things next time?
22:01:34 <mkwst_> bhill2: CORS, will deal with CfC next time as well.
22:01:44 <Zakim> -devditz
22:01:45 <mkwst_> bhill2: thanks!
22:01:48 <Zakim> -[Mozilla.a]
22:01:50 <Zakim> -neilm
22:01:51 <Zakim> -[GVoice]
22:01:51 <Zakim> -[Mozilla]
22:01:52 <bhill2> rrsagent, make minutes
22:01:52 <RRSAgent> I have made the request to generate http://www.w3.org/2013/08/13-webappsec-minutes.html bhill2
22:01:52 <Zakim> -mkwst_
22:01:53 <Zakim> -[Google]
22:01:57 <bhill2> rrsagent, set logs public visible
22:01:58 <Zakim> -puhley
22:02:12 <ekr> ekr has joined #webappsec
22:03:45 <Zakim> -gmaone
22:05:09 <Zakim> -bhill2
22:05:10 <Zakim> SEC_WASWG()5:00PM has ended
22:05:10 <Zakim> Attendees were +49.898.393.0.aaaa, +1.303.229.aabb, bhill2, mkwst_, neilm, gmaone, tanvi, garrettR, [Mozilla], DaneshIrani, +1.415.596.aacc, puhley, ekr, devditz, jww, [GVoice]
22:26:10 <grobinson> grobinson has left #webappsec
22:36:14 <tanvi> tanvi has left #webappsec
22:45:22 <ekr> ekr has joined #webappsec