15:58:31 #startmeeting tor anti-censorship meeting 15:58:31 Meeting started Thu Dec 1 15:58:31 2022 UTC. The chair is meskio. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:58:31 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:58:36 hello everybody!!! 15:58:39 here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 15:58:57 add whatever you've been working on and please put items to the agenda 15:59:44 hi~ 16:00:37 while others come up with more things to discuss I can start with the point I just added 16:00:44 Tor Browser multi-locale 16:00:58 next week (hopefully monday) there will be the release of TB 12.0 16:01:28 one of the main changes is that instead of providing one TB installer per locale there will be one single installer per platform with all locales included 16:01:50 this requires changes in gettor, but we are ready for it and will de ploy the changes when the release is done 16:01:57 hopefully nothing will break :) 16:03:18 I guess we can move the next topic: "Reported as offline in metrics" 16:03:21 is it you ggus ? 16:03:26 it's me 16:03:58 since last week i'm receiving messages from bridge operators reporting that their bridges are offline in metrics 16:04:22 but their bridges are running. they didn't make any change 16:04:28 s 16:04:50 isn't that happening since a while? I remember seeing it before 16:05:07 it was happening some months ago, and it was an issue with Serge 16:05:21 ahh, and now is a different issue 16:05:25 cool 16:05:29 or not cool 16:05:44 i mean, i don't know if it's the same issue 16:05:44 anyway, it looks like a bug on the bridge authority 16:06:22 we should poke gman and see if he knows anything, otherwise we might need to involve the network team to look into it 16:06:44 i poked him some days ago on #tor-project, and he didn't see anything different 16:07:30 mmm, then I think we need to ask the network team, I'm going to poke ahf in that ticket and see if he can help there 16:07:53 BTW, AFAIK if the running flag is not set for some bridges rdsys will not distribute them 16:08:24 but I remember making rdsys detect if the running flag was missing for most of the bridges and ignore it if that is the case 16:08:46 maybe we are hitting that sittuation, I'll investigate, I believe this is reported in prometheus somehow 16:10:32 meskio: i restarted my bridges' tor daemon the other day, and now my bridge is "online" again. https://metrics.torproject.org/rs.html#details/25A5B3BB5449EC5A0D4AE4DB657899C02C186EBE 16:10:58 mmm, weird, how bridge authority works is a bit a black box for me 16:11:36 last time one of the issues with Serge was ipv6 connectivity or something like this. 16:14:37 I just checked, rdsys ignores bridge updates if the number of running bridges is < 50% 16:14:44 and we signal it in prometheus 16:14:57 last time this happend was a week ago 16:15:08 it does happen sometimes when the bridge authority gets restarted 16:15:19 so, most bridges have the running flag 16:15:27 but it looks like some don't 16:15:40 I'll investigate more 16:15:47 anything else on this topic? 16:16:15 all good, thanks! 16:16:26 thanks for bringing it up 16:16:36 next topic: license of webtunnel 16:16:38 shelikhoo? 16:16:40 yes 16:16:41 (Re)license webtunnel as MIT license: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel 16:17:09 I recently discovered that webtunnel project don't have a license yet 16:17:24 and I think it is a good time to give it one 16:17:54 +1 16:17:58 we might wants to consider MIT license first 16:18:12 unless there is more suitable one 16:18:26 AFAIK this licenses is what we do by default in other projects, I don't see anything against it 16:20:16 thanks for bringing it up, I have in my queue to review that we have licenses in all projects: https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/110 16:20:27 anything against licensing it as MIT? 16:21:52 cool, I guess this is an agreement 16:22:02 anything else to talk about? 16:22:04 something related to webtunnel. do we have an eta for the tor browser? 16:23:03 gaba: https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_requests/595#note_2858936 16:23:14 \o/ 16:23:50 I have get it to build together with tor browser, and it is waiting for review from application team 16:24:10 beautiful 16:24:13 right now, one can connect to a webtunnel bridge with a custom bridge line 16:24:14 thanks 16:24:24 but, there is no UI for this yet 16:24:38 do we need work from UX team for that? 16:24:44 do you have a ticket for the UI part? 16:25:04 I guess we don't need any UI for now, if we provide the right bridgeline it will work, isn't it? 16:26:06 we don't need it right now, but... 16:26:42 in the future, it would need a small UI change to allow user select webtunnel default bridge or receive it via rdsys 16:27:06 ok 16:27:08 but I think it can reuse the ui design we have for obfs4 16:27:27 ok. it would be good to have a ticket explaining it so we can add it to the work from the ux team for next quarter 16:27:45 the 'request a bridge' button will need a selector of the type of bridge, and some thinking on how to do it not-confusing 16:27:58 but we don't have rdsys/moat support for it yet 16:28:21 yes, let's have a ticket and have a discussion there 16:28:47 that reminds me I should open an issue to do the rdsys part, but I hope that will be mostly configuration on the server side 16:30:12 gaba: can shelikhoo open that issue in the UX side? where is the right place for it? 16:31:26 the right place to do it is the webtunnel repo and mark it with the ux label 16:31:33 ux has tickets all over the place depending on the tool 16:31:54 yes... I will write a ticket for that 16:31:58 thanks! 16:32:04 nice 16:32:20 anything else before we move to the reading group? 16:32:59 great, we have for this week: Measuring DoT/DoH Blocking Using OONI Probe: a Preliminary Study 16:33:08 https://www.ndss-symposium.org/ndss-paper/auto-draft-123/ 16:33:57 using OONI they measure if DoT and/or DoH services are blocked in kazakhstan, Iran and china 16:34:30 checking first if the resolver domain name does resolve correctly using the normal ISP domain server, and then if a connection works to the resolver 16:35:01 I'm surprised to see that 80% of the resolvers were uncensored 16:35:50 not sure if the usage is just low enough they don't care, or the censors don't relay so much on DNS to censor contet and they don't care if it works 16:35:54 (I guess the second) 16:36:47 The DoH/DoT situation has changed recently in Iran (much more blocked now). https://ooni.org/post/2022-iran-technical-multistakeholder-report/#increased-blocking-of-encrypted-dns 16:37:03 mmm, true, the paper is from 2 years ago... 16:37:04 yeah, since IP, SNI basically allow censor to block a lot of things already 16:37:38 and they could, as described by dcf, to block them only when necessary 16:39:10 yes :( 16:39:15 I was helping someone debug encrypted DNS accessibility in Iran in October, most of the prominent ones were blocked, but there were some obscure ones that still worked. 16:39:57 is curious, from the link you shared dcf1 that they don't just block port 853, only certain remotes (50% of tested DoT resovlers) 16:40:12 E.g. ipv4-zepto-mci-1.edge.nextdns.io 16:42:24 yes, I guess they block anything they notice being used 16:44:41 anything else on this paper? 16:45:55 great, I guess we can end this meeting here 16:45:55 EOF 16:46:01 #endmeeting