15:57:56 <shelikhoo> #startmeeting tor anti-censorship meeting 15:57:56 <shelikhoo> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 15:57:56 <shelikhoo> feel free to add what you've been working on and put items on the agenda 15:57:56 <MeetBot> Meeting started Thu May 25 15:57:56 2023 UTC. The chair is shelikhoo. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:57:56 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 15:58:00 <shelikhoo> Hi! Hi! 15:58:02 <meskio> hello 15:58:12 <onyinyang[m]> helloooo o/ 15:59:45 <cohosh> hi 16:00:27 <onyinyang[m]> hmm I didn't update the discussion from last week for this week so some (all?) of those points are old. . . 😅 16:01:44 <meskio> I guess we can remove the poing on snowflake block on china 16:02:00 <meskio> but I belive shelikhoo wanted to talk about the speed deficiency 16:02:04 <meskio> maybe the others can go 16:03:13 <shelikhoo> yeah, I think we should have an discussion but the snowflake's speed issue and my proposed fix 16:03:54 <meskio> can we remove the armored bridges and the lox churn as well? 16:04:29 <shelikhoo> i think for armed bridge, did we agree to not include forward error correction 16:04:53 <shelikhoo> if so it can be removed, I can proceed to write a draft about what the protocol would look like 16:04:54 <meskio> I agree with not including it, but I don't have a strong opinion 16:05:06 <shelikhoo> and have a reference implementation for testing 16:05:17 <shelikhoo> maybe we can just don't include for now 16:05:28 <shelikhoo> and have something we have poke with first 16:06:59 <meskio> +1 16:07:13 <shelikhoo> yes, then discussion about that is done 16:07:49 <onyinyang[m]> I think the bridge churn links are for reference. I have them all opened in tabs to look at 😅 dcf1 is there anything more to discuss there for now? 16:08:07 <dcf1> no 16:08:32 <shelikhoo> okay, let move to the first topic! 16:08:33 <shelikhoo> 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:09:45 <shelikhoo> after some discussion with dcf1, I think the choice about design is basically narrowed down to a few single choices 16:10:10 <shelikhoo> first, how should client id be transferred 16:10:55 <shelikhoo> what will be the inner protocol protocol within webrtc data channel 16:12:05 <shelikhoo> we either have a micro protocol to transfer client ID info within the data channel 16:12:42 <shelikhoo> or we transfer that with SCTP(webrtc data channel)'s built in connection name system 16:14:04 <shelikhoo> the plan A: micro protocol can give us more room for improvement when it comes to updating the protocol, since it will already have the overhead to do that 16:14:35 <shelikhoo> but it would be more complex to implement, thus more thing could go wrong 16:15:50 <shelikhoo> than plan B: use datachannel's built in system are simpler, but does not give us advantage for future upgrade. 16:17:29 <shelikhoo> I have a tendency to make things more complex than necessary... but there are things to gain for get it done in the harder way 16:17:41 <cohosh> do you have something in mind for what you'd update the protocol to include other than the connection id? 16:17:57 <shelikhoo> yes, to add padding and fragmentation 16:18:18 <shelikhoo> so that if snowflake is identified by traffic shape 16:18:32 <shelikhoo> we can just upgrade the client and server to workaround it 16:19:23 <shelikhoo> otherwise we would need to upgrade the proxy as well, which is super time consuming 16:20:39 <shelikhoo> okay, that's opinions from me about this issue 16:21:45 <cohosh> i tend to prefer doing things the simpler way first, especially if that won't necessarily make future improvements harder 16:22:44 <cohosh> in this case, it's not precluding defining an inner protocol, right? it just delays introducing it? 16:23:16 <dcf1> shelikhoo: have you begun prototyping? You have outlined the pros and cons of different approaches well, does it require a decision now or could that come out of an iteration of prototyping? 16:24:04 <shelikhoo> i have not begin prototyping, we can have decision what to try first 16:24:33 <dcf1> okay, you want more feedback and a decision before you begin any implementation 16:25:03 <shelikhoo> yes, if something goes wrong, I can always changes things later 16:25:08 <shelikhoo> but it would cost time... 16:26:00 <dcf1> I will just say that it's easy for me to make pronouncements when commenting on a ticket, not having to do the actual work. I hope I have provided some good food for thought, but I'll defer to your decisions when you are the one in close contact with the actual problems. 16:26:19 <shelikhoo> (and I have so many things to do, it would be too slow to implement a lot of unused design) 16:26:58 <shelikhoo> yes, so just wants to know if there any unknown pro or cons about either design 16:27:54 <dcf1> if you are looking for the team's approval of the choice you prefer, I would suggest to start making working on that choice and see how it goes 16:28:16 <cohosh> agreed :) 16:28:23 <shelikhoo> yes... 16:28:57 <shelikhoo> okay I will then just proceed with plan A.. ^~^ 16:29:13 <dcf1> for me, I don't foresee a need for any features in the inner protocol beyond the ability to add padding. I do think the ability for padding (not necessarily fragmentation) is essential, but I don't think there will be a need for extensibility beyond that, if it helps. 16:29:36 <shelikhoo> okay, let's move to the next topic, I will have a write summary of design choices 16:29:42 <meskio> sounds good to go for simple 16:29:48 <meskio> we can always complicate it later... 16:30:06 <cohosh> meskio: i think A is the less simple, but future-proof case 16:30:09 <meskio> ahh, no, you were going for the complex 16:30:10 <shelikhoo> meskio: X~X actually i can picking one complex one... 16:30:14 <meskio> :D 16:30:17 <meskio> ups 16:30:24 <shelikhoo> but anyway, let try it... 16:30:24 <meskio> anyway, I trust you to know better :) 16:31:10 <shelikhoo> okay let's move to the next topic 16:31:10 <shelikhoo> PT implementation version in the descriptors 16:31:10 <shelikhoo> https://gitlab.torproject.org/tpo/core/tor/-/issues/11101 16:31:10 <shelikhoo> Will be included in next Tor version (0.4.8???) 16:31:10 <shelikhoo> we'll need to update goptlib and the different PTs 16:31:17 <shelikhoo> meskio, I think this is from you? 16:31:25 <meskio> yes 16:31:57 <meskio> I've being talking with the network team and they are going to add the changes to include the implementation of the pt in the descriptors in the next tor version 16:32:12 <dcf1> is that tpo/core/torspec!63? 16:32:16 <meskio> we'll need to change goptlib and the PTs acordingly 16:32:23 <meskio> dcf1: yes, that one 16:32:41 <meskio> but there is no rush, there is no tor implementation for it yet 16:32:52 <meskio> I just wanted to share that this is moving :) 16:33:47 <meskio> they are also planning to include https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/688 16:33:52 <shelikhoo> I think it is nice that is is moving.... 16:33:55 <meskio> that we were discussing last week about 16:35:07 <meskio> I'll create an issue once tor is ready to test that 16:35:18 <meskio> I mean an issue about the pt implementation 16:35:22 <meskio> that is all from my side 16:36:47 <shelikhoo> yes! nice! thanks! let's see what happens then 16:37:04 <shelikhoo> too bad snowflake proxies won't report version in this way 16:37:46 <meskio> yes, we might want to make the proxies report their version to the broker, or are they alredy doing that? 16:37:57 <meskio> they do the implementation 16:38:21 <shelikhoo> i think they are already doing that in some way, but we don't have a chart available 16:38:41 <cohosh> it's a part of the protocol to have them report a version number, but it's traditionally been the version /of that protocol/ rather than the package version 16:39:20 <meskio> I see, I recall there was a protocol version there 16:39:29 <shelikhoo> anyway, reporting the version is quite important as we are seeing a lot of need to update protocol to deal with censor and scaling 16:39:34 <cohosh> there's nothing preventing us from increasing it to the package version though 16:40:13 <shelikhoo> yes, or it could have two part 16:40:25 <shelikhoo> the first part is protocol version 16:40:34 <shelikhoo> and then implementation version 16:41:31 <cohosh> i don't think it's worth having two, the implementation is probably sufficient for both 16:42:30 <meskio> there are at least two implementations, but we could keep a table of what features are supported by what version+implementation... 16:42:39 <shelikhoo> yes, but we might need to split the webextension and standalone version anyway 16:43:04 <shelikhoo> it will be like v1.3/standalonev3.5 16:43:37 <cohosh> ah i see 16:44:05 <shelikhoo> so that we can track the the each implementation's adoption 16:44:07 <shelikhoo> yes 16:44:11 <meskio> cool, we are going towards a browser user-agent :) 16:44:29 <shelikhoo> X~X 16:44:49 <shelikhoo> anyway, that is the last topic in the pad 16:44:59 <shelikhoo> anything more we would like to discuss? 16:45:05 <meskio> not from me 16:46:56 <shelikhoo> okay no need to keep everyone here any longer, have a nice day/weekend! 16:46:57 <shelikhoo> #endmeeting