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