IRC log of webappsec on 2013-08-13

Timestamps are in UTC.

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