16:00:09 #startmeeting tor anti-censorship meeting 16:00:09 Meeting started Thu Jun 2 16:00:09 2022 UTC. The chair is meskio. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:09 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:00:12 hello everybody! 16:00:22 here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 16:00:23 hi~ 16:00:33 feel free to add what you've been working on and put items on the agenda 16:02:04 I see for now we only have one point in the agenda: Endless loop on the latest snowflake 16:02:48 is this from our random cypherpunk? 16:03:39 I think people should open issues with this kind of problems instead of dumping them into our pad 16:03:53 if the author is not around I think we can skip it 16:04:07 or does anybody want to talk about it? 16:04:45 ok, lets go to the next point in the agenda: Implement metrics to measure snowflake churn 16:05:06 yes 16:05:27 this the one that try to count distinct proxy ip 16:05:41 and allow set operation on these proxy ip 16:05:58 so that we can know how fast does these proxy ip change 16:06:16 nice!!! 16:06:21 to see how resilient our network is 16:06:42 it used hyperloglog++ structure 16:06:49 to do the count distinct 16:07:12 instead of remembering individual IP 16:07:31 so user's ip info is not extractable from our data 16:07:38 making it possible to publish this data 16:08:26 with all probabilistic data structure, it is not fully accurate 16:08:57 which is a free bonus in our use case 16:09:04 +1 16:09:22 because we would record user info 16:09:30 and may even publish this info 16:09:51 so comments are welcomed 16:09:55 sounds pretty good 16:09:59 thank you 16:10:03 no problem 16:10:51 thanks shelikhoo for working on that 16:11:05 i'm interested to see the results 16:11:16 (additionally, user ip is keyed-hashed by a secret key first, so attacker can not either proof a ip is in poor or not without that secret key) 16:11:35 (additionally, user ip is keyed-hashed by a secret key first, so attacker can not either proof a ip is in pool or not without that secret key) 16:12:11 (additionally, user ip is keyed-hashed by a secret key first, so attacker can not neither proof a ip is in pool nor proof it is not in the pool without that secret key) 16:12:49 no problem~ I am interested to see the result as well 16:13:13 yeah, let's see what it shows 16:13:13 that's all. an invitation for comment 16:13:34 cool, I guess we can move to the next topic 16:13:50 last week we were talking about enforcing having 2FA in gitlab 16:14:21 I have contacted everybody that had commit access to gitlab's anti-censorship group without 2FA and ask them to set it up 16:14:46 there are few accounts with non-commit permitions in the group that doesn't have 2FA, but I don't consider that a problem 16:15:19 I left the point just to inform that is done 16:15:54 anything else for today? 16:16:29 should we pick a paper to discuss? 16:17:21 maybe "Even Censors Have a Backup: Examining China's Double HTTPS Censorship Middleboxes": https://dl.acm.org/doi/10.1145/3473604.3474559 ? 16:17:57 any other ideas? 16:18:32 nothing from me 16:19:43 I would propose to do it in 3 weeks (June 23), as I will be AFK the next 2 thursdays 16:20:40 sounds good to me.... 16:20:41 ok, so if no one has any better proposal let's do that one 16:20:48 anything else for today? 16:21:04 (nice to have sort meetings once in a while :) 16:22:05 EOF 16:22:11 #endmeeting