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