15:58:23 <shelikhoo> #startmeeting tor anti-censorship meeting
15:58:23 <shelikhoo> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
15:58:23 <shelikhoo> feel free to add what you've been working on and put items on the agenda
15:58:23 <MeetBot> Meeting started Thu Dec  8 15:58:23 2022 UTC.  The chair is shelikhoo. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:58:23 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:58:26 <shelikhoo> Hi~
15:58:27 <shelikhoo> Hi~
15:58:48 <shelikhoo> Oh this time I started the meeting at the exact second(seems to me)
15:59:13 <meskio> XD
15:59:19 <meskio> hello everybody
16:01:24 <shelikhoo> I won't be at next Tuesday's team sync meeting, but I don't have a lot of urgent things to discuss... AFK reachable over signal until next Wednesday for a personal vacation...
16:01:59 <meskio> nice, vacations :)
16:02:10 <meskio> I have few announcements
16:02:17 <shelikhoo> yes!
16:02:55 <meskio> we have an outreachy intern, working on extending gettor to more IM/social media platforms, you'll see cece around in our communications channels
16:04:20 <meskio> another announcement I have is that as usually we'll be AFK for new year break, there will not be meetings neither Dec 29 or Jan 5, we'll resume the meetings January 12
16:05:41 <meskio> ohh, I see in the announcement's list that snowflake-02 is life with the new TB version, amazing
16:05:57 <dcf1> yes
16:05:58 <shelikhoo> great! it is finally here!
16:06:02 <meskio> let's see how the load of the broker goes with the doubling of connections
16:06:17 <shelikhoo> ^~^
16:06:26 <dcf1> we expect snowflake-02 to get about 50% of the Tor Browser traffic, which is maybe less than half of all snowflake traffic.
16:06:43 <dcf1> I think there are actually more snowflake users on Orbot than on Tor Browser.
16:06:59 <meskio> ohh
16:07:12 <meskio> should we talk with orbot people to inclue snoflake-02?
16:07:23 <meskio> or let's wait a bit to see how it goes with TB 12?
16:07:35 <dcf1> yes we should, no rush though I think
16:07:46 <shelikhoo> yes. we could start chatting with them
16:08:10 <shelikhoo> but no need to push that on priority todo list
16:08:23 <meskio> we have regular meetings with them because of sponsor 96, we can mention it in the next one (in January)
16:08:51 <dcf1> ok
16:09:14 <meskio> I'll add it to the agenda of that meeting so I don't forget
16:10:53 <shelikhoo> anything more on this topic?
16:11:05 <meskio> not from me
16:11:07 <shelikhoo> we can move on to the next topic: make obfs4 distinguishability reports public?
16:11:39 <dcf1> right, we postponed the original date of November 15 to give time for Tor Browser releases and bridge operators to upgrade
16:12:37 <dcf1> is it ok to make those issues public, or are we still waiting on anything?
16:12:42 <shelikhoo> did we run the scan again to determine as of now how many of them are upgraded?
16:13:13 <meskio> I was waiting to make sure at least 50% are upgraded, so we have some certainty that most users get at least one bridge upgraded
16:13:20 <dcf1> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/obfs4/-/issues/40008#note_2857416
16:13:43 <meskio> last week we were not too far from it
16:14:20 <meskio> I was thinking on sending a second round of emails to bridge operators asking to upgrade (to the ones that hasn't upgraded)
16:14:44 <meskio> the last time the delivery to gmail addresses failed, I hope this is going to be fixed very soon
16:14:50 <dcf1> ohh
16:14:55 <meskio> but maybe I'm blocking it without need
16:15:12 <dcf1> I think it doesn't matter much one way or another, just don't want it to sit forever.
16:15:20 <meskio> delivery fail, as gmail detects it as spam, our sysadmins are working hard to fix it (see tor-project emails about it)
16:16:12 <meskio> dcf1: I agree, let's not sit on it for ever, let me do a final push for bridges to upgrade and let's make it public
16:16:28 <meskio> how do you feel about doing it as soon as we come back from the new year's break? January 7?
16:16:33 <dcf1> ok
16:16:37 <shelikhoo> +1
16:16:38 <meskio> or I'm ok being convinced to do it now
16:16:46 <meskio> I just prefer not to do it just before going AFK
16:16:59 <shelikhoo> let's do it after we return to work next year
16:17:24 <meskio> sounds good, I'll change the deadline of the ticket
16:17:41 <meskio> and sorry for pushing it back for so long
16:17:51 <dcf1> no apology necessary
16:17:59 <meskio> :)
16:17:59 <shelikhoo> it is no one's fault
16:18:14 <shelikhoo> okay, anything more on this topic?
16:18:37 <meskio> I said january 7, but that is a saturday, will do monday 9 :)
16:18:41 <meskio> nothing else from me
16:19:00 <shelikhoo> let's move to     does ajax.aspnetcdn.com still work in turkmenistan??
16:19:19 <shelikhoo> we don't yet have access to turkmenistan's network environment
16:19:21 <meskio> I added that, because AFAIK we use that for snowflake in TM, isn't it?
16:19:30 <meskio> I was checking that
16:19:49 <meskio> mmm, no cdn.sstatic.net, maybe I'm wrong
16:20:10 <dcf1> dig @95.85.120.6 ajax.aspnetcdn.com
16:20:14 <dcf1> dig @95.85.120.6 cdn.sstatic.net
16:20:21 <dcf1> neither of these gets DNS injection for me just now
16:20:27 <meskio> so my question is because in our 'interesting links' section there is a mention about ajax.aspnetcdn.com being blocked in russia
16:20:32 <meskio> we use that one for meek
16:20:42 <meskio> but I see is not used for anything else
16:21:07 <meskio> dcf1: nice, I guess we don't need to do anything there
16:21:38 <meskio> meek is not working in russia, but there are other options and we've being planning to retire meek, hopefully we don't need to do anything with this
16:21:43 <dcf1> curl --connect-to ::telecom.tm: http://ajax.aspnetcdn.com/
16:21:47 <dcf1> curl --connect-to ::telecom.tm: https://ajax.aspnetcdn.com/
16:22:04 <dcf1> these also are not getting injection
16:22:13 <dcf1> https://github.com/net4people/bbs/issues/80#issuecomment-906533865
16:22:46 <dcf1> curl --connect-to ::telecom.tm: http://cdn.sstatic.net/
16:22:49 <dcf1> curl --connect-to ::telecom.tm: https://cdn.sstatic.net/
16:22:51 <dcf1> also seem ok
16:23:01 <meskio> :)
16:23:40 <meskio> I recall we did change the snowflake configuration in TM at some point and I thought we were using azure, but it looks like we dont, good
16:24:43 <meskio> I don't have anything else on this topic
16:25:04 <shelikhoo> okay anything more we wants to discuss in this meeting?
16:25:18 <rwails> I have something brief :-)
16:25:28 <shelikhoo> yes! please!
16:26:17 <rwails> I'm working with nrl and with you on sponsor 28 work -- we are working on PT that hopefully has fewer distinguishability issues than obfs4
16:26:46 <rwails> I'm hoping to attend these meetings more frequently to keep y'all updated about what we're up to
16:27:25 <meskio> pretty cool, can we already see something on this PT? is it an evolution of obfs4 or something totally new?
16:28:05 <rwails> but I just had one quick question for now: we were hoping to code the PT to be comptabile with both the current C tor client and with a future arti client... if we use the current PT spec, do you think we will be forward compatibile with the arti client? or are there planned changes to the api?
16:28:43 <dcf1> My guess is whatever is in arti 1.1.0 (the version with client PT support) is pretty close to final
16:28:58 <rwails> meskio: we're working on a paper currently, so the design is somewhat still changing, but the idea is to have protocol flows look encrypted, but with more protocol strucuture than obfs4 currently has (ie not uniformly random in every packet)
16:28:59 <meskio> the current pt spec: https://gitweb.torproject.org/torspec.git/tree/pt-spec.txt is already implemented in arti
16:29:04 <dcf1> I haven't tried it myself but they say they have tested with with existing PTs not specifically coded for arti
16:29:14 <meskio> and the plan is to keep compatibility with it
16:29:18 <rwails> oh, ok, awesome :-)
16:29:35 <meskio> there are some details on how to run a PT in arti here: https://gitlab.torproject.org/tpo/core/arti/-/issues/333
16:29:41 <meskio> (is in my queue of things to try :)
16:30:03 <rwails> thanks, that's very helpful!
16:30:12 <meskio> rwails: thanks for working on this, is going to be very useful :)
16:30:47 <rwails> \o/
16:30:52 <meskio> 'not uniformly random in every packet' sounds useful seeing that some censors are starting to block fully random traffic
16:31:06 <rwails> yes, that's a large part of the motivation
16:31:11 <meskio> :)
16:31:58 <meskio> I'll love to see the paper when is public, we should add it to our reading group
16:32:16 <rwails> I think that's all on that though, thanks again. working on it over the holiday break, so maybe I'll have something nice to say next meeting
16:32:30 <rwails> sure! we can probably send some things in advance of publication, too
16:32:40 <shelikhoo> yes! I will be happy to try this tool once it is available..,
16:32:40 <meskio> :)
16:32:50 <shelikhoo> thanks for working on this!
16:33:56 <shelikhoo> okay, anything more on this topic?
16:34:11 <meskio> not from me
16:34:13 <shelikhoo> or anything more we wants to discuss in this meeting?
16:34:52 <shelikhoo> #endmeeting