15:58:42 <itchyonion> #startmeeting tor anti-censorship meeting
15:58:42 <MeetBot> Meeting started Thu Jun  1 15:58:42 2023 UTC.  The chair is itchyonion. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:58:42 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:58:50 <itchyonion> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
15:58:50 <itchyonion> feel free to add what you've been working on and put items on the agenda
15:58:55 <itchyonion> hello
15:59:13 <meskio> hello
15:59:40 <shelikhoo> hi~
16:00:59 <itchyonion> The first topic:  Report of TLS-in-DTLS detection and throttling in China that affects Snowflake
16:01:22 <itchyonion> I believe we talked about this last week, but looks like there are some new updates
16:01:38 <dcf1> this is realted to last week's discussion, but this is new
16:02:16 <dcf1> someone reported that their own WebRTC proxy (not snowflake) was being throttled based on traffic analysis features that they investigated
16:02:46 <dcf1> one of which was the size of the first client->server send or a pattern that looks like TLS inside the DTLS connection
16:03:20 <dcf1> they say it affects snowflake too. the throttling is done by packet drops, the reporter reported packet loss rates of around 50%
16:03:33 <cohosh> woah
16:03:54 <dcf1> I made a quick patch to change the traffic signature of the first client send, and the reporter said that it resolved the throttling in snowflake for them
16:04:47 <dcf1> It is just one report, but it may be a or the primary cause of the high packet loss shelikhoo has measured in China before https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40251#note_2887929
16:04:58 <shelikhoo> Sorry I didn't see your reply on the snowflake speed earlier, I think it should be possible for me to run the test with that patch
16:05:18 <dcf1> So the proposal is to try the quick patch from a vantage in China, and if it helps, then perhaps deploy some simple initial padding strategies, at least for the short term
16:05:31 <shelikhoo> and compare the result with the previous tests
16:06:10 <dcf1> The packet encapsulation protocol does have support for traffic shaping, we just have not tried using it before now
16:06:25 <dcf1> thanks shelikhoo, that will be great
16:06:30 <meskio> wow
16:06:34 <cohosh> i didn't think we'd have to start doing traffic shaping so soon
16:06:53 <dcf1> This weekend is the June 4th anniversary, there is often increased censorship in China around this time. Though it could be unrelated.
16:06:57 <cohosh> well i guess i don't know what "soon" means here heh
16:07:22 <dcf1> This is still pretty preliminary imo, but the reporter on BBS seems to know what they are talking about.
16:07:51 <shelikhoo> Yeah, I will try to run this experiment as soon as possible
16:08:17 <shelikhoo> china some time have event exclusive censorship and will soon goes away
16:08:17 <meskio> if that traffic shaping does solve the chinese problem, do we still want the changes shelikhoo is being working on to deal with unreliable connections?
16:08:44 <shelikhoo> meskio: let's discuss this after we got the test result on the patch
16:08:51 <dcf1> We can later discuss better ways to implement the padding strategy. I just kind of hacked it in, but a better way will be to introduce a new Conn type that implements a given padding strategy (which could be simple, and perhaps only affect the first 10 KB or so of a connection)
16:09:06 <shelikhoo> it is too early to discuss that now
16:09:18 <meskio> ack
16:09:22 <dcf1> meskio: yes, definitely the switch to unreliable data channels is desirable independent of this throttling observation
16:09:32 <meskio> +1
16:10:00 <dcf1> China performance was the initial cause that made shelikhoo look into it closely, but it's just a good idea anyway
16:10:36 <shelikhoo> yes, but it could have impact on priority, but anyway it is too early to tell.
16:10:50 <shelikhoo> let's discuss this after we got the result about the patch
16:10:52 <dcf1> I agree, let's proceed with some tests first
16:10:55 <shelikhoo> thanks dcf1!
16:11:04 <meskio> cool
16:12:33 <itchyonion> Anything more on this topic?
16:12:45 <shelikhoo> EOF from me
16:12:50 <dcf1> that's all
16:12:54 <itchyonion> Moving on to the next one.  Research about designing an armored bridge line sharing URL format (new update)
16:12:58 <shelikhoo> yes!
16:13:18 <shelikhoo> I have run a few experiments about the armored bridge line sharing urll
16:14:19 <shelikhoo> the TLDR is that I think "7bit,crc32,base64,prefix" is the best sequence of action to generate a url for non-qr usage
16:14:29 <shelikhoo> (if we don't add forward error correction)
16:15:02 <shelikhoo> 7bit remove the first bit in each char, take the advantage that bridgeline is limited to ASCII chars
16:15:13 <shelikhoo> and ascii only use 7 bits
16:15:29 <shelikhoo> crc32 add checksum
16:15:52 <shelikhoo> base64 encode the binary data into sting with 0.75 density
16:16:07 <shelikhoo> finally prefix is nice for os integration
16:16:18 <shelikhoo> allow us to be the default handler of these urls
16:16:24 <shelikhoo> you can try this on
16:16:24 <shelikhoo> https://32gky4batesvburcfrxvq4bbhy0fupjx.lambda-url.eu-west-1.on.aws/encode7.html
16:16:32 <meskio> prefix as in bridge:// or https://brdg.es/?
16:16:41 <shelikhoo> https://32gky4batesvburcfrxvq4bbhy0fupjx.lambda-url.eu-west-1.on.aws/decode7.html
16:17:26 <shelikhoo> It could be either of them, but the https one allow better os integration on mobile
16:17:35 <shelikhoo> as user can just click on it to import this url
16:17:49 <shelikhoo> and one of the app can be the default handler
16:18:16 <shelikhoo> bridge:// on the otherhand won't send dns request when there is no handler
16:18:32 <meskio> yes, nice, I was just checking that was that nor some kind of prefix in the string itself
16:18:48 <shelikhoo> yes, we have either or both of them...
16:19:23 <meskio> I think is good to have both, as in some cases we could use bridge:// without problems and be more secure of not leaking the domain...
16:19:30 <meskio> like for example in QRcodes
16:19:40 <shelikhoo> for QR code, having Base36 then uppercase increase the density to 0.8
16:19:52 <shelikhoo> but it would make things more complex
16:19:59 <shelikhoo> to parse
16:20:35 <meskio> I think is better to stick to a single encoding
16:20:42 <shelikhoo> I decide not to use base45 as original discussed as it have all kinds of symbols that don't work really well
16:20:50 <shelikhoo> for an url such as space
16:21:09 <shelikhoo> https://32gky4batesvburcfrxvq4bbhy0fupjx.lambda-url.eu-west-1.on.aws/encodeqr.html
16:21:14 <shelikhoo> and you can try it here
16:21:35 <shelikhoo> yes, 0.05 isn't that important, I think
16:21:59 <meskio> +1
16:22:05 <shelikhoo> https://github.com/xiaokangwang/armoredurl/tree/master/cli
16:22:17 <shelikhoo> the source code is here, sorry for poor code quality
16:22:32 <meskio> I think it makes sense what you found and is a good looking proposal
16:22:33 <shelikhoo> it is not meant for long term usage
16:23:11 <meskio> hehe, how many projects start like that and they are still around years after :P
16:23:51 <shelikhoo> yes, I think we can move forward with just 7bit, crc32, base64, prefix for both qr and text format
16:24:01 <meskio> +1
16:24:28 <meskio> what are the next steps? draft a rfc? ask for comments from other ineterested parties?
16:24:33 <shelikhoo> I will have a chat with ggus about forward error correction... but anyway, that is the thing we are most likely to use
16:24:53 <shelikhoo> I was advised to write a tor spec for this
16:25:06 <shelikhoo> so I will proceed with that
16:25:17 <shelikhoo> I think it is consider a spec, and is rfc like
16:25:34 <shelikhoo> and ask comments from other parties once it is ready
16:25:50 <shelikhoo> EOF
16:26:46 <itchyonion> Next topic:     Update on Analysis of speed deficiency of Snowflake in China, 2023 Q1 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40251#note_2883879
16:27:51 <meskio> I guess after the previous discussion this topic is posponed for now, isn't it?
16:28:02 <itchyonion> Related to the first topic. Anything new other than what we've already discussed?
16:28:59 <shelikhoo> no.. I think we already covered this
16:29:16 <shelikhoo> let's proceed with test and return to this later
16:29:37 <itchyonion> Sounds good. Moving on to interesting links:     Large oscillations in relay users in China the past 6 weeks:
16:29:37 <itchyonion> https://people.torproject.org/~dcf/metrics-country.html?start=2023-03-01&end=2023-05-31&country=cn
16:30:24 <dcf1> nothing really to say about it, just the graph looks really weird
16:31:13 <dcf1> in the "bridge users by transport", you can see some echoes of the relay oscillations, and that obfs4 and snowflake are negatively correlated
16:31:24 <shelikhoo> yes.. we don't have enough information about its cause for now....
16:31:49 <meskio> weird
16:32:43 <itchyonion> Looks like it begins after obfs4 usage was dropped down to almost 0 around April - May
16:33:42 <dcf1> which was https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40033#note_2896876 I believe
16:35:56 <shelikhoo> one possibility is that users use obfs4 when it is accessible
16:36:08 <shelikhoo> because snowflake is slow for users in china
16:36:52 <shelikhoo> so when government found obfs4 ip and block then, users switch to snowflake
16:37:19 <shelikhoo> and when bridge operators get new ip, and user update their bridge line
16:37:34 <shelikhoo> they switch back to obfs4, since it is faster than snowflake in china
16:37:46 <shelikhoo> but this is just a guess, I have zero evidence...
16:38:55 <shelikhoo> EOF
16:39:12 <itchyonion> Did we patch anything on obfs4? I couldn't find what's causing the recovery.
16:40:04 <shelikhoo> there are new bridges showing up once for a while
16:40:04 <meskio> no, it could be just temporary censorship
16:40:15 <meskio> like the block "random looking" traffic
16:40:15 <shelikhoo> or just temporary censorship
16:41:02 <itchyonion> i see. Anything else we want to discuss today?
16:41:18 <shelikhoo> one more thing from me...
16:41:28 <shelikhoo> dcf1: I have reimplemented meek in V2Ray. It may get a sun set at Tor, but it still shining somewhere else in the world. Thanks dcf for its design and original implementation.
16:41:28 <shelikhoo> https://github.com/v2fly/v2ray-core/releases/tag/v5.7.0
16:41:28 <shelikhoo> Here is a guide on how to set it up from one of users.
16:41:28 <shelikhoo> https://cscot.pages.dev/2023/05/31/v2ray-meek/
16:41:30 <shelikhoo> over!
16:42:02 <dcf1> shelikhoo: oh, that's good to know, thank you
16:42:12 <shelikhoo> no no no thank you!!!
16:42:24 <shelikhoo> EOF
16:42:42 <itchyonion> #endmeeting