15:59:28 <meskio> #startmeeting tor anti-censorship meeting
15:59:28 <MeetBot> Meeting started Thu Feb 24 15:59:28 2022 UTC.  The chair is meskio. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:59:28 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:59:32 <meskio> hello!!!
15:59:38 <shelikhoo> Hi~
15:59:41 <meskio> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
15:59:55 <meskio> please add what you've been working on and put items on the agenda
16:01:11 <meskio> we have a pretty empty agenda
16:01:25 <meskio> I added a point about obfs4 issues, but I'm not sure we have much to update there
16:02:07 <meskio> https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40804
16:02:26 <meskio> yawning knows about the issue, but is not clear is interested on fixing it
16:02:46 <meskio> he asks people to update the server side so the problem goes away
16:02:56 <dcf1> We've not heard back from Aaron Johnson yet, whom arma contacted after last week's meeting
16:04:03 <meskio> obfs4proxy package is in its way to debian testing, I guess as soon as it hits testing we should ask acute to upload it to backports so we get more servers to fix the problem on their side
16:04:13 <meskio> but still will be nice to have a fix for the problem
16:04:38 <shelikhoo> Did we test if upgrade will solve this issue?
16:04:49 <dcf1> Yes, an upgraded server solves it.
16:05:49 <shelikhoo> Yes.... So we can either find a way to get most of server update their obfs4 version, or try to find a client side fix.
16:06:16 <meskio> I expect it will take many months to get a decent number of bridges to update the version
16:06:42 <dcf1> How about starting with the Tor Browser default bridges?
16:06:50 <meskio> +1
16:07:53 <shelikhoo> Yes, and if this kind of urgent update happen too frequently, we might wants to invest in a way to deploy new change more quickly
16:08:22 <shelikhoo> Yes, and if this kind of urgent update happen too frequently, we might wants to invest in a creating way to deploy new change more quickly
16:09:05 <meskio> I can build a docker image with the new version, maybe people automatically update their dockers
16:09:46 <shelikhoo> Yes, we might also wants to update our deployment guide to point to containerised deployment
16:10:29 <shelikhoo> instead of rely on Debian package
16:10:34 <meskio> I'm assuming we are moving forward here and don't consider going back to the previous version an option...
16:10:39 <dcf1> There is a ticket for having PT bridges report their versions, which would help with tracking the progress of upgrades: https://gitlab.torproject.org/tpo/core/tor/-/issues/11101#note_2770219
16:12:56 <shelikhoo> Do we need to amend PT spec to do this in a well defined way?
16:13:22 <ggus> Having that implemented would be helpful ^^^
16:13:58 <dcf1> shelikhoo: not necessarily, there is a STATUS message that could have a defined format for reporting the version
16:14:19 <meskio> is the version already being reported by snowflake and obfs4?
16:14:33 <dcf1> no
16:14:52 <ggus> meskio: do you have an estimate time when the new obfs4 package will be released on Debian?
16:15:08 <dcf1> there's no protocol defined for doing it. STATUS is a free-form message without defined sematics for specific messages, some defined semantics is what is needed.
16:15:28 <meskio> ggus: is already in unstable, so it should be <10 days
16:15:54 <meskio> that is the time to get it into testing, once is in testing you can upload it to backports, but I've never done that, I think this is pretty fast
16:16:44 <meskio> maybe we should create a task on our side to start reporting the version of snowflake, as a first step for it
16:16:49 <meskio> task == issue
16:17:09 <meskio> once we are reporting the version we can check back with the network team to do their part
16:17:48 <shelikhoo> Yes. I think we might wants to ask network team about their preferred way of receiving version information
16:17:52 <dcf1> Past notes on version reporting using STATUS: https://lists.torproject.org/pipermail/tor-project/2021-October/003194.html
16:20:12 <dcf1> http://meetbot.debian.net/tor-meeting/2021/tor-meeting.2021-09-30-16.00.log.html#l-10
16:20:26 <dcf1> I'll add those links to #11101
16:21:10 <meskio> shelikhoo: sounds good, I can start the conversation with the network team in #11101 and see what will be the preferred format
16:21:23 <shelikhoo> Yes.....
16:22:34 <meskio> ggus: do you want to contact the default bridges about the obfs4 upgrade? or should I do it? (I guess I can find their contact somewhere in the wiki)
16:23:05 <shelikhoo> I hope we don't get PT spec spammed with 10 different ways to report version...
16:23:30 <meskio> I hope not
16:24:02 <ggus> meskio: I can do that. Tell me when
16:24:43 <meskio> I guess we can already ask them what they need to update, and if the package in debian backports is a block for them
16:25:31 <ggus> Ok! Let’s open a ticket to track this
16:26:15 <meskio> thanks for taking care of it, I'm happy to be in cc if you want
16:26:52 <meskio> anything more about this topic?
16:26:55 <ggus> Ack! Thank you!
16:27:32 <meskio> uTLS in Snowflake Client Broker Communication
16:27:48 <shelikhoo> Yes
16:28:09 <shelikhoo> We received reply from Rod Hynes
16:28:29 <shelikhoo> The TLDR is that uTLS is working for now
16:29:07 <shelikhoo> And there are other optional improvement we can use to improve it
16:30:27 <shelikhoo> Since it is a client side feature, we should be able to ship change to get it back to working status quickly
16:31:18 <shelikhoo> "Since it is a client side feature, we should be able to ship change to get it back to working status quickly" is from me
16:32:08 <meskio> are you proposing that we enable uTLS by default in snowflake?
16:33:32 <shelikhoo> The thing I wish to propose is that we first ship a version with uTLS, and allow user to try it first
16:33:59 <shelikhoo> with the intention to make it default if no issue were discovered
16:34:16 <shelikhoo> or when a censorship can be evaded by it
16:34:23 <meskio> sounds good
16:34:45 <meskio> in that case I think we should pick a default fingerprint, so it can be enabled without having to understand what a fingerprint is
16:35:02 <meskio> (that might require changes in the proposed params)
16:35:13 <shelikhoo> remember we have a censorship map in the pipeline
16:35:55 <shelikhoo> so it should allow us to ship targeted change as soon as user have done testing of utls
16:35:56 <meskio> I see where you are going, but then we should be able to enable uTLS from the SOCKS connection
16:36:07 <meskio> the same way we pass the obfs4 params
16:36:29 <dcf1> that's how it works in meek-client and obfs4proxy, utls=xxx in the SOCKS params
16:36:39 <meskio> nice
16:37:02 <dcf1> https://gitweb.torproject.org/pluggable-transports/meek.git/tree/doc/meek-client.1.txt?h=v0.37.0#n46
16:37:12 <shelikhoo> Yes, I will amend the merge request to make it happen
16:37:20 <meskio> I guess is something you put in the bridge line, isn't it?
16:37:35 <dcf1> correct, the SOCKS params are in the bridge line
16:39:01 <meskio> I will coordinate with TB people, because we don't have anything yet in the circumvention settings for that, but I think should be possible to add
16:39:17 <dcf1> In goptlib, the args end up in the Args field of each SocksRequest https://pkg.go.dev/git.torproject.org/pluggable-transports/goptlib.git#SocksRequest
16:40:03 <dcf1> meskio: that's why there used to be a separate meek-google, meek-amazon, etc. Those were settings that could have been controlled via SOCKS params, but there was not interface for choosing SOCKS params independently of a bridge line.
16:41:17 <shelikhoo> Yes, and it is much easier to change the bridge line in Tor browser, than to change PT plugin settings
16:41:17 <meskio> I see, should not be a problem for the circumvention settings, as there is already a way to provide the bridge line, but I'm not sure if we were doing it for snowflake
16:42:45 <meskio> good, we have a path forward for this
16:42:54 <shelikhoo> The intention we I am not yet considering enable it for everyone by default is because of the imperfection of uTLS
16:43:12 <shelikhoo> we don't wants to break someone's setup unnecessarily
16:43:39 <shelikhoo> but this is not an issue if the non-utls is already censored
16:44:34 <meskio> +1
16:44:59 <shelikhoo> anyway, the first step will be amend merge request to receive utls setting from bridge line
16:46:32 <meskio> good, anything else on this topic? any other topic to discuss?
16:47:23 <shelikhoo> EOF
16:47:31 <meskio> I have an anouncement: I'm planning to deploy rdsys+bridgedb in production next monday
16:47:45 <meskio> so many bridges will change distribution mechanisms
16:47:57 <meskio> but hopefully this is the only change visible
16:48:09 <meskio> I'll send emails to tor-project and tor-relays
16:49:11 <meskio> do we want to pick the next paper for our reading group? or want to wait for cecylia? (she will be around next week)
16:50:05 <shelikhoo> I am fine either way
16:50:22 * meskio looks into https://censorbib.nymity.ch/ for interesting papers
16:52:02 <meskio> the titles that sound interesting to me are: How Great is the Great Firewall? Measuring China's DNS Censorship
16:52:04 <meskio> Throttling Twitter: an emerging censorship technique in Russia
16:52:22 <meskio> Web censorship measurements of HTTP/3 over QUIC
16:53:46 <meskio> any preferences?
16:55:07 <shelikhoo> Throttling Twitter: an emerging censorship technique in Russia? we have got 5-10kb/s download speed on some of s96 bridges
16:55:43 <shelikhoo> changing to bbr made most of them finish bootstrap, but some of them still have poor download speed
16:56:08 <shelikhoo> maybe we can have some inspiration from paper?
16:56:08 <meskio> good, let's do that one, two weeks, 10 March?
16:56:16 <meskio> that is a good reason
16:56:40 <meskio> ok, I think we are done with the meeting
16:56:54 <meskio> I'll wait a minute to close it just in case someone has something else to say
16:58:04 <meskio> #endmeeting