16:20:55 <RRSAgent> RRSAgent has joined #webappsec
16:20:55 <RRSAgent> logging to http://www.w3.org/2015/05/18-webappsec-irc
16:21:43 <bhill2> rrsagent, make minutes
16:21:43 <RRSAgent> I have made the request to generate http://www.w3.org/2015/05/18-webappsec-minutes.html bhill2
16:24:53 <Zakim> Zakim has joined #webappsec
16:25:21 <bhill2> wseltzer, I can't find the minutes for the last meeting...
16:25:59 <bhill2> http://www.w3.org/2015/05/04-webappsec-minutes.html
16:26:17 <bhill2> even http://www.w3.org/2015/05/04-webappsec-irc is missing...
16:26:45 <wseltzer> it looks as though rrsagent was never there
16:26:53 <wseltzer> but I have backlog still
16:28:01 <wseltzer> starting part-way through
16:33:09 <wseltzer> http://www.w3.org/2015/05/04-webappsec-irc.txt is what I have
16:47:02 <wseltzer> bhill2, if someone has better logs, I can generate the full minutes
17:02:28 <bhill2> thanks, I'll ask on the call if anyone has scrollback saved
17:04:56 <wseltzer> and using "trackbot, start teleconf" gets all the bots going at once
17:17:08 <keiji> keiji has joined #webappsec
17:30:50 <renoirb> renoirb has joined #webappsec
18:28:35 <Zakim> Zakim has left #webappsec
18:49:51 <wseltzer> trackbot, start teleconf
18:49:53 <trackbot> RRSAgent, make logs world
18:49:53 <Zakim> Zakim has joined #webappsec
18:49:55 <trackbot> Zakim, this will be WASWG
18:49:55 <Zakim> ok, trackbot; I see SEC_WASWG()3:00PM scheduled to start in 11 minutes
18:49:56 <trackbot> Meeting: Web Application Security Working Group Teleconference
18:49:57 <trackbot> Date: 18 May 2015
18:52:20 <dlongley> dlongley has joined #webappsec
18:53:09 <gmaone> gmaone has joined #webappsec
18:55:31 <gmaone> Is zakim@voip.w3.org broken? I get "500 - Service unavailable", while the echo test (123@voip.w3.org) does work.
18:58:12 <Zakim> SEC_WASWG()3:00PM has now started
18:58:17 <Zakim> SEC_WASWG()3:00PM has ended
18:58:18 <Zakim> Attendees were
18:58:29 <manu> zakim, code?
18:58:29 <Zakim> the conference code is 92794 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), manu
18:58:59 <Zakim> SEC_WASWG()3:00PM has now started
18:59:08 <Zakim> +mkwst
18:59:22 <Zakim> +[IPcaller]
18:59:26 <manu> zakim, I am [IPcaller]
18:59:26 <Zakim> ok, manu, I now associate you with [IPcaller]
18:59:27 <Zakim> +[IPcaller.a]
18:59:31 <manu> zakim, [IPcaller] is me
18:59:31 <Zakim> +manu; got it
18:59:36 <francois> francois has joined #webappsec
18:59:41 <manu> zakim, [IPcaller.a] is dlongley
18:59:41 <Zakim> +dlongley; got it
19:00:09 <manu> zakim, who is on the call?
19:00:09 <Zakim> On the phone I see mkwst, manu, dlongley
19:00:11 <Zakim> + +1.503.712.aaaa
19:00:22 <terri> Zakim, aaaa is me
19:00:22 <Zakim> +terri; got it
19:00:26 <bhill2> bhill2 has joined #webappsec
19:00:34 <Zakim> + +1.206.876.aabb
19:00:53 <Zakim> + +1.206.348.aacc
19:01:07 <bhill2> zakim, this is 92794
19:01:07 <Zakim> bhill2, this was already SEC_WASWG()3:00PM
19:01:08 <Zakim> ok, bhill2; that matches SEC_WASWG()3:00PM
19:01:13 <drx-goog> drx-goog has joined #webappsec
19:02:05 <Zakim> + +1.418.907.aadd
19:02:18 <Zakim> +[Microsoft]
19:02:26 <francois> Zakim, aadd is me
19:02:26 <Zakim> +francois; got it
19:02:32 <Zakim> +[Mozilla]
19:02:57 <Zakim> + +1.310.597.aaee
19:03:01 <dveditz> Zakim, Mozilla has dveditz, ekr
19:03:01 <Zakim> +dveditz, ekr; got it
19:03:04 <ekr> ekr has joined #webappsec
19:03:06 <tanvi> tanvi has joined #webappsec
19:03:19 <bhill2> zakim, aacc is bhill2
19:03:19 <Zakim> +bhill2; got it
19:04:10 <bhill2> zakim, who is here?
19:04:10 <Zakim> On the phone I see mkwst, manu, dlongley, terri, +1.206.876.aabb, bhill2, francois, [Microsoft], [Mozilla], +1.310.597.aaee
19:04:12 <Zakim> [Mozilla] has dveditz, ekr
19:04:12 <Zakim> On IRC I see tanvi, ekr, drx-goog, bhill2, francois, gmaone, dlongley, Zakim, keiji, RRSAgent, dveditz, pde, schuki, tobie, mkwst, timeless, terri, freddyb, manu, Josh_Soref,
19:04:12 <Zakim> ... trackbot, wseltzer
19:04:35 <dwalp> dwalp has joined #webappsec
19:05:13 <tanvi> zakim, aaee is tanvi
19:05:13 <Zakim> +tanvi; got it
19:05:19 <Zakim> + +1.617.324.aaff
19:05:23 <manu> Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2015May/0073.html
19:05:58 <israelh> israelh has joined #webappsec
19:06:02 <tanvi> bhill2: yes, i can send you my irc logs
19:06:08 <bhill2> if anyone has last meeting's IRC logs, I could use them
19:07:14 <keiji> zakim, aaff is keiji
19:07:14 <Zakim> +keiji; got it
19:07:21 <tanvi> sent
19:07:36 <mkwst> drx-goog: What is EPR?
19:07:41 <vgb> vgb has joined #webappsec
19:08:00 <mkwst> ... intended to be complementary to CSP against XSS, but also address CSRF
19:08:05 <bhill2> scribenick: mkwst
19:08:07 <mkwst> ... difficult to implement full locdown CSP
19:08:08 <Zakim> +[Microsoft.a]
19:08:20 <vgb> zakim, [microsoft.a] is me
19:08:20 <Zakim> +vgb; got it
19:08:26 <mkwst> ... EPR is another option to address the issues.
19:08:40 <tanvi> a bit hard to hear.
19:08:42 <mkwst> ... EPR is intended towards self-contained webapps.
19:09:05 <mkwst> ... web page admin interface. consequences of compromise are catastrophic.
19:09:11 <dveditz> https://w3c.github.io/webappsec/specs/epr/
19:09:12 <ekr> Is it just me that is having trouble hearing?
19:09:37 <mkwst> ... How EPR works?
19:09:53 <Zakim> + +1.415.857.aagg
19:10:04 <devd> devd has joined #webappsec
19:10:26 <mkwst> ... Each site that wants to opt-in serves a header that says "I support EPR."
19:10:30 <mkwst> ... corresponding policy file.
19:10:45 <mkwst> ... externally sourced navigation requests to non-entry points have an action defined by the policy.
19:11:09 <mkwst> ... "externally sources" === policy doesn't apply for user initiated navigation, same-origin navigation, address bar, bookmarks, etc.
19:11:29 <mkwst> ... various actions: blocking outright, redirection, etc.
19:11:34 <mkwst> ... applied on a per-policy basis.
19:11:50 <tanvi> so policy works for things like window.open?
19:11:54 <mkwst> ... That's a quick overview. Questions?
19:12:30 <mkwst> bhill2: I have a few questions. The spec says that the delivery mechanism is specified in terms of Manifest.
19:12:40 <mkwst> ... Other parts are hinting at things that don't match up.
19:12:49 <mkwst> ... One policy per origin?
19:13:04 <mkwst> ... Manifest spec allows multiple manifests per origin on a path basis.
19:13:11 <mkwst> ... Intent to allow more than one manifest per origin?
19:13:16 <mkwst> drx: Not today.
19:13:24 <mkwst> ... Format would be the same as manifest spec.
19:13:32 <mkwst> ... Policy file would be separate.
19:13:44 <mkwst> ... No fundamental objections to combining them.
19:14:01 <mkwst> ... Multiple policy files per origin? I hadn't accounted for that in the spec. Wasn't intended.
19:14:12 <mkwst> bhill2: Implies that the manifest might come from a different origin.
19:14:15 <mkwst> [crosstalk]
19:14:24 <mkwst> bhill2: Need to define the algorithm clearly.
19:14:34 <mkwst> dveditz: Manifest specified in a <link> tag in a document.
19:14:51 <mkwst> ... Might be in a document without such a tag, not intended to be part of the app?
19:14:59 <mkwst> ... Suggest .well-known instead.
19:15:16 <mkwst> ... Multiple policies for the same origin isn't workable; in an origin, don't know where you're going.
19:15:37 <mkwst> drx: Agree. Today, would set one policy file in a well-defined location, could make it flexible.
19:15:55 <mkwst> ... using the `Link:` HTTP response header field could solve the <link> tag problem.
19:16:03 <mkwst> ... Not in the spec, but if interest, we could add it.
19:16:12 <mkwst> ... Hardcoded is simplest.
19:16:39 <mkwst> dveditz: Would it be better to use a max-age like HSTS/HPKP in case sites lock themselves into a bad policy?
19:16:57 <mkwst> drx: That was the original idea, now we're just using the default cache header expiration.
19:17:22 <mkwst> ... do recognize that problem. Could certainly be the case however one specifies the expiration, if a broken policy is served, etc.
19:17:32 <mkwst> dveditz: Cache might expire things faster than you'd like.
19:18:14 <mkwst> drx: I see. One thing mentioned in the spec is the idea that when a policy takes effect you can decide to issue an async request for the policy file to refresh.
19:18:17 <terri> Caching might also be a bit of an issue if we start talking per-path policy.  That could result in a bunch of extra round trips
19:18:24 <mkwst> ... UAs could implement sane behavior here.
19:18:48 <mkwst> ... Perhaps "the first time violation happens in a day, pull down a new copy".
19:19:36 <mkwst> drx: More questions?
19:20:27 <mkwst> bhill2: If I've seen the header, and downloaded the manifest, covers a resource, and then load that resource that doesn't contain the EPR header, do I apply the policy?
19:20:57 <mkwst> ... Given a.html and b.html: a.html has an EPR header. I download the manifest, declares that b.html should be covered.
19:21:10 <mkwst> ... I load b.html, not served with an EPR header. Do I apply the policy?
19:21:22 <mkwst> drx: it would apply the policy. interesting point, though.
19:21:44 <mkwst> ... lack of EPR header doesn't mean you've opted out of EPR.
19:22:17 <mkwst> bhill2: tricky to say that you can be opted in without sending the header.
19:22:41 <mkwst> ... If one resource can set a header which impacts policy elsewhere on the origin, we should be cautious about specifying the behavior.
19:22:51 <mkwst> drx: Not defined today, we should be careful.
19:23:07 <mkwst> bhill2: If I see manifest data, but no EPR header, should I apply it?
19:23:11 <mkwst> drx: No. No header, no EPR.
19:23:17 <mkwst> ... Should specify that.
19:23:37 <mkwst> bhill2: Have you thought about interactions with CORS?
19:24:10 <mkwst> ... What is the order of operations/rules for omit-credentials in EPR vs credentials in CORS?
19:24:44 <mkwst> drx: Action that allows to omit credentials seemed like a nice-to-have; need to define more clearly to specify interaction.
19:25:01 <mkwst> bhill2: Rename to "omit-credentils"? Better not to mint new concepts, but to reuse names.
19:25:12 <mkwst> ... Whatever fetch says.
19:25:25 <mkwst> ... "credentials=omit" => "omit-credentials"?
19:25:55 <mkwst> dveditz: Do the redirect URL/reporting URL need to be same-origin?
19:26:06 <mkwst> drx: Should be explicit; should lock to same-origin.
19:26:13 <bhill2> we don't lock CSP reports to same-origin...
19:26:36 <mkwst> dveditz: In the IDL, misusing `sequence`. Only for parameters/return values.
19:26:44 <mkwst> ... check with Anne.
19:27:06 <mkwst> ... Concerned about regex bit here. Wild west. Flavours, etc.
19:27:14 <mkwst> ... Even if we reference JS, it's changed over time.
19:27:20 <mkwst> ... Wondering if there's a better way.
19:27:28 <mkwst> ... Simpler globbing format, perhaps?
19:27:47 <mkwst> drx: Probably fine. Needs to be finer-grained than a string comparison.
19:28:07 <mkwst> ... Implementing this via the prototype, we needed to specify something under a path, for instance.
19:28:20 <mkwst> dveditz: Unix utils; basic/extended regex.
19:28:26 <mkwst> ... Would be nice to have a basic version.
19:28:37 <mkwst> ... Minor concern, just not well specified yet.
19:28:51 <mkwst> drx: Want to point to something that exists. Don't want to define something new.
19:28:59 <mkwst> ... Just need to be a bit more flexible than string comparison.
19:29:14 <mkwst> dveditz: And not just a simple prefix match?
19:29:36 <mkwst> dwalp: Check the apparmour(?) format. It does something similar.
19:29:52 <francois> apparmor, actually
19:29:53 <mkwst> https://wiki.ubuntu.com/AppArmor ?
19:30:19 <mkwst> dwalp: Opensource linux security product.
19:30:33 <mkwst> ... Developers on it are at Ubuntu.
19:30:45 <bhill2> s/dwalp/ccowan
19:30:51 <terri> I'd be surprised if there isn't some well-defined implementation of regex we could use somewhere
19:30:52 <mkwst> dveditz: Navigational seems wordy. Perhaps "document" or "page"?
19:31:03 <dlongley> http://www.ecma-international.org/ecma-262/5.1/#sec-15.10
19:31:13 <mkwst> drx: ?
19:31:35 <mkwst> dveditz: Need to type "navigational" pretty often. "document" seems simpler.
19:31:43 <mkwst> drx: "document" would work too, I suppose.
19:31:56 <mkwst> dveditz: The algorithm runs through the rules in order.
19:32:07 <mkwst> ... Match one, good to go, don't check anything else.
19:32:15 <mkwst> drx: Yes. Match one, it's an entry point, good to go.
19:32:22 <mkwst> ... Then do the default action.
19:32:33 <mkwst> ... Unless the UA decides it's exempt, like a bookmark action or etc.
19:32:47 <mkwst> dveditz: Needing to type `allow` is tedious.
19:33:15 <mkwst> ... When it's the default on the web, perhaps something else should be the default.
19:33:26 <mkwst> ... Don't want a complex policy. Downloading, parsing, etc.
19:33:41 <bhill2> dveditz: time check?
19:33:52 <mkwst> ... allow-data false means that if the request has data it doesn't match, right?
19:33:59 <mkwst> drx: yes. doesn't force the data to be stripped.
19:34:22 <mkwst> dveditz: One more question: has to be a secure request? Only for HTTPS?
19:34:37 <mkwst> drx: Seems reasonable. Don't need to enable for non-secure sites.
19:34:59 <mkwst> dveditz: Something in the middle of the spec. Perhaps should be clear from the beginning that ti's true, or the bit in the middle is confusing.
19:35:15 <mkwst> drx: will pin it down.
19:35:36 <mkwst> dveditz: Section 4.3, step 1.
19:35:45 <mkwst> bhill2: further questions? GitHub issues!
19:35:56 <mkwst> bhill2: last words, David?
19:36:05 <mkwst> drx: GitHub issues! Send me email! Chat! Whatever!
19:36:18 <bhill2> scribenick bhill2
19:36:23 <mkwst> https://w3c.github.io/webappsec/specs/credentialmanagement/
19:36:30 <bhill2> TOPIC: Credential Management Level 1
19:36:44 <bhill2> mkwst: a number of issues open, many editorial, some more fundamental
19:37:00 <bhill2> ... summarize first, then turn over to Manu and David for their concerns about extensibility
19:37:23 <bhill2> ... summary of current API
19:37:26 <tanvi> if you are not talking, can you mute
19:37:28 <bhill2> zakim, who is making noise?
19:37:31 <israelh> +1
19:37:38 <Zakim> bhill2, listening for 10 seconds I heard sound from the following: mkwst (80%), +1.206.876.aabb (45%), [Mozilla] (4%)
19:37:45 <bhill2> zakim, mute aabb
19:37:45 <Zakim> +1.206.876.aabb should now be muted
19:39:11 <mkwst> https://github.com/w3c/webappsec/pull/292
19:40:05 <drx-goog_> drx-goog_ has joined #webappsec
19:41:31 <mkwst> bhill2: The part where it says it's applicable to the top-level browsing context.
19:41:43 <mkwst> ... Concern is that the user doesn't understand anything other than the address bar.
19:41:51 <mkwst> ... Set ofuse cases for collecting credentials in frames.
19:41:54 <dveditz> eeeeeevil
19:42:04 <mkwst> ... Prevalent in payment, etc.
19:42:08 <mkwst> ... Common use case.
19:42:30 <terri> side note: there's scientific evidence that the user doesn't really understand the address bar, even
19:42:55 <bhill2> mkwst: I agree with you on those use cases, not stunningly common but certainly used on the web
19:43:13 <bhill2> ... would prefer to specify something with a more narrow scope and determine how to open it up more safely
19:43:30 <bhill2> ... address bar is only user context, has been core to model that the spec is putting together
19:43:45 <bhill2> ... hard to understand how to make it safe for iframe to request credentials
19:43:52 <dveditz> terri: too true. but if they understand anything it might be the URL bar and the lock. maybe
19:44:07 <bhill2> ... assume PayPal were to do this ... they don't do this now and there is a reason
19:44:44 <mkwst> bhill2: Paypal does have an iframe flow.
19:44:48 <terri> dveditz: the eye-tracking studies on EV certs found that they don't even look at the url bar and lock, even when they claim to, sadly.  But I agree that it's still the best bet, it's just kind of a crappy best bet.
19:44:51 <mkwst> ... in response to other payment providers.
19:45:05 <bhill2> ... if browser is going to ask the user and the origin is different from address bar
19:45:05 <mkwst> dev: Should this spec get into that?
19:45:27 <dveditz> yeah. anecdotally I think my family only checks the URL bar if something on the page "looks off"
19:45:37 <mkwst> ... Invariant across everything we do.
19:45:52 <mkwst> ... We can mention the invariant, but shouldn't specify that.
19:45:58 <mkwst> ... Verified by Visa, etc.
19:46:28 <bhill2> mkwst: if you can't trust it, we can't expect anyone to trust it
19:46:35 <bhill2> ... user mediation is critical
19:46:58 <bhill2> .. credential info is sensitive, esp from UI perspective
19:47:27 <bhill2> ... means persistent access to a user's data at an origin
19:48:02 <bhill2> ... going to be confused and not able to make a good trust decision when multiple origins in play
19:48:05 <manu> +1 to mkwst
19:48:23 <bhill2> dev: this is a problem with http basic auth, etc. quick redirects can bypass
19:48:37 <bhill2> ... much harder and broader problem, we won't solve it in this spec
19:48:44 <bhill2> mkwst: set the bare minimum bar
19:48:49 <bhill2> ... possible to do more, not les
19:49:01 <bhill2> dev: worry about doing the bare minimum, it's like doing RC4
19:49:07 <bhill2> ... would rather acknowledge the problem
19:49:25 <bhill2> mkwst: how we decrease security by limiting conrext
19:49:29 <bhill2> s/conrext/context
19:49:52 <mkwst> bhill2: I don't like iframe flows, but this UI could increase my trust.
19:49:59 <mkwst> ... Chooser must indicate the origin.
19:50:16 <mkwst> ... That's trusted interaction, perhaps I'll have better understanding of what's going on.
19:50:37 <mkwst> ... Origin-locked delivery to the iframe is a reasonable increase in security.
19:50:46 <mkwst> ... Iframe can only ask on its own behalf.
19:51:01 <mkwst> ... Protecting the credential itself, this ight be safer, assuming the iframe flows exist.
19:51:11 <bhill2> assuming these flows exist, this is a safer way to handle than excluding htem
19:51:28 <bhill2> israel: can we scope to high level with understanding there is more work to do later, easier to expand.
19:51:31 <mkwst> israelh: Why couldn't we start with the top-level, and perhaps extend to nested contexts later?
19:52:22 <manu> Potential Web Payments IG and Credentials CG concerns here:  https://lists.w3.org/Archives/Public/public-webappsec/2015May/0101.html
19:52:43 <bhill2> manu: couple of groups interested in credentials work
19:53:03 <bhill2> ... web payments IG, credentials CG working on slightly different type of credentials
19:53:42 <bhill2> ... would like to harmonize these new types of credentials with the api being created here
19:54:34 <bhill2> ... types of credentials these groups talking about are broader: driver's addresses, proofs of age, address, etc.
19:54:57 <bhill2> ... same origin vs. cross-origin credentials
19:55:34 <bhill2> ... is the current API shape extensible enough to handle cross-origin credentials?
19:55:34 <Zakim> - +1.415.857.aagg
19:56:55 <bhill2> vijay: seems there is a more expansive definition of credential, why do feel they must be accomplished by extending this API rather than creating a bigger framework this API can plug into?
19:57:37 <bhill2> manu: our thinking is very similar, so close we feel we would be duplicating work, vs. just making small modifications on extensibility
19:58:08 <bhill2> vijay: seems like you think it should be possible to put a payment instrument into this API
20:00:11 <bhill2> manu: new credentials are associated with an identifier, not a "has a" identifier relationship
20:00:32 <Zakim> -[Mozilla]
20:00:53 <bhill2> ... we are committed to get something to Mike on an extensibility mechanism
20:00:57 <terri> I have a question about usability work in this space, but I'll try to bring it to the mailing list.
20:01:33 <bhill2> .. we have some questions, specifically about what browsers think about this work, data structures, etc.
20:02:23 <terri> +1 to bringing this to PING
20:03:10 <Zakim> -tanvi
20:03:15 <Zakim> - +1.206.876.aabb
20:03:18 <Zakim> -manu
20:03:20 <Zakim> -francois
20:03:21 <Zakim> -dlongley
20:03:22 <bhill2> rrsagent, make minutes
20:03:22 <RRSAgent> I have made the request to generate http://www.w3.org/2015/05/18-webappsec-minutes.html bhill2
20:03:25 <Zakim> -[Microsoft]
20:03:26 <Zakim> -terri
20:03:29 <bhill2> rrsagent, set logs world
20:03:29 <Zakim> -keiji
20:03:34 <bhill2> zakim, list attendees
20:03:34 <Zakim> As of this point the attendees have been mkwst, manu, dlongley, +1.503.712.aaaa, terri, +1.206.876.aabb, +1.206.348.aacc, +1.418.907.aadd, [Microsoft], francois, +1.310.597.aaee,
20:03:37 <Zakim> ... dveditz, ekr, bhill2, tanvi, +1.617.324.aaff, keiji, vgb, +1.415.857.aagg
20:03:41 <bhill2> rrsagent, make minutes
20:03:41 <RRSAgent> I have made the request to generate http://www.w3.org/2015/05/18-webappsec-minutes.html bhill2
20:03:50 <bhill2> rrsagent, set logs world
20:04:00 <Zakim> -vgb
20:04:38 <dlongley> dlongley has left #webappsec
20:14:19 <mkwst> Hi. Sorry. :(
20:14:23 <Zakim> -mkwst
20:14:57 <mkwst> You'll be thrilled to know that my daughter says hi. Sorry I wasn't able to attend the last ~15 minutes. :/
20:19:23 <Zakim> disconnecting the lone participant, bhill2, in SEC_WASWG()3:00PM
20:19:25 <Zakim> SEC_WASWG()3:00PM has ended
20:19:25 <Zakim> Attendees were mkwst, manu, dlongley, +1.503.712.aaaa, terri, +1.206.876.aabb, +1.206.348.aacc, +1.418.907.aadd, [Microsoft], francois, +1.310.597.aaee, dveditz, ekr, bhill2,
20:19:26 <Zakim> ... tanvi, +1.617.324.aaff, keiji, vgb, +1.415.857.aagg
20:39:40 <dveditz> dveditz has joined #webappsec
20:50:38 <bhill2> thanks, wseltzer, I got a copy from some folks, will try to run it through the scribe.pl woodchipper and see what happens
20:58:41 <wseltzer> sounds good
21:33:00 <keiji> keiji has joined #webappsec
21:55:59 <ekr> ekr has joined #webappsec
22:02:36 <ekr> ekr has joined #webappsec
22:12:56 <ekr> ekr has joined #webappsec
22:20:37 <ekr> ekr has joined #webappsec
22:26:36 <ekr> ekr has joined #webappsec
22:57:53 <bhill2> bhill2 has joined #webappsec
22:59:34 <keiji> keiji has joined #webappsec
23:52:34 <bhill2> bhill2 has joined #webappsec