IETF
pearg
pearg@jabber.ietf.org
Thursday, November 11, 2021< ^ >
Shivan Sahib has set the subject to: PEARG IETF 111 https://codimd.ietf.org/notes-ietf-111-pearg
Room Configuration
Room Occupants

GMT+0
[14:05:43] Meetecho joins the room
[14:06:20] alexamirante joins the room
[14:06:46] alexamirante has set the subject to: PEARG IETF 112
[14:15:03] Paolo Saviano_web_529 joins the room
[14:15:03] Hannes Tschofenig_web_978 joins the room
[14:15:03] Brad Chen_web_712 joins the room
[14:15:03] abdullahalshoaili_web_794 joins the room
[14:15:03] Watson Ladd_web_722 joins the room
[14:15:03] Ching-Heng Ku_web_193 joins the room
[14:15:03] Tobia Castaldi_web_798 joins the room
[14:15:42] Ching-Heng Ku_web_193 leaves the room
[14:17:11] Matthew Finkel_web_809 joins the room
[14:18:36] Antoine Fressancourt_web_126 joins the room
[14:19:02] Steven Valdez_web_994 joins the room
[14:20:19] Sofia Celi_web_424 joins the room
[14:22:40] Tobia Castaldi_web_798 leaves the room
[14:23:21] Kazuaki Ueda_web_520 joins the room
[14:23:25] Luigi Iannone_web_839 joins the room
[14:23:28] Shivan Sahib_web_355 joins the room
[14:23:49] <Shivan Sahib_web_355> Hi all
[14:23:56] <Antoine Fressancourt_web_126> hello
[14:24:12] <npd> 👋
[14:24:30] Nick Doty_web_893 joins the room
[14:24:51] <npd> I can't access the notes doc, fyi
[14:25:15] Matthias Marx_web_452 joins the room
[14:25:26] <Shivan Sahib_web_355> https://notes.ietf.org/notes-ietf-112-pearg
[14:25:39] <Shivan Sahib_web_355> even after logging in via datatracker?
[14:26:32] Nicolas Kuhn_web_413 joins the room
[14:26:37] <npd> now I can, though I don't think I changed anything
[14:26:42] <Shivan Sahib_web_355> strange
[14:26:52] Thom Wiggers_web_578 joins the room
[14:26:53] Christopher Wood_web_757 joins the room
[14:27:19] Andrew Campling_web_545 joins the room
[14:28:00] Kelley Burgin_web_301 joins the room
[14:28:23] Steve Olshansky_web_500 joins the room
[14:28:24] Watson Ladd_web_722 leaves the room
[14:28:28] Watson Ladd_web_828 joins the room
[14:28:30] Michael B_web_396 joins the room
[14:28:33] Michael Bilca_web_372 joins the room
[14:28:39] Jari Arkko_web_111 joins the room
[14:28:41] Zaid AlBanna_web_679 joins the room
[14:28:55] Jiri Novotny_web_365 joins the room
[14:28:59] <Shivan Sahib_web_355> npd: are you volunteering to take notes? :)
[14:29:00] Eric Orth_web_412 joins the room
[14:29:05] James Galvin_web_834 joins the room
[14:29:33] Dan Harkins_web_519 joins the room
[14:29:38] Eric Rescorla_web_599 joins the room
[14:29:48] Bradford Lassey_web_671 joins the room
[14:30:04] Kesara Rathnayake_web_856 joins the room
[14:30:05] Bhavit Shah_web_655 joins the room
[14:30:09] David Oran_web_787 joins the room
[14:30:10] Julien Maisonneuve_web_497 joins the room
[14:30:32] Yuji Suga_web_245 joins the room
[14:30:34] Dan McArdle_web_611 joins the room
[14:30:35] Colin Perkins_web_255 joins the room
[14:30:39] Dirk Kutscher_web_402 joins the room
[14:30:41] Florence D_web_820 joins the room
[14:30:46] Jean-Michel Combes_web_445 joins the room
[14:31:05] David Schinazi_web_677 joins the room
[14:31:07] Tara Whalen_web_311 joins the room
[14:31:11] Taiji Kimura_web_155 joins the room
[14:31:31] <Andrew Campling_web_545> I'm pretty sure some of the other sessions had six behavioral bullets?
[14:31:32] Patrick Tarpey_web_608 joins the room
[14:31:39] Ching-Heng Ku_web_189 joins the room
[14:31:50] Eric Rosenberg_web_146 joins the room
[14:31:53] Alissa Cooper_web_705 joins the room
[14:31:54] Taiji Kimura_web_155 leaves the room
[14:31:56] <npd> (I could do second half, but can't start)
[14:32:07] Samuel Weiler_web_990 joins the room
[14:32:13] <Watson Ladd_web_828> I can do the first part
[14:32:17] <Antoine Fressancourt_web_126> I obviously can't
[14:32:22] Zhe Lou_web_491 joins the room
[14:32:27] Robert Story_web_238 joins the room
[14:32:33] <Watson Ladd_web_828> npd where is the handoff point?
[14:32:46] Joerg Ott_web_443 joins the room
[14:32:59] Bron Gondwana_web_792 joins the room
[14:33:15] Daniel Gillmor_web_440 joins the room
[14:33:15] Wendy Seltzer_web_705 joins the room
[14:33:43] Satoru Kanno_web_917 joins the room
[14:33:44] Nick Banks_web_691 joins the room
[14:34:01] Bron Gondwana_web_792 leaves the room
[14:34:03] Richard Barnes_web_937 joins the room
[14:34:15] Christopher Patton_web_532 joins the room
[14:34:24] Ian Swett_web_108 joins the room
[14:34:35] Alex Chernyakhovsky_web_679 joins the room
[14:34:35] Benjamin Schwartz_web_197 joins the room
[14:34:47] Tommy Jensen_web_440 joins the room
[14:34:47] Michael Hollyman_web_262 joins the room
[14:34:48] Matthew Finkel_web_809 leaves the room
[14:34:54] Christopher Inacio_web_601 joins the room
[14:35:10] Alex Chernyakhovsky_web_679 leaves the room
[14:35:11] Matthew Finkel_web_426 joins the room
[14:35:14] Alex Chernyakhovsky_web_616 joins the room
[14:35:16] <Shivan Sahib_web_355> @Andrew: I took the points from RFC 7154, though I think the other slide I've seen mentions speaking slowly which is a good idea :)
[14:35:42] Vittorio Bertola_web_698 joins the room
[14:36:12] Jeffrey Yasskin_web_698 joins the room
[14:36:14] Jonathan Hoyland_web_238 joins the room
[14:36:20] <Watson Ladd_web_828> slowly=1/2 ekr, at most
[14:36:25] ekr@jabber.org joins the room
[14:37:13] <Jonathan Hoyland_web_238> That definition gives Ekr a great opportunity to DOS people :joy:
[14:37:15] <ekr@jabber.org> Does anyine know what he is citing to with "pixel tracking"
[14:37:58] Benjamin Kaduk_web_175 joins the room
[14:38:07] <Luigi Iannone_web_839> The use of a one pixel picture in html pages/mail
[14:38:25] <Jeffrey Yasskin_web_698> <img src="https://adtech.example/user_saw_this.png">
[14:38:29] Bernie Hoeneisen_web_245 joins the room
[14:38:30] <Matthew Finkel_web_426> "New « Pixel tracking » technique to
bypass cookies limitations"
[14:38:30] dkg joins the room
[14:38:32] <ekr@jabber.org> OK. I was thrown because that technique is like a million years old
[14:38:33] <Luigi Iannone_web_839> The you can track who is downloading that pixel that is not visible by the user
[14:38:36] <Matthew Finkel_web_426> Sounds like the standard
[14:38:44] <ekr@jabber.org> And he referred to it as "new"
[14:38:52] <Bradford Lassey_web_671> What ISPs are deploying VPNs?
[14:38:57] <Brad Chen_web_712> In mature systems, the right to privacy is complemented by responsibilities, for example, responsibility to obey the law. What responsibilities should apply online? Anybody interested in considering responsibilities?
[14:39:07] <Watson Ladd_web_828> someone is not a Verizon customer
[14:39:07] <ekr@jabber.org> I am not aware of any ISPs deploying VPNs
[14:39:22] Allison Mankin_web_362 joins the room
[14:39:29] <Vittorio Bertola_web_698> @ekr In general this discussion often seems frozen in 2013. Like, "a certain guy named Snowden just revealed that...".
[14:39:34] Joey Salazar_web_878 joins the room
[14:39:41] Juan-Carlos Zúñiga_web_952 joins the room
[14:39:47] <Benjamin Schwartz_web_197> Google Fi VPN :)
[14:39:52] kaduk@jabber.org/barnowl joins the room
[14:39:58] <dkg> has the surveillance on the internet gotten better or worse since 2013?
[14:39:58] <ekr@jabber.org> Google is a search company with an ISGP :)
[14:40:21] <dkg> i'm pretty sure google is an advertising company which also offers search
[14:40:31] <Vittorio Bertola_web_698> @dkg: possibly worse, but possibly also due to actors other than governments (IMHO)
[14:40:33] <ekr@jabber.org> Fair enough @dkg
[14:40:48] <Jonathan Hoyland_web_238> @dkg Well they've been "going dark" since then, so hopefully better for us.
[14:40:49] Yuji Suga_web_245 leaves the room
[14:40:49] <Andrew Campling_web_545> At least one ISP is testing quantum-secure network connections
[14:40:50] <Luigi Iannone_web_839> AFAIK DT offers VPN service to their customers, Orange offers VPN services to enterprise customers
[14:40:52] <ekr@jabber.org> @dkg: is "better" == "more soophisticaed"
[14:40:53] Yuji Suga_web_146 joins the room
[14:40:57] <Vittorio Bertola_web_698> @dkg Facebook is also an advertising company which also offers social media and messaging :)
[14:41:04] <npd> I have heard that many non-US countries have ISPs that don't constantly surveil their own customers, but it's maybe just a rumor
[14:41:27] <ekr@jabber.org> @Brad Lasse, isn't "gnatcatcher" just the NAT thing? Hence the name
[14:41:33] Phillip Hallam-Baker_web_544 joins the room
[14:41:39] <Watson Ladd_web_828> they have ISPs that say they don't, but get very mad when people take away their visibility into the data they swear they aren't using
[14:41:45] <Andrew Campling_web_545> GDPR comes into play in Europe at least
[14:41:46] <Jonathan Hoyland_web_238> Some ISPs outside the US surveil their customers by law.
[14:41:48] Yuji Suga_web_146 leaves the room
[14:41:58] <ekr@jabber.org> There's plenty of evidence that ISPs do commercial surveillance
[14:42:12] <ekr@jabber.org> At least in the US
[14:42:16] Phillip Hallam-Baker_web_544 leaves the room
[14:42:22] <dkg> +1 Watson
[14:42:24] <npd> definitely in the US, yes
[14:42:27] Craig Pearce_web_388 joins the room
[14:42:35] <Andrew Campling_web_545> @ekr It would be good if this was shared at some point as it keeps being asserted at the IETF but without evidence
[14:42:39] Stephen Farrell_web_861 joins the room
[14:42:39] <Vittorio Bertola_web_698> Yes, part of the problem is that the threat model in the real world is significantly different depending on where you are from
[14:42:49] Sara Dickinson_web_224 joins the room
[14:42:56] Renan Krishna_web_676 joins the room
[14:42:58] <ekr@jabber.org> @campling: uh, it's in the newspaper?
[14:43:05] <Watson Ladd_web_828> @Andrew: read Verizon's privacy policy. They say exactly what they are doing
[14:43:10] <Bradford Lassey_web_671> ekr, gnatcatcher is a combination of a proxy (or NAT) with a policy-based opt-out
[14:43:16] <Jeffrey Yasskin_web_698> ekr: https://github.com/bslassey/ip-blindness
[14:43:23] <Jonathan Hoyland_web_238> TOR isn't technically the best you can do.
[14:43:32] Yuji Suga_web_479 joins the room
[14:43:35] <ekr@jabber.org> @jeff, yes, I know the link, but it's not clear to me what the branding is
[14:43:37] <npd> FTC just published an extensive report about what US ISPs are doing: https://www.ftc.gov/news-events/press-releases/2021/10/ftc-staff-report-finds-many-internet-service-providers-collect
[14:43:41] <Wendy Seltzer_web_705> it's Tor, not TOR :)
[14:43:42] <Jonathan Hoyland_web_238> There are more secure solutions, but they aren't very useable.
[14:43:45] <ekr@jabber.org> Thanks @npd.
[14:43:50] Stephen Farrell_web_861 leaves the room
[14:43:50] <Andrew Campling_web_545> @ekr remember the US market model is not common to everyone else
[14:43:53] <ekr@jabber.org> Thanks npd.
[14:43:54] Stephen Farrell_web_610 joins the room
[14:43:56] <kaduk@jabber.org/barnowl> It's not ToR (top of rack), either :)
[14:43:56] <Bradford Lassey_web_671> so, traffic is proxied by default, but servers that agree to a policy get direct connections
[14:44:10] <dkg> npd++
[14:44:11] <Vittorio Bertola_web_698> For example, yesterday I was in a European Commission meeting where everybody seemed to agree that Apple Private Relay could potentially be the opposite of "more privacy", depending on conditions
[14:44:17] <ekr@jabber.org> @Andrew: I didn't say that all ISPs did it. I said ISPs did it.
[14:44:20] <ekr@jabber.org> And some do.
[14:44:23] Bernie Hoeneisen_web_245 leaves the room
[14:44:27] Bernie Hoeneisen_web_781 joins the room
[14:44:37] <Watson Ladd_web_828> yes, if you assume collusion between two parties, vs. isps (one party) breaking their rules
[14:44:38] Craig Pearce_web_388 leaves the room
[14:44:42] Craig Pearce_web_240 joins the room
[14:44:54] <Alissa Cooper_web_705> the parties concerned about apple private relay must be losing access to something valuable to them, then
[14:44:58] <ekr@jabber.org> Or, as Watson says, just doing what their rules says
[14:45:17] <Shivan Sahib_web_355> curious about the concerns with apple private relay
[14:45:26] <dkg> it would be great to see other government agencies (outside the US) do a similar report to the FTC's report for their jurisdiction
[14:45:40] <Christopher Wood_web_757> +1 dkg
[14:45:49] <dkg> Shivan: one concern is that it gives apple visibility that they wouldn't otherwise have
[14:45:50] <Andrew Campling_web_545> @Alissa Yes, for example the ability to optimise traffic flows, utilise CDNs etc
[14:46:00] <Vittorio Bertola_web_698> @Alissa: you seem to say that anyone complaining about potential loss of privacy is just worried of not being able to do the same...
[14:46:11] Yuji Suga_web_479 leaves the room
[14:46:15] Yuji Suga_web_239 joins the room
[14:46:24] <ekr@jabber.org> @dkg: well, Private Relay seems to be generally well designed to minimize what Apple learns, but yes
[14:46:31] <npd> +1 dkg, I would like reports on ISP practices in other countries as well
[14:46:33] <Alissa Cooper_web_705> yes
[14:46:33] <Watson Ladd_web_828> i don't see why ISPs saying "trust us" is a good protection versus technical means
[14:46:38] <Matthew Finkel_web_426> For Private Relay, are there more concerns than collusion between the two nodes?
[14:46:42] Mihail Zverev_web_143 joins the room
[14:46:52] <Benjamin Schwartz_web_197> @Watson I don't think a non-collusion requirement qualifies as a technical means.
[14:46:53] Yuji Suga_web_239 leaves the room
[14:46:55] <npd> (as I say, it seems different from the US, but mostly seems to come down to rumor or common knowledge)
[14:46:57] Yuji Suga_web_855 joins the room
[14:47:07] <Andrew Campling_web_545> @Matthew Yes, for example lack of discovery of proxies
[14:47:10] <Watson Ladd_web_828> @Ben: would Tor count?
[14:47:26] <dkg> Tor also has a non-collusion requirement in its threat model
[14:47:29] Peter Koch_web_134 joins the room
[14:47:32] <Watson Ladd_web_828> @Andrew: do you have a workable discovery proposal?
[14:47:33] <Vittorio Bertola_web_698> @Shivan: the concern is that until now you get an iPhone and send your packets to whatever service you want to access (separate packets to separate services). Now, under that model, all your packets go first through Apple and then through an Apple contractor.
[14:47:46] <Benjamin Schwartz_web_197> @Watson: It's an interesting question.
[14:47:51] <Alex Chernyakhovsky_web_616> APR is opt-in, though
[14:47:51] <Matthew Finkel_web_426> @Andrew okay, so you need to trust Apple...which you need to do anyway because they own the device
[14:48:01] <Vittorio Bertola_web_698> Incidentally, that is likely to make Apple a telco, but I will leave this to the European Commission :)
[14:48:06] <dkg> ahem: you still own your own device
[14:48:07] <Shivan Sahib_web_355> same concern as with a VPN, no?
[14:48:29] <Andrew Campling_web_545> @Matthew To be fair, I own the device, Apple designed it + the os etc, but I know what you mean
[14:48:30] <Shivan Sahib_web_355> less so because of proxy
[14:48:42] Kris Shrishak_web_897 joins the room
[14:48:49] <ekr@jabber.org> let's distinguish between "I have to trust that the software on the iphone isn't cheating" and "I have to trust that Apple's servers aren't cheating"
[14:48:50] <Matthew Finkel_web_426> @Andrew right, sure :)
[14:49:08] <ekr@jabber.org> Private relay is designed to minimize the risk of (2) but the design of Apple's devices precludes (1)
[14:49:19] <ekr@jabber.org> One could imagine deploying Private Relay iwth open source clients, however.
[14:49:25] <ekr@jabber.org> (Which is sorta kinda what Tor is)
[14:49:32] <Matthew Finkel_web_426> ekr: agreed
[14:49:34] <Vittorio Bertola_web_698> I would feel much better if the software involved were open, yes
[14:50:04] <dkg> ekr: "precludes" or "requires" ?  i think you mean that Apple's proprietary design *requires* iOS users to trust that the local software is not cheating.
[14:50:18] <Vittorio Bertola_web_698> But still, the collusion risk is materially impossible for users to control
[14:50:26] <ekr@jabber.org> @dkg: yes, that's whatI mean
[14:50:37] <Alex Chernyakhovsky_web_616> note that even if the server implementations were open, there is currently no technological soluition for an end-user to verify the server they are communicating with is in fact running that code
[14:50:52] <Watson Ladd_web_828> The risk of ISPs maintaining logs and selling data is also impossible for users to control.
[14:50:54] <ekr@jabber.org> @Alex: yes that's correct.
[14:51:00] <Vittorio Bertola_web_698> I would also feel better if users chose at least one of the proxies, not the device maker
[14:51:15] Craig Pearce_web_240 leaves the room
[14:51:19] Craig Pearce_web_708 joins the room
[14:51:28] <Andrew Campling_web_545> Private Relay also gifts significant intel to the CDN partners and has implications for centralisation, resilience etc
[14:51:32] <Richard Barnes_web_937> Vittorio: I look forward to your UX proposal
[14:51:39] <ekr@jabber.org> As I said yesterday in PRIV, the current situation involves an enormous amount of trust in people. These designs are incremental steps towards makig the number of people you have to trust smaller.
[14:51:41] <kaduk@jabber.org/barnowl> If the source is responsible for setting up the source routing, does
that require the full topology to be public?
[14:51:52] <ekr@jabber.org> To complaint that you still have to trust people makes the best the enemy of the good
[14:52:13] <dkg> ekr: some of them are incremental steps toward making the number of people you have to trust *larger*, but with *less* trust in each, no?
[14:52:15] whalen@jabber.org joins the room
[14:52:31] <kaduk@jabber.org/barnowl> I am also not really clear on what benefit is gained from offering
users a choice of proxy.
[14:52:41] <Alex Chernyakhovsky_web_616> today you have to trust all entities across which your traffic routes
[14:52:46] <ekr@jabber.org> @dkg: yes, that's fair
[14:52:54] <kaduk@jabber.org/barnowl> That is, the destination server has a veto over what proxies are
acceptable -- if the server wants to misbehave, they will require all
acceptable proxies to misbehave.
[14:53:01] <dkg> you can make the number of people you have to trust as small as 1 if you just pledge fealty to your overlord and let them handle it all
[14:53:09] <Andrew Campling_web_545> @Kaduk For a start, it removes an element of control from the client
[14:53:20] <Vittorio Bertola_web_698> @ekr: There is another fundamental clash of cultures here. In the US apparently privacy is a product you get, so tech company makers are expected to control and provide privacy for you. In Europe, privacy is a right that you enjoy and that you, and no one else, must control in first person.
[14:53:24] <ekr@jabber.org> Well, once again, the *client* does control it. It's just that the client was wirtten by Apple
[14:53:27] <dkg> but a feudal outcome is not really what i'm aiming for
[14:53:57] <dkg> (or what i think we should all be aiming for)
[14:54:01] <ekr@jabber.org> @Vittorio: but you actually don't get that because the ISPs actually do participate in government surveillance
[14:54:01] <Watson Ladd_web_828> Vittoro, do you think Apple isn't also subject to the same GPDR rules?
[14:54:04] <Richard Barnes_web_937> @Vittorio - Users are not engineers, so presumably there's some software acting on the user's behalf.
[14:54:19] <kaduk@jabber.org/barnowl> @Andrew: Please clarify what control this is.  I am interpreting your
position as assuming that some server wants to misbehave, and that
user choice of proxy will be a defense against that misbehavior.  Is
that an incorrect interpretatin of your position?
[14:54:28] <Alissa Cooper_web_705> somehow I didn't notice this difference living in Europe versus the US
[14:54:32] <ekr@jabber.org> More generally, I prefer technical controls to policy controls
[14:54:35] <dkg> even engineer users are trusting their software at some level
[14:54:40] <Vittorio Bertola_web_698> Yes, but the European principle is that I (the user) get to decide which parties can get my data. That is why there is an expectation for users to be able to choose the parties on the path.
[14:54:59] tim costello_web_437 joins the room
[14:55:02] <Andrew Campling_web_545> @ekr bear in mind that, thanks to the US CLOUD Act and FISA 702, non-US citizens have no privacy rights from US law enforcement agencies for services operated by US companies
[14:55:18] <ekr@jabber.org> @Vittorio: I await a European version of Private Relay
[14:55:28] Alex Chernyakhovsky_web_616 leaves the room
[14:55:32] Alex Chernyakhovsky_web_370 joins the room
[14:55:59] <Vittorio Bertola_web_698> @ekr: if there is a way to provide it, I guess there could be parties in Europe that would provide alternative proxies for Apple Private Relay users that prefer them
[14:55:59] <dkg> Andrew: if you're arguing that the US legal regime is problematic for non-US persons, you'll get very few counterarguments
[14:56:02] <Dan Harkins_web_519> bring back anon.funet.fi
[14:56:09] <Richard Barnes_web_937> @Vittorio: You expect users to understand the network topology?
[14:56:11] <Alex Chernyakhovsky_web_370> I do not believe there is any reason to believe an EU deployment will inherently be more trustworthy
[14:56:24] whalen@jabber.org leaves the room
[14:56:36] Benjamin Schwartz_web_197 leaves the room
[14:56:40] Benjamin Schwartz_web_551 joins the room
[14:56:52] <Vittorio Bertola_web_698> @Alex: that's what most Brussels institutions think, though, as it would be covered by GDPR and not subject to the CLOUD Act
[14:56:56] <Alex Chernyakhovsky_web_370> if you don't like the N internet companies approach, why would you like a governmental entity (which will probably contract out anyway)
[14:57:09] whalen@jabber.org joins the room
[14:57:19] <Alex Chernyakhovsky_web_370> I think that's a very nationalistic approach that is not grounded in reality
[14:57:20] <Andrew Campling_web_545> @Kaduk Discovery makes it possible for a far more diverse ecosystem of ingress and egress proxies, to use Apple's nomenclature, to evolve.  Greater choice, driven by the user seems to me to be a good thing, is more consistent with RFC 8890
[14:57:26] <Watson Ladd_web_828> @Andrew: non-US citizens have even less rights with data not stored by US companies, just as French intelligence spies on people worldwide. So maybe instead of rules, we need to cut down on access.
[14:57:34] Benjamin Schwartz_web_551 leaves the room
[14:57:38] Benjamin Schwartz_web_596 joins the room
[14:57:51] Luigi Iannone_web_839 leaves the room
[14:57:53] <Watson Ladd_web_828> Discovery: where is the concrete proposal to solve it
[14:57:55] Luigi Iannone_web_286 joins the room
[14:58:01] <Vittorio Bertola_web_698> One of the concerns is: what if an U.S. agency goes to the providers of the two proxies and forces them to collude and trace specific non-US users under the CLOUD Act?
[14:58:05] <Benjamin Schwartz_web_596> @Watson: www.google.com
[14:58:17] <kaduk@jabber.org/barnowl> @Andrew: are you assuming there is a server that wants to misbehave,
or not?  "Diversity" is not useful if all elements of the diverse
population are forced to misbehave.
[14:58:24] Luigi Iannone_web_286 leaves the room
[14:58:28] Luigi Iannone_web_109 joins the room
[14:58:31] <Richard Barnes_web_937> @Vittorio is that easier or harder than going to a single provider in an un-proxied solution?
[14:58:59] <Alex Chernyakhovsky_web_370> Seems like it should be harder by construction
[14:59:11] <Richard Barnes_web_937> @Alex - that is my point :)
[14:59:12] <Alex Chernyakhovsky_web_370> and if that is  not the case we have made technological errors in the design
[14:59:13] <Jeffrey Yasskin_web_698> We have an existence proof for user choice in the DoH provider settings in Firefox, Chrome, and Edge. It's plausible to do the same for the OHAI systems. Client software will still need to pick a good default.
[14:59:15] <ekr@jabber.org> I certainly agree that the situation in the US re: surveillance is not ideal, but against the backdrop of the proposed eIDAS QWAC mandates, I don't find the argument that somehow Europe is a utopia for user privacy against the government particularly persuasive
[14:59:30] <Andrew Campling_web_545> @Kaduk True, however having an open ecosystem makes it more likely that one or more of the parties will share details of any prescribed misbehavior
[14:59:35] <dkg> any one of the forced proxies has an opportunity to object, to give notice, to shut down, or to start a legal fight.  increasing the number that needs to be forced to get effective surveillance seems like a useful speedbump.
[14:59:38] <David Oran_web_787> Naïve q: for the AS path-based approaches, what about privacy for traffic that never leaves the source AS?
[14:59:52] <Watson Ladd_web_828> unless the parties are run by the people misbehaving.
[14:59:54] <npd> @yasskin, I would love to see a summary somewhere of the UI/UX choices for DoH providers, and how it's working
[15:00:04] <Vittorio Bertola_web_698> A single provider would not get all your traffic. Except perhaps your ISP, which, if you're in Europe, is not subject to the CLOUD Act.
[15:00:16] <Richard Barnes_web_937> @Oran - one might presume that there's not much point to privacy with an AS, since presumably an AS is under unitary control?
[15:00:25] <Jonathan Hoyland_web_238> Just because my explanation wasn't that clear this is what I was referring to. https://petsymposium.org/2020/files/papers/issue3/popets-2020-0056.pdf
[15:00:52] <Jeffrey Yasskin_web_698> npd: I don't have the data for how often it gets changed. You can look at the UI by searching for 'dns' in the browser settings.
[15:01:02] <ekr@jabber.org> @jeffey: at least in Fx, rarely
[15:01:22] <kaduk@jabber.org/barnowl> @Andrew: because of the way in which the server has to trust the
proxy, I think we can at best (with current technology) get a "half
open" ecosystem, and it's not very clear to me to what extent it would
provide the property you want
[15:01:33] <Jeffrey Yasskin_web_698> And I'd expect the same for OHAI proxy choice.
[15:01:37] <Brad Chen_web_712> Is there an update to the agenda?
[15:01:52] <David Oran_web_787> @richard - well, if my first hop ToR router is in my home router? Also, it's likely that Akamai and Cloudflare have CDN nodes in just about every AS and grab tyour traffic directly?
[15:02:05] <dkg> it's Tor, not ToR ☺
[15:02:11] <Richard Barnes_web_937> @oran - yeah, i don't know the real answer, just speculating
[15:02:13] <Matthew Finkel_web_426> route at the top of the rack
[15:02:14] <ekr@jabber.org> I think it's tOR
[15:02:18] <Matthew Finkel_web_426> *router
[15:02:23] <Richard Barnes_web_937> tOr
[15:02:33] <dkg> keep going, we've almost got all the permutations
[15:02:38] <David Oran_web_787> Interesting stuff - but I have to bail to get onto a Hotnets session...
[15:02:38] <Richard Barnes_web_937> transmitter Onion receiver
[15:02:44] David Oran_web_787 leaves the room
[15:03:34] <Richard Barnes_web_937> i would question whether we even need resolvers in the modern world.  *that* would be a research project!
[15:03:50] <Watson Ladd_web_828> /etc/hosts is there for you
[15:04:38] <Richard Barnes_web_937> for example, in the web context, you could disseminate DNS information alongside links
[15:04:41] <Alex Chernyakhovsky_web_370> a return to arpanet: the hosts file is downloaded locally daily
[15:04:57] <Richard Barnes_web_937> @Alex modern take -- put it on a blockchain!
[15:05:02] <Jeffrey Yasskin_web_698> The poor website maintainers...
[15:05:13] <Alex Chernyakhovsky_web_370> I'm sure the bitcoin and etherium people would (genuinely) love that
[15:05:20] <Watson Ladd_web_828> see also .eth
[15:05:59] <dkg> Barnes: see the "dns off the back of a truck" discussion that we started back before the pandemic
[15:06:02] <Benjamin Schwartz_web_596> @Richard: https://lists.w3.org/Archives/Public/ietf-http-wg/2018JulSep/0050.html
[15:06:16] <Watson Ladd_web_828> If that's the definition of tee, i don't think any exist
[15:06:46] <Hannes Tschofenig_web_978> TrustZone would do that
[15:07:52] <dkg> this would require the RNG to be part of the TEE as well, right?
[15:08:04] <Watson Ladd_web_828> I'm not familiar enough with what TrustZone provides: I know SGX fell to side channel attacks
[15:08:24] <kaduk@jabber.org/barnowl> A TEE integrated with the CPU would be able to run RDRAND (or
analogous) natively, I think
[15:08:24] <dkg> otherwise, the source of entropy for the encrypted transport could be compromised
[15:08:24] <ekr@jabber.org> Yeah, all the evidence is that SGX is catastrophically insecure against a dedicated attacker
[15:08:41] <ekr@jabber.org> @DKG: or you could just run OHAI-type thing to the enclave
[15:08:45] <Hannes Tschofenig_web_978> There is, of course, the ideal what the TEEs are supposed to provide and then how the implementations actually look like
[15:09:10] <Jeffrey Yasskin_web_698> We have to run our software and defend against attackers on the implementations rather than the ideals. ;)
[15:09:35] <ekr@jabber.org> And recall that more or less by definition this runs in  the infrastructure of a very sophisticated attacker
[15:09:50] <Vittorio Bertola_web_698> Is this the latest incarnation of the "Trusted Computing" concept that in 2003 was meant to prevent us all from playing DVDs on Linux?
[15:09:55] <Watson Ladd_web_828> yes
[15:10:00] <ekr@jabber.org> Yes.
[15:10:11] <dkg> DVDoverDNS
[15:10:19] <Vittorio Bertola_web_698> Has it ever worked in these last 18 years?
[15:10:24] <ekr@jabber.org> No
[15:10:36] <Vittorio Bertola_web_698> Ok, thanks for the update.
[15:10:37] <dkg> DRM does "work" in the sense of increasing friction a little bit
[15:10:54] <dkg> it does *not* work in terms of absolute prevention of data leaks
[15:10:55] <ekr@jabber.org> Yes, that's the level of attacker it works aganst
[15:10:59] Juliana Guerra_web_686 joins the room
[15:11:07] David Oliver_web_140 joins the room
[15:11:56] <Jeffrey Yasskin_web_698> Could use of TEE be helpful for an auditor trying to check that data isn't used inappropriately, since breaking the TEE would be clearly intentional and malicious? Or can auditors check for inappropriate data use easily enough anyway?
[15:11:57] <Jonathan Hoyland_web_238> So more script-kiddie annoyance than strong protection?
[15:12:00] <npd> is that a different level of advertising than advertising to your users that you promise not to do this?
[15:12:15] <ekr@jabber.org> @Jeffrey: the problem is that the TEE breaks involve key extraction
[15:12:16] <Richard Barnes_web_937> channelling Eliot Lear -- doesn't the lack of user-level data here hinder defenses against malicious uses of the DNS?
[15:12:16] <dkg> does anyone think that it would be worse for a recursive resolver to run within a TEE than not in a TEE?
[15:12:39] Dan McArdle_web_611 leaves the room
[15:12:40] <ekr@jabber.org> no, I just don't think it does much
[15:12:43] Dan McArdle_web_803 joins the room
[15:12:47] <Jonathan Hoyland_web_238> I'm sure SysAdmins would be "going dark".
[15:12:52] <ekr@jabber.org> and is a distraction from better systems like ODoH
[15:12:53] <Alex Chernyakhovsky_web_370> My personal view that running network services in a TEE doesn't add much value because you naturally have an observer outside the TEE
[15:13:05] <dkg> ¿por que no los dos?
[15:13:07] <Benjamin Schwartz_web_596> Lots of stuff relies on Hardware Security Modules.  They're not unbreakable but they've really gotten pretty strong.
[15:13:07] <Alex Chernyakhovsky_web_370> so if metadata is valuable, the TEE isn't adding value
[15:13:16] <Richard Barnes_web_937> you would need to tunnel the TLS to the TEE, verify the attestation, ....
[15:13:28] <Watson Ladd_web_828> HSMs have a very limited interface to be secure
[15:13:32] <Hannes Tschofenig_web_978> This is our latest TEE development: https://www.arm.com/why-arm/architecture/security-features/arm-confidential-compute-architecture
[15:13:37] <Alex Chernyakhovsky_web_370> the question to answer is not "is the TEE better than not-TEE", the question is "what properties do we get with the TEE and how do they play with our threat model"
[15:13:40] <Watson Ladd_web_828> a TEE, especially one on shareded hardware is much bigger
[15:13:44] <Richard Barnes_web_937> @dkg - why not both bc limited engineering resources in the world
[15:13:44] <Jonathan Hoyland_web_238> To be fair it took me _ages_ to get Secure Boot working on Arch.
[15:13:59] <Hannes Tschofenig_web_978> @Richard: Tunneling TLS into the TEE -- we do that. https://archive.fosdem.org/2021/schedule/event/tee_veracruz/
[15:14:05] <Jonathan Hoyland_web_238> So it's at least me resistant.
[15:14:25] <Richard Barnes_web_937> @Hannes - totally agree that it's possible, it's just more complext than Jari's preso might make you think
[15:14:44] <Andrew Campling_web_545> @Alex:  Surely To TEE or not to TEE, that is the question. ;-)  
[15:14:46] <ekr@jabber.org> Either the cache needs to be in the TEE, or you need like PIR to the cahce
[15:14:51] <Jiri Novotny_web_365> Tunneling TLS to TEE was shown on the diagram and is done generally in many implementations
[15:14:56] <Shivan Sahib_web_355> AWS ec2 has nitro enclaves now
[15:15:00] Jonathan Lennox_web_672 joins the room
[15:15:13] <Hannes Tschofenig_web_978> @Richard: There have been efforts to make it easier to write software for the TEE. In the past, that hasn't been easy...
[15:15:14] <Richard Barnes_web_937> like you can't just take the code and run it in a TEE, to get the benefit you also need to change the protocol and the clients
[15:15:17] <ekr@jabber.org> IIRC those enclaves are secured by the "Amazon promiss" technique
[15:15:28] <ekr@jabber.org> *promises
[15:15:30] <Richard Barnes_web_937> yeah iirc nitro is software
[15:15:38] <npd> would the TEE be a way to more easily prove your privacy status to Mozilla or another UA who requires a certain policy to be included in the list of recommended resolvers?
[15:15:50] <Jiri Novotny_web_365> @richard yes it is more complex than Jari presented and we're happy to discuss it. This meeting didn't seem like a right place to go to technical details of TEE implementations
[15:15:52] <ekr@jabber.org> Well, for the reasons above, it wouldn't help us.
[15:16:06] Shu-Fang Hsu_web_437 joins the room
[15:16:13] <Watson Ladd_web_828> I think once you put enough things out to help debugging, you have enough to have a problem
[15:16:23] <dkg> Watson++
[15:16:38] <Hannes Tschofenig_web_978> @Richard: > like you can't just take the code and run it in a TEEIn general, you cannot do that. But if you look at the CCC then you will see that there are different approaches for running software in the TEE. This is quite a heavy research activity right now
[15:16:40] <ekr@jabber.org> @Watson: maybe a ZKP of correct behavior for debugging
[15:16:58] <Jeffrey Yasskin_web_698> Just write correct code the first time.
[15:17:05] <Jonathan Hoyland_web_238> Or just do debugging on simulated hardware maybe?
[15:17:17] <Watson Ladd_web_828> you end up needing to know example.com is not being resolved by users in this place: can be due to authoritiative issues
[15:17:33] <ekr@jabber.org> @Jeffrey: correct, write it in Rust
[15:17:49] <Jiri Novotny_web_365> indeed, writing implementations specifically for TEE is a crucial step. just Graphene resolver works, but it aint good
[15:18:19] Eric Rescorla_web_599 leaves the room
[15:18:22] <Watson Ladd_web_828> think zone suicide+client caching issue for instance
[15:18:23] Eric Rescorla_web_964 joins the room
[15:18:28] <Benjamin Schwartz_web_596> TEE isn't perfect, but it seems like a stronger level of security than "we passed an audit last year".
[15:18:32] <Watson Ladd_web_828> or geodns authoriattive not working
[15:18:34] <ekr@jabber.org> not really no.
[15:18:36] <Shivan Sahib_web_355> I think we have time for one q
[15:18:54] whalen@jabber.org leaves the room
[15:19:56] <Christopher Wood_web_757> @Ben: why ORAM? Who needs to write?
[15:20:03] <ekr@jabber.org> The cache, no?
[15:20:12] <Alex Chernyakhovsky_web_370> if I understood Ben correctly a caching resolver would have its RAM patterns indicative of query responses
[15:20:14] <Benjamin Schwartz_web_596> @Christopher: It's really about the reads from cache.
[15:20:20] <Richard Barnes_web_937> to answer the question on the slide: not sci-fi, just not all that useful, especially compared to other techniques
[15:20:58] whalen@jabber.org joins the room
[15:21:08] <Jeffrey Yasskin_web_698> Well, sci-fi in the sense that if a TEE existed, this would be cool, but all the TEE attempts have been broken.
[15:21:20] Tadahiko Ito_web_563 joins the room
[15:21:29] <Alex Chernyakhovsky_web_370> SGX is super fun because Intel says side-channels are outside of the threat
[15:21:31] <Richard Barnes_web_937> @Jeffrey - even then, the prerequisites are pretty killer for actual deployment
[15:21:37] <Jeffrey Yasskin_web_698> Fair enough
[15:21:41] <kaduk@jabber.org/barnowl> Would be nice to hear Ekr say something about how the ARM stuff
compares to SGX...
[15:21:44] <Benjamin Schwartz_web_596> @Alex: Wait, what?
[15:21:52] <Alex Chernyakhovsky_web_370> Yup, go read the Intel whitepaper on SGX
[15:21:57] <Christopher Patton_web_532> DRM applications still use trusted computing platforms, right?
[15:22:01] <Alex Chernyakhovsky_web_370> they consider side channel attacks and glitching attacks outside of teh threat model scope for SG X
[15:22:07] <Benjamin Schwartz_web_596> Yikes
[15:22:18] <Watson Ladd_web_828> but the signing was in the enclave-> total loss
[15:22:25] <Alex Chernyakhovsky_web_370> but they have pushed microcode fixes to some sidechannels/glitching attachs, which also ruined my ability to undervolt my laptop cpu :(
[15:23:01] <ekr@jabber.org> Sorry, I don't know much about the ARM stuff
[15:23:14] Chi-Jiun Su_web_715 joins the room
[15:23:22] <Richard Barnes_web_937> i assume given Hannes' involvement that the ARM stuff is much better :)
[15:23:40] <Hannes Tschofenig_web_978> Thanks, Richard. I paid you enough to say that
[15:24:34] Philip Eardley_web_275 joins the room
[15:25:45] <Watson Ladd_web_828> https://github.com/tfpauly/privacy-proxy/issues/96 this might be of interest to you
[15:26:34] <Jari Arkko_web_111> :-) i'm sure there's competition to better in this space. But, what Benjamim said at earlier in the chat: not perfect, but better than trusting $BIGCORP without anything. Or reading a report that they passed an audit last year. Also, much better than on purpose passing data to the advertisers which seems to be the business model for many Internet players.
[15:27:36] <Benjamin Schwartz_web_596> I think TEE is interesting enough to be a fun research topic, but I agree that the hardware isn't strong enough to warrant the effort required for standardization.
[15:27:36] Chen Li_web_173 joins the room
[15:28:01] <Hannes Tschofenig_web_978> @Benjamin: Do you know the latest hardware?
[15:28:04] Dan McArdle_web_803 leaves the room
[15:28:08] Dan McArdle_web_451 joins the room
[15:28:13] <Benjamin Schwartz_web_596> In particular, standardization requires freezing and standardizing specific binaries across the whole internet, which is very brittle.
[15:28:18] Nicolas Kuhn_web_413 leaves the room
[15:28:27] <Hannes Tschofenig_web_978> Why is that?
[15:28:31] <Richard Barnes_web_937> lol "very brittle" seems like quite the understatement
[15:29:10] <Jeffrey Yasskin_web_698> Hannes: How long has the latest hardware stood up to attackers?
[15:29:11] <Shivan Sahib_web_355> we're planning to call for adoption of this draft
[15:29:22] <Shivan Sahib_web_355> so if folks have opinions those would be appreciated
[15:29:29] <Bradford Lassey_web_671> Hannes, I'd be interested in pointers that show that the latest hardware is better than what ekr described
[15:29:34] <Jari Arkko_web_111> No, it wouldn't require that... standards require protocols to talk between parties, and ability to pass data. You do need someone to bless a particular open source version and compilation as checked, but that's a data-level thing, not a standards level thing. Kind of like cert formats vs. what certs CAs issue.
[15:29:48] <Hannes Tschofenig_web_978> @Jeffrey: Not long, obviously, because it is new stuff.
[15:30:06] <Hannes Tschofenig_web_978> Happy to put a reading list together of what we have been working on in Arm.
[15:30:12] <Richard Barnes_web_937> @Jari you still need all the resolver's clients to be OK with the resolver's software
[15:30:12] <Jonathan Hoyland_web_238> @Hannes I think he means, what is the oldest unbroken thing?
[15:30:26] <Watson Ladd_web_828> @Matt: this sounds like a much bigger effort than just one draft
[15:30:29] <Benjamin Schwartz_web_596> @Jari: Sure.  Then instead of pinning binaries, you need to build a trusted ecosystem of parties who approve the source code and pin binaries.
[15:30:36] <npd> where should we send questions about the IP address privacy draft?
[15:30:37] Benjamin Kaduk_web_175 leaves the room
[15:30:46] <Bradford Lassey_web_671> list is fine
[15:30:49] Jeffrey Yasskin_web_698 leaves the room
[15:30:50] <Bradford Lassey_web_671> or file issues
[15:30:51] Zaid AlBanna_web_679 leaves the room
[15:30:56] <Jari Arkko_web_111> @Richard yes and for that you could find a trusted party - a Verifier perhaps - to make that determination.
[15:31:00] abdullahalshoaili_web_794 leaves the room
[15:31:02] Kelley Burgin_web_301 leaves the room
[15:31:03] Tara Whalen_web_311 leaves the room
[15:31:03] Steve Olshansky_web_500 leaves the room
[15:31:03] Dan Harkins_web_519 leaves the room
[15:31:03] Florence D_web_820 leaves the room
[15:31:06] <Richard Barnes_web_937> yet another party to trust!
[15:31:06] Kris Shrishak_web_897 leaves the room
[15:31:07] <Hannes Tschofenig_web_978> Thanks
[15:31:07] David Oliver_web_140 leaves the room
[15:31:10] <Antoine Fressancourt_web_126> Thanks
[15:31:11] Jonathan Hoyland_web_238 leaves the room
[15:31:11] Colin Perkins_web_255 leaves the room
[15:31:12] Yuji Suga_web_855 leaves the room
[15:31:13] Andrew Campling_web_545 leaves the room
[15:31:13] Christopher Inacio_web_601 leaves the room
[15:31:13] Chi-Jiun Su_web_715 leaves the room
[15:31:14] Richard Barnes_web_937 leaves the room
[15:31:15] Christopher Wood_web_757 leaves the room
[15:31:15] Dan McArdle_web_451 leaves the room
[15:31:17] Kesara Rathnayake_web_856 leaves the room
[15:31:17] Shu-Fang Hsu_web_437 leaves the room
[15:31:18] Tadahiko Ito_web_563 leaves the room
[15:31:20] Steven Valdez_web_994 leaves the room
[15:31:20] Zhe Lou_web_491 leaves the room
[15:31:22] Mihail Zverev_web_143 leaves the room
[15:31:23] <Shivan Sahib_web_355> Thanks to all our presenters!
[15:31:24] Joerg Ott_web_443 leaves the room
[15:31:24] Jonathan Lennox_web_672 leaves the room
[15:31:26] tim costello_web_437 leaves the room
[15:31:29] Eric Rosenberg_web_146 leaves the room
[15:31:38] Meetecho leaves the room
[15:31:38] Stephen Farrell_web_610 leaves the room
[15:31:40] James Galvin_web_834 leaves the room
[15:31:40] Philip Eardley_web_275 leaves the room
[15:31:41] <npd> I have many questions, and will send at least some to the list
[15:31:41] Renan Krishna_web_676 leaves the room
[15:31:42] Tommy Jensen_web_440 leaves the room
[15:31:42] Eric Orth_web_412 leaves the room
[15:31:43] Craig Pearce_web_708 leaves the room
[15:31:44] Samuel Weiler_web_990 leaves the room
[15:31:48] Bhavit Shah_web_655 leaves the room
[15:31:48] Peter Koch_web_134 leaves the room
[15:31:50] Alissa Cooper_web_705 leaves the room
[15:31:52] <Shivan Sahib_web_355> thanks npd
[15:31:54] Luigi Iannone_web_109 leaves the room
[15:31:55] Watson Ladd_web_828 leaves the room
[15:31:56] Vittorio Bertola_web_698 leaves the room
[15:31:56] Antoine Fressancourt_web_126 leaves the room
[15:31:56] Hannes Tschofenig_web_978 leaves the room
[15:31:58] Matthias Marx_web_452 leaves the room
[15:31:58] Bernie Hoeneisen_web_781 leaves the room
[15:31:59] Robert Story_web_238 leaves the room
[15:32:01] Nick Banks_web_691 leaves the room
[15:32:02] Christopher Patton_web_532 leaves the room
[15:32:02] <npd> for example, does IP geolocation functionality need to be eternally retained?
[15:32:04] Alex Chernyakhovsky_web_370 leaves the room
[15:32:05] Nick Doty_web_893 leaves the room
[15:32:06] Jean-Michel Combes_web_445 leaves the room
[15:32:07] Bradford Lassey_web_671 leaves the room
[15:32:10] Brad Chen_web_712 leaves the room
[15:32:11] Dirk Kutscher_web_402 leaves the room
[15:32:11] <Jari Arkko_web_111> @Richard. Yes but of course the alternative is to blindly trust the guys who provide the actual service.
[15:32:16] Benjamin Schwartz_web_596 leaves the room
[15:32:21] <Jari Arkko_web_111> I realize many people prefer that. I don't.
[15:32:27] Eric Rescorla_web_964 leaves the room
[15:32:35] Jari Arkko_web_111 leaves the room
[15:32:37] Juliana Guerra_web_686 leaves the room
[15:32:37] <ekr@jabber.org> But the point is that your design is actually rhe same as blindly trusting
[15:32:41] Michael Bilca_web_372 leaves the room
[15:32:51] <ekr@jabber.org> Because any such sophisticaed attacker can just break the TEE
[15:32:58] Allison Mankin_web_362 leaves the room
[15:33:02] Paolo Saviano_web_529 leaves the room
[15:33:02] Kazuaki Ueda_web_520 leaves the room
[15:33:02] Thom Wiggers_web_578 leaves the room
[15:33:02] Sofia Celi_web_424 leaves the room
[15:33:02] Shivan Sahib_web_355 leaves the room
[15:33:02] Michael B_web_396 leaves the room
[15:33:02] Julien Maisonneuve_web_497 leaves the room
[15:33:02] Jiri Novotny_web_365 leaves the room
[15:33:02] Patrick Tarpey_web_608 leaves the room
[15:33:02] David Schinazi_web_677 leaves the room
[15:33:02] Ching-Heng Ku_web_189 leaves the room
[15:33:02] Daniel Gillmor_web_440 leaves the room
[15:33:02] Wendy Seltzer_web_705 leaves the room
[15:33:02] Satoru Kanno_web_917 leaves the room
[15:33:02] Ian Swett_web_108 leaves the room
[15:33:02] Michael Hollyman_web_262 leaves the room
[15:33:02] Joey Salazar_web_878 leaves the room
[15:33:02] Matthew Finkel_web_426 leaves the room
[15:33:02] Juan-Carlos Zúñiga_web_952 leaves the room
[15:33:02] Sara Dickinson_web_224 leaves the room
[15:33:02] Chen Li_web_173 leaves the room
[15:38:18] alexamirante leaves the room
[15:52:16] kaduk@jabber.org/barnowl leaves the room
[15:59:55] whalen@jabber.org leaves the room
[16:03:06] whalen@jabber.org joins the room
[16:56:02] ekr@jabber.org leaves the room
[17:59:01] whalen@jabber.org leaves the room
[18:28:34] whalen@jabber.org joins the room
[18:29:02] whalen@jabber.org leaves the room
[18:34:26] whalen@jabber.org joins the room
[19:28:33] whalen@jabber.org leaves the room
[19:29:46] whalen@jabber.org joins the room
[19:31:03] whalen@jabber.org leaves the room
[19:34:18] whalen@jabber.org joins the room
[19:45:06] whalen@jabber.org leaves the room
[19:45:16] whalen@jabber.org joins the room
[19:47:06] whalen@jabber.org leaves the room
[20:03:17] whalen@jabber.org joins the room
[20:16:09] whalen@jabber.org leaves the room
[20:18:25] whalen@jabber.org joins the room
[21:52:08] whalen@jabber.org leaves the room
[21:56:56] whalen@jabber.org joins the room
[22:49:11] whalen@jabber.org joins the room
[22:49:11] cjsu leaves the room
[22:49:11] Matthew leaves the room
[22:49:11] npd leaves the room
[22:49:11] sftcd leaves the room
[22:49:13] whalen@jabber.org leaves the room
[22:49:15] cjsu joins the room
[22:49:15] Matthew joins the room
[22:49:15] npd joins the room
[22:49:15] sftcd joins the room
[23:05:57] whalen@jabber.org joins the room
[23:06:13] whalen@jabber.org leaves the room
[23:20:13] whalen@jabber.org joins the room
[23:20:14] whalen@jabber.org leaves the room
[23:48:45] dkg leaves the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!