IETF
websec@jabber.ietf.org
Monday, 26 March 2012< ^ >
stpeter has set the subject to: WebSec WG | http://tools.ietf.org/wg/websec/
Room Configuration

GMT+0
[10:29:05] linuxwolf joins the room
[10:49:01] sftcd joins the room
[10:49:58] sftcd leaves the room
[10:50:12] sftcd joins the room
[10:50:46] iljitsch joins the room
[10:51:26] iljitsch leaves the room
[10:57:43] hillbrad joins the room
[10:59:17] linuxwolf leaves the room
[10:59:27] linuxwolf joins the room
[11:00:44] SM joins the room
[11:01:07] rbarnes_scribe joins the room
[11:01:10] kazubu joins the room
[11:01:13] iljitsch joins the room
[11:01:14] <rbarnes_scribe> aloha
[11:01:23] <SM> Hi Richard
[11:01:33] <rbarnes_scribe> anyone here not physically in the room?
[11:01:41] iljitsch leaves the room
[11:01:45] <hillbrad> yes
[11:01:57] <rbarnes_scribe> ok, i'll try to be more thorough :)
[11:02:01] iljitsch joins the room
[11:02:17] <iljitsch> bonjour
[11:02:19] <hillbrad> audio streaming link appears not to be working
[11:02:28] <rbarnes_scribe> salut, iljitsch
[11:02:30] Atarashi Yoshifumi joins the room
[11:02:34] <SM> appears as in you cannot see it?:)
[11:02:43] <linuxwolf> mic tests happening now
[11:02:44] cabo joins the room
[11:02:49] <SM> No audio here
[11:02:59] Dominik Elsbroek joins the room
[11:03:13] stpeter joins the room
[11:03:43] <stpeter> still no audio?
[11:03:49] <SM> No audio
[11:03:52] <stpeter> hmph
[11:03:57] <stpeter> ok I'll ping the Secretariat
[11:03:59] burn joins the room
[11:04:13] Satoru Kanno joins the room
[11:05:06] wseltzer joins the room
[11:05:28] <linuxwolf> still nothing?
[11:05:44] <hillbrad> audio at http://ietf83streaming.dnsalias.net/ietf/ietf833.m3u is resolving to http://nagasaki.bogus.com:8000/stream03, which is "The file you requested could not be found"
[11:05:56] <stpeter> heh
[11:06:11] <linuxwolf> hrm
[11:06:30] <rbarnes_scribe> ok, hard-core transcription/scribing time
[11:06:40] rbarnes_scribe does finger stretches
[11:06:41] barryleiba joins the room
[11:06:59] <stpeter> the NOC folks are on their way
[11:07:07] <rbarnes_scribe> still doing initial set-up, nothing interesting yet
[11:07:21] mcr joins the room
[11:07:22] =JeffH joins the room
[11:07:31] <linuxwolf> note well
[11:07:44] <rbarnes_scribe> going through the chairs slides
[11:07:52] <rbarnes_scribe> note well the note well
[11:07:52] Bran, Cary joins the room
[11:08:03] <stpeter> agenda review
[11:08:50] <rbarnes_scribe> main focus of the meeting is the discussion of -websec-framework-reqs and -mime-sniff
[11:09:01] <rbarnes_scribe> agenda bashes?
[11:09:03] <stpeter> no agenda bashing
[11:09:16] <rbarnes_scribe> review of WG status
[11:09:19] <stpeter> page 5
[11:09:27] Hollenbeck joins the room
[11:09:57] <rbarnes_scribe> agenda slides: http://www.ietf.org/proceedings/83/agenda/agenda-83-websec.txt
[11:10:01] <rbarnes_scribe> er, agenda
[11:10:24] <rbarnes_scribe> agenda SLIDES: http://www.ietf.org/proceedings/83/slides/slides-83-websec-3.pdf
[11:11:01] <rbarnes_scribe> now up: jeff hodges on hsts
[11:11:05] PHB joins the room
[11:11:14] <stpeter> Dear Jabberites: if you have topic that you'd like us to relay to the physical meeting room, please prepend with "MIC"
[11:11:15] synp joins the room
[11:11:29] <rbarnes_scribe> slides: http://www.ietf.org/proceedings/83/slides/slides-83-websec-5.pdf
[11:11:49] <rbarnes_scribe> slide: Progress since IETF 82
[11:11:54] <PHB> is the audio working?
[11:11:59] <SM> No
[11:12:09] <PHB> oh fun
[11:12:11] <stpeter> the NOC is investigating
[11:13:04] <stpeter> Open Tickets
[11:13:30] <stpeter> issue #33
[11:13:57] <linuxwolf> question to the room: are people aware of the quoted-string grammar discussion?
[11:14:37] <rbarnes_scribe> Julian: If there is consensus to make changes to the grammer, I will provide more specifics
[11:15:21] <rbarnes_scribe> JeffH: Concern is mainly around max-age; julian argues that value for max-age is either token or quoted string (currently just token)
[11:15:33] barryleiba leaves the room
[11:15:57] <rbarnes_scribe> issue is that in HTTPbis cleanup work, julian is trying to move everyone toward using either tokens or quoted strings uniformly
[11:16:23] <rbarnes_scribe> that way, if people are sloppy on the server side, the client will be more relaxed/accepting
[11:17:03] <rbarnes_scribe> julian: Proliferation of header formats means there's huge parser proliferation, lots of pain/bugs
[11:17:22] <stpeter> Carsten Bormann at the mic
[11:17:30] <stpeter> similar issue in the CORE WG
[11:17:54] <rbarnes_scribe> carsten: in CORE, we have re-used the Link header format, and found that implementors didn't get the fine point about tokens vs. quoted strings
[11:18:07] <rbarnes_scribe> jeff: would you have every parameter value in either syntax?
[11:18:16] <rbarnes_scribe> carsten: yeah, just handle all the parameters the same way
[11:18:36] <rbarnes_scribe> julian: Link header does have that problem, erratum has been filed
[11:19:28] <rbarnes_scribe> adam barth was opposed to quoted-string, but this may not still be true
[11:20:27] tlr joins the room
[11:20:33] <rbarnes_scribe> chairs: action item to julian to submit something substantial
[11:20:54] <stpeter> BTW, the erratum against RFC 5988 was http://www.rfc-editor.org/errata_search.php?rfc=5988&eid=3158
[11:21:27] <rbarnes_scribe> Hannes: is this the same discussion as in oauth?
[11:21:32] <rbarnes_scribe> julian: yes
[11:22:15] <rbarnes_scribe> HANDS: Who is comfortable providing an opinion on this issue?
[11:22:21] <rbarnes_scribe> (~10 hands)
[11:22:28] <rbarnes_scribe> HANDS: Who supports Julian's proposal
[11:22:29] <stpeter> moving to issue #37
[11:22:33] <rbarnes_scribe> (~10 hands)
[11:22:43] <rbarnes_scribe> HANDS: Who opposes Julian's proposal?
[11:22:44] <stpeter> (while rbarnes_scribe catches up)
[11:22:50] <rbarnes_scribe> (no hands)
[11:22:58] <rbarnes_scribe> On issue 37
[11:23:54] <rbarnes_scribe> tobias clarified that you need to cache subdomains even if they're overridden by parents
[11:24:34] <rbarnes_scribe> paul hoffman
[11:24:37] Thomas Hardjono joins the room
[11:24:50] <rbarnes_scribe> paul: add a sentence explicitly about what max-age=0 means
[11:25:42] <rbarnes_scribe> think that people are throwing away 0-lifetime HSTS pins
[11:25:50] <stpeter> issue 39
[11:25:56] <rbarnes_scribe> jeff: will note that as well
[11:26:02] <Thomas Hardjono> Any audio for websec?
[11:26:09] <stpeter> (and BTW we are recording locally via Hannes)
[11:26:12] <stpeter> Thomas Hardjono: no
[11:26:17] <stpeter> NOC is looking into it
[11:26:19] <rbarnes_scribe> jeff: still reading through issue 39 text
[11:26:23] <Thomas Hardjono> ok thanks
[11:26:24] <rbarnes_scribe> will reply on list
[11:26:31] <rbarnes_scribe> on issue 41/42
[11:26:38] stpeter has set the subject to: WebSec WG | http://tools.ietf.org/wg/websec/ audio is broken at IETF 83!
[11:26:59] Andrew Sullivan joins the room
[11:27:12] <rbarnes_scribe> on issue 41: hard fail has been built in from the beginning
[11:27:28] <rbarnes_scribe> users are not given the option to "click through"
[11:27:42] <rbarnes_scribe> moved it from normative language to advice, because we don't do UI
[11:28:12] William Chan joins the room
[11:28:20] <rbarnes_scribe> yoav proposes that we add an indication of whether the browser should hard fail
[11:28:49] <rbarnes_scribe> jeffh: haven't had any issues with test deployment
[11:29:11] <rbarnes_scribe> yoav: thought some things skipped the hard fail in the event of expired certs
[11:29:48] <rbarnes_scribe> this could be a real barrier to entry, especially for small players
[11:30:14] <rbarnes_scribe> would like the option of soft roll-out
[11:30:53] <rbarnes_scribe> hoffman: jeff was incorrect when he said it was non-normative, says MUST terminate
[11:31:06] <rbarnes_scribe> jeff: that's correct, we were talking more about user recourse
[11:31:31] york joins the room
[11:32:22] <rbarnes_scribe> hoffman: [missed core of it]
[11:32:35] <rbarnes_scribe> tobias: how are foreseeing these things breaking, given they're under control of web site?
[11:32:50] <rbarnes_scribe> key question here seems to be cert expiry
[11:33:47] <rbarnes_scribe> can see a point for soft fail, but obviously we need to go hard fail at the end
[11:34:11] <rbarnes_scribe> farrell [missed]
[11:34:23] <rbarnes_scribe> salowey: in prototypes, have you run into trouble with captive portals?
[11:34:53] <rbarnes_scribe> jeffh: we've had push-back from captive portal vendors
[11:35:22] <rbarnes_scribe> hoffman: to farrell: would you be ok with this if there were a time limit in the document?
[11:35:54] <rbarnes_scribe> yoav: expiry happens, need to be able to recover
[11:36:01] <hillbrad> audio is now working
[11:36:15] <rbarnes_scribe> ah, great, i might slow down a little
[11:36:27] <stpeter> hillbrad: thanks for the report
[11:36:30] <rbarnes_scribe> farrell: expiry and rollout are completely different issues
[11:36:43] <stpeter> and thanks to rbarnes for scribing
[11:36:49] <rbarnes_scribe> jeffh: some folks have said not to hard-fail on *just* expiry
[11:36:55] <stpeter> do folks in the chatroom need the link to the audio stream?
[11:37:10] <hillbrad> http://ietf83streaming.dnsalias.net/ietf/ietf833.m3u
[11:37:23] <stpeter> hillbrad: thanks
[11:37:32] <rbarnes_scribe> sullivan: sounds like people want a do what i mean protocol, uncomfortable with that
[11:37:36] stpeter has set the subject to: WebSec WG | http://tools.ietf.org/wg/websec/ audio at http://ietf83streaming.dnsalias.net/ietf/ietf833.m3u
[11:38:11] barryleiba joins the room
[11:38:14] <rbarnes_scribe> if the problem is "it fails when i screw something up", don't accommodate screw-ups, learn how to do things right
[11:38:23] <rbarnes_scribe> tobias: +1 to andrew
[11:39:28] <rbarnes_scribe> paul hoffman at the mic
[11:40:20] <rbarnes_scribe> hoffman: if we don't add this parameter, we might need a "pitfalls" document
[11:40:42] <rbarnes_scribe> similar issues with CRL/OCSP checking as with expiry
[11:41:43] <rbarnes_scribe> jeffh: we do touch on those things, send comments on docs
[11:42:03] <rbarnes_scribe> yoav at the mic
[11:42:19] Tom Wesselman joins the room
[11:43:23] cabo leaves the room
[11:43:53] <mcr> I think his point is that you can't force the user to go clear, because the site doesn't ever operate clear.
[11:44:30] <sftcd> I don't get that - for yoav's case, what's listening on port 80?
[11:44:52] <rbarnes_scribe> yngve petterson at the mic
[11:45:21] <mcr> nothing... that's the point. he doesn't care to hardfail, because he just wants the user to always use https:, but doesn't care if some other https validation fails... he's not going to be forced to http, because he doesn't speak http.
[11:46:07] <rbarnes_scribe> yngve: instead of hard failing on things like OCSP, we just show the site as insecure
[11:46:29] Tom Wesselman leaves the room
[11:47:10] <rbarnes_scribe> tobias: trouble seeing where we're going with this
[11:47:52] barryleiba leaves the room
[11:48:08] <stpeter> Iljitsch van Beinum at the mic
[11:48:16] <rbarnes_scribe> iljitsch: clarification: is there a third option between user click-through and complete hard fail?
[11:48:38] <rbarnes_scribe> sullivan: disagree really strongly with that
[11:49:33] <rbarnes_scribe> iljitsch: user is more involved in https than dnssec
[11:49:45] <rbarnes_scribe> sullivan: either way, there's a site operator involved
[11:50:08] <rbarnes_scribe> [personal opinion: +1 to mr. sullivan]
[11:50:34] <rbarnes_scribe> yngve: if there's no hard fail, people will just have users click through
[11:51:23] <Andrew Sullivan> I'm not getting up again, but if the answer is "if we don't let this thing softfail, people will just disable it", then we might as well not standardize the mechanism at all
[11:51:23] <rbarnes_scribe> stpeter: you said earlier that hard fail was not failing the connection, it was not allowing click-through
[11:51:37] Suzanne joins the room
[11:52:18] <rbarnes_scribe> jeffh: we really are talking about UI advice
[11:52:26] <rbarnes_scribe> hoffman: that doesn't come across clearly in the draft
[11:52:45] <rbarnes_scribe> [not_scribe: andrew: it's also not clear what a "soft fail" means, where the bounds lie]
[11:53:53] <stpeter> obviously, Eric Rescorla at the mic
[11:54:21] <rbarnes_scribe> ekr: browsers typically hang up the connection pretty soon after the TLS handshake complete
[11:54:26] <rbarnes_scribe> yngve: we try to keep it open
[11:55:23] <rbarnes_scribe> tobias: asking some shows of hands
[11:55:36] <rbarnes_scribe> HANDS: do you feel comfortable judging on this?
[11:55:40] <rbarnes_scribe> (>10 hands)
[11:55:54] <rbarnes_scribe> HANDS: in favor of no recourse?
[11:55:59] <rbarnes_scribe> (10-15 hands)
[11:56:09] <rbarnes_scribe> HANDS: Option for hard-fail=no?
[11:56:14] <rbarnes_scribe> (~2 hands)
[11:56:22] <rbarnes_scribe> HANDS: Specific cases in which hard-fail=no?
[11:56:28] <rbarnes_scribe> (~2 hands, different people)
[11:56:45] <rbarnes_scribe> tobias: pretty strong indication toward remaining with hard fail
[11:57:15] <rbarnes_scribe> ekr: suggest an alternative interpretation of this? CSP has a "don't puke, just tell me" directive
[11:57:51] <rbarnes_scribe> rather than having a feature that says "don't hard fail", have something like the "report URI" function from CSP
[11:58:05] <rbarnes_scribe> risk of having a feature that could completely brick your site
[11:58:54] <rbarnes_scribe> hoffman: maybe inform the users of why the site hard-failed
[11:59:48] <linuxwolf> remember, if those not present want something spoken, prefix with "mic:"
[11:59:58] <rbarnes_scribe> crocker: informing users won't do anything; let's not make this a user interface group
[12:00:18] <rbarnes_scribe> [linuxwolf: or just lazy people in the room :) ]
[12:00:42] <linuxwolf> the lazy people can just hardfail d-:
[12:01:18] <mcr> crocker is wrong. Administrators are users. Administrators and support people have only the same tools as the users. They only way they can escalate to the right people is to get the details.
[12:01:29] <PHB> MIC: There is a huge difference between the decision to communicate information to the user (or not) and being a UI group
[12:01:42] <rbarnes_scribe> iljitsch: [sounds like something like what ekr said]
[12:01:51] <PHB> MIC the TLS protocol use in HTTP and the web relies on the users being informed in particular ways
[12:01:54] <SM> The user makes an informed decision ;_0
[12:01:57] <rbarnes_scribe> mcr: do you want that to the mic?
[12:02:03] <mcr> okay.
[12:02:13] <linuxwolf> PHB: will mic for you
[12:02:45] linuxwolf is now known as m&m
[12:02:52] <rbarnes_scribe> hannes: look at HTTP auth vs. form-based auth; too hard a fail can make things less useful
[12:03:00] <stpeter> "nothing fails like failure"
[12:03:48] Lucy Lynch&#x2019;s iPad joins the room
[12:03:55] <SM> So the WG is discussing how to redefine failure to make it a success
[12:04:13] <rbarnes_scribe> ???: if we specify more than that it must fail, then this is not a standard that browsers can implement correctly
[12:04:29] <tlr> ??? = Tom Lowenthal
[12:04:33] <rbarnes_scribe> ekr: suggesting a mode where you proceed as if HSTS had not been used
[12:04:35] <m&m> PHB: still mic?
[12:04:48] <Andrew Sullivan> It may be that the consequent of what Tom said is true even without the antecedent.
[12:05:32] <PHB> unless the room is agreed crocker is wrong on that point, yes
[12:06:04] <rbarnes_scribe> ekr: clarify, not suggesting that there be a mode where users can click through
[12:06:07] <m&m> I believe the room has
[12:06:19] <rbarnes_scribe> [PHB: pretty sure the room diagrees with crocker]
[12:06:37] barryleiba joins the room
[12:06:39] <PHB> [that sounds ok then]
[12:06:39] <rbarnes_scribe> [PHB's comment being relayed]
[12:08:11] <rbarnes_scribe> iljitsch: the issue when hsts fails isn't really the site giving stuff to the user, it's more user data going to server
[12:08:31] <rbarnes_scribe> lowenthal: either option here is pretty untenable, ordering browsers to show or hide information
[12:09:21] <rbarnes_scribe> tobias: conclusion is, no conclusion
[12:09:33] <rbarnes_scribe> now on issue 42
[12:09:38] <mcr> I agree... browsers should neither be forced to display, nor prevented from doing so.
[12:10:26] PHB leaves the room
[12:10:28] <rbarnes_scribe> [mcr: it's a little bit of a false dichotomy, given that the current language is not normative, just advisory]
[12:10:32] <iljitsch> i
[12:10:47] <iljitsch> I disagree about trying to hide such failures from the user
[12:11:02] Tom Wesselman joins the room
[12:11:02] <iljitsch> the connection can't be established for security reasons. The end.
[12:11:11] <iljitsch> no choice, MUSTs all the way down
[12:11:11] barryleiba leaves the room
[12:11:26] PHB joins the room
[12:11:46] <iljitsch> if you can't do this for security then we may as well remove RFC 2119 language from all our documents.
[12:11:47] <rbarnes_scribe> jeffh: CAs should do the right thing, instead of us modifying the protocol
[12:12:28] <rbarnes_scribe> hoffman: if CA.com turns on HSTS, then it can block access to OCSP / CRL content
[12:15:10] <rbarnes_scribe> jeffh: could also violate HSTS by leaking cookies on unsecure connections
[12:17:10] <rbarnes_scribe> tobias: there's still some circular conditions you can get in, e.g., for a site hosting a CRL for itself
[12:17:16] <rbarnes_scribe> hoffman: just put it on a separate domain!
[12:17:22] <rbarnes_scribe> tobias: it already does
[12:17:32] <rbarnes_scribe> jeffh: want to close this ticket without addressing
[12:18:20] barryleiba joins the room
[12:18:31] <rbarnes_scribe> next presenter: yoav nir on Extended Origins
[12:18:54] <rbarnes_scribe> slides: http://www.ietf.org/proceedings/83/slides/slides-83-websec-0.pdf
[12:19:02] <rbarnes_scribe> slide: What's the problem
[12:20:03] <rbarnes_scribe> slide: The proposal
[12:20:39] <rbarnes_scribe> [ adds a path parameter to origin (making it a 4-tuple) that allows the domain to constrain path as well ]
[12:22:52] <rbarnes_scribe> tlr: in partial deployment, doesn't this fail unsafe?
[12:23:29] <rbarnes_scribe> yoav: these are internal, so they're not likely to attack each other
[12:23:56] <rbarnes_scribe> andrew: your third option won't work, it's hopelessly broken
[12:25:01] <rbarnes_scribe> [third option == Yet Another Alternate Solution]
[12:25:54] <rbarnes_scribe> Richardson: [concern about login pages]
[12:27:34] Hollenbeck leaves the room
[12:28:24] Lucy Lynch&#x2019;s iPad leaves the room
[12:28:24] <rbarnes_scribe> jeffh: hillbrad and i think this is really broken, no way we're going to change origin
[12:28:54] Lucy Lynch&#x2019;s iPad joins the room
[12:29:18] <rbarnes_scribe> tobias: call for conversation on the list
[12:29:24] Lucy Lynch&#x2019;s iPad leaves the room
[12:29:29] <hillbrad> using host names as suggested on list is good solution for VPN
[12:29:54] <mcr> wildcard certificates ought to be cheaper :-)
[12:30:31] <rbarnes_scribe> tobias: update on a couple of w3c issues
[12:30:31] antonin.bas joins the room
[12:30:33] <rbarnes_scribe> x-frame-options
[12:30:50] <rbarnes_scribe> slides: http://www.ietf.org/proceedings/83/slides/slides-83-websec-2.pdf
[12:30:51] antonin.bas leaves the room
[12:30:56] <rbarnes_scribe> slide: frame-options: history
[12:32:41] <mcr> I like the "DENY" option.
[12:33:08] hillbrad leaves the room
[12:33:21] hillbrad joins the room
[12:33:33] <rbarnes_scribe> slide: frame-options - Drafts
[12:33:34] barryleiba leaves the room
[12:34:58] <rbarnes_scribe> slide: frame-options
[12:35:57] <rbarnes_scribe> iljitsch: why is this not in w3c, in HTML?
[12:36:59] <mcr> I think it needs to be here, because the content being displayed (or not being displayed) is not necessarily *HTML*
[12:36:59] <rbarnes_scribe> tlr: there are two things going on here. one is the normative question (what should happen), other is that this is existing, partially deployed header, and documenting that
[12:37:17] <rbarnes_scribe> [ mcr: what else can you put in a <frame> ? ]
[12:37:56] <mcr> can't an <iframe> contain a .png or a .pdf or any content that the browser knows how to natively display?
[12:38:00] <rbarnes_scribe> ekr: could be good in webappsec
[12:39:26] <rbarnes_scribe> tlr: this is fine to do in the ietf
[12:39:34] <rbarnes_scribe> stpeter: this is fine to do here
[12:39:45] <rbarnes_scribe> alexei: we'll do the hum on the mailing list
[12:39:46] <tlr> ekr said: this could be in webappsec, but no energy to drive it. If enthusiasm here, do it here
[12:39:56] <rbarnes_scribe> tobias: CSP header
[12:40:13] <rbarnes_scribe> slides: http://www.ietf.org/proceedings/83/slides/slides-83-websec-4.pdf
[12:40:44] <iljitsch> it's strange that this is in an HTTP header now
[12:40:53] <tlr> iljitsch, it's been in an HTTP header for a while
[12:41:01] <iljitsch> rubber stamping it is a bad precedent (although I'm sure not the first one)
[12:41:21] <iljitsch> it really has nothing to do with the HTTP protocol, it's HTML semantics
[12:41:25] <rbarnes_scribe> slide: CSP - Background
[12:41:54] <rbarnes_scribe> [ iljitsch: you could view it as metadata about the content, like Content-Type or Content-Disposition ]
[12:42:05] <rbarnes_scribe> [ iljitsch: or CSP, heh ]
[12:42:08] <iljitsch> also, this proliferation of http headers is a bad thing, especially ones sent by the client over slow ADSL/cable upstream links
[12:43:04] <hillbrad> fine by me
[12:44:02] <rbarnes_scribe> next topic: current drafts under consideration
[12:44:28] iljitsch leaves the room
[12:44:46] weiyinxing joins the room
[12:45:18] <rbarnes_scribe> jeffh: will rev -framework-reqs soon, please comment
[12:45:44] <rbarnes_scribe> tobias: people promise to read, so we'll continue
[12:45:51] <rbarnes_scribe> alexei: … but hsts is a higher priority
[12:46:28] <rbarnes_scribe> tobias: Who has read -mime-sniff? Several hands
[12:46:51] <rbarnes_scribe> tobias: looking for volunteers to edit
[12:47:40] burn leaves the room
[12:48:06] <rbarnes_scribe> hoffman: seems like there's a lot of disagreement on the list, should think about how to get to consensus
[12:50:06] Dominik Elsbroek leaves the room
[12:50:40] Bran, Cary leaves the room
[12:50:52] Atarashi Yoshifumi leaves the room
[12:50:53] Tom Wesselman leaves the room
[12:50:54] sftcd leaves the room
[12:50:58] tlr leaves the room
[12:51:01] m&m leaves the room: Disconnected: session closed
[12:51:14] SM leaves the room
[12:51:17] weiyinxing leaves the room
[12:51:24] William Chan leaves the room
[12:51:32] rbarnes_scribe leaves the room
[12:51:34] hillbrad leaves the room
[12:52:22] PHB leaves the room
[12:53:09] Thomas Hardjono leaves the room
[12:53:28] kazubu leaves the room
[12:53:54] Andrew Sullivan leaves the room
[12:53:54] Satoru Kanno leaves the room
[12:54:36] =JeffH leaves the room: Logged out
[12:55:00] mcr leaves the room
[12:56:58] Dominik Elsbroek joins the room
[12:57:15] synp leaves the room: Computer went to sleep
[13:00:52] york leaves the room
[13:02:57] wseltzer leaves the room
[13:03:24] William Chan joins the room
[13:03:29] stpeter leaves the room
[13:06:46] rbarnes_scribe joins the room
[13:06:50] rbarnes_scribe leaves the room
[13:07:35] m&m joins the room
[13:09:48] kazubu joins the room
[13:10:28] Satoru Kanno joins the room
[13:10:57] Andrew Sullivan joins the room
[13:12:01] mcharlesr joins the room
[13:13:08] sftcd joins the room
[13:13:41] Satoru Kanno leaves the room
[13:13:42] sftcd leaves the room
[13:14:40] Dominik Elsbroek leaves the room
[13:16:44] cabo joins the room
[13:18:55] woolf joins the room
[13:19:25] William Chan leaves the room
[13:20:50] woolf leaves the room
[13:22:41] Andrew Sullivan leaves the room
[13:36:31] kazubu leaves the room
[13:45:57] Dominik Elsbroek joins the room
[14:03:28] m&m leaves the room
[14:03:38] Dominik Elsbroek leaves the room
[14:23:04] mcharlesr leaves the room
[14:30:52] wseltzer joins the room
[14:31:14] Dominik Elsbroek joins the room
[14:36:27] cabo leaves the room
[14:36:57] tlr joins the room
[14:38:08] wseltzer leaves the room
[14:54:48] mcharlesr joins the room
[14:57:01] mcharlesr leaves the room
[14:58:30] cabo joins the room
[15:20:37] tlr leaves the room
[15:22:06] tlr joins the room
[15:31:27] cabo leaves the room
[15:32:28] cabo joins the room
[17:03:00] Dominik Elsbroek leaves the room
[17:12:03] tlr leaves the room
[17:35:35] cabo leaves the room
[21:27:42] Dominik Elsbroek joins the room
[21:36:40] Dominik Elsbroek leaves the room
[21:37:24] Dominik Elsbroek joins the room
[21:57:47] Dominik Elsbroek leaves the room
[23:28:55] William Chan joins the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!