15:58:23 <meskio> #startmeeting tor anti-censorship meeting 15:58:23 <MeetBot> Meeting started Thu Feb 9 15:58:23 2023 UTC. The chair is meskio. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:58:23 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 15:58:29 <meskio> hello everyone!!! 15:58:31 <meskio> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 15:58:35 <meskio> feel free to add what you've been working on and put items on the agenda 15:59:24 <shelikhoo> Hi! 15:59:49 <meskio> shelikhoo: I kept the packet lost in point in the agenda, but I can remove it if there is nothing to update there 16:00:47 <cohosh> hi 16:01:40 <onyinyang[m]> Hello! 16:01:46 <cohosh> onyinyang[m]: hey! 16:01:54 <cece[m]> hi 16:02:10 <meskio> wellcome onyinyang[m] nice to read you here!!! 16:02:25 <shelikhoo> meskio: let's remove it, nothing to update yet 16:02:42 <meskio> ack 16:03:39 <meskio> we have a short agenda for today then :) 16:03:47 <meskio> the first point is from last week: 16:03:49 <onyinyang[m]> meskio: long time lurker, second-ish time participator 😆 16:03:56 <meskio> "Conjure is in nightly versions of Tor Browser now, an update on how it's going and the roll out plan" 16:04:19 <meskio> onyinyang[m]: sounds good to move from lurker to participator :) 16:04:25 <cohosh> ok i'll just give a brief update on that 16:04:42 <cohosh> we've been working on integrating conjure as a PT for tor 16:05:33 <cohosh> it's been a PT for psiphon for awhile now, and the library is still maintained by the researchers at CU Boulder 16:05:38 <cohosh> client-side library: https://github.com/refraction-networking/gotapdance 16:05:52 <cohosh> station: https://github.com/refraction-networking/conjure/ 16:06:33 <cohosh> so the tor PT on the client-side is sort of a wrapper that makes it communicate with the tor process 16:07:02 <cohosh> and on the bridge side, connection from the station to the conjure tor bridge happen using the haproxy protocol 16:08:03 <cohosh> right now the features we support are minimal, to just get something working but the hope is that this will offer a slightly different set of censorhsip-resistant features than e.g., snowflake 16:08:26 <cohosh> for example, it supports refraction networking (aka decoy routing) for the registration step 16:08:34 <cohosh> and dpesm 16:08:40 <cohosh> *and doesn't rely on stun 16:09:17 <cohosh> there are a few pain points like an overloading of the station that's been happing due to the internet shutdowns in iran 16:09:38 <cohosh> and some other reliability issues we're actively debugging in the connections between the stations and the bridge 16:10:28 <cohosh> i'm considering a turbotunnel like solution to those and im curious about if anyone has tried it out and what their thoughts on this are 16:11:30 <meskio> it sounds pretty cool, amazing work 16:11:32 <shelikhoo> nice! congrats cohosh! 16:11:35 <meskio> what is dpesm? 16:11:45 <cohosh> a typo of "doesn't" heh 16:12:07 <meskio> ahh, now I'm pasing the sentence :) 16:12:23 <meskio> I thought was some cool protocol or something I should learn about 16:12:25 <meskio> :D 16:12:38 <cohosh> xD maybe it is 16:13:49 <meskio> will using turbotunnel would allow reconnections without having to redo the tor circuit like in snowflake? 16:14:17 <shelikhoo> meskio: yes, it is kcp + connection stability assist 16:14:25 <shelikhoo> and is not tied to tor 16:14:25 <cohosh> yeah, it's a similar idea 16:15:05 <meskio> I guess it will face the same complexities to allow multiple bridges, but we have the snowflake experience there, sounds good 16:15:14 <cohosh> i thought conjure would be more usable than snowflake without it because the proxy connections go through one of several dedicated servers 16:16:04 <cohosh> but these connections aren't as reliable as I hoped, even beyond the load issues 16:16:40 <cohosh> plus there are good arguments for turbotunnel beyond just reliability within a connection 16:17:03 <meskio> do you know from where the reliability issues are comming from? 16:17:07 <cohosh> or rather, there are arguments for turbotunnel with even straightforward client-server PTs 16:17:16 <shelikhoo> personally, I think turbo tunnel uses kcp, which increases network load. So... 16:17:33 <onyinyang[m]> Yeah I was wondering the same as meskio 16:17:47 <cohosh> meskio: i don't have access to the station for debugging, so i'm not 100% sure, but some of them are from load 16:18:26 <cohosh> others are due to the station having difficulty with the connection to the bridge and not timing out that conneciton properly 16:18:29 <shelikhoo> we might wants to make sure there is enough station... it is harder to find a conjure station than setting up a snowflake server 16:18:50 <cohosh> shelikhoo: yes this is a real struggle 16:19:02 <cohosh> and part of why we're not going to make conjure a built-in bridge any time soon 16:19:37 <cohosh> shelikhoo: good point on the kcp and network load, though the load might have more to due with limitations on number of connections rather than bandwidth 16:19:48 <cohosh> i'm honestly not sure 16:20:28 <meskio> it could be a good replacement for meek, as meek might stop working this year, something slow and unreliable but that works often will be a good option in some cases 16:21:22 <shelikhoo> yes... we might wants to find out why it is not stable if possible... 16:22:11 <meskio> sure, I agree, I just mean is still usefull even if is not great 16:22:36 <cohosh> yeah i've been looking into the station code as well as trying to figure out some simple client-side changes that will improve the experience 16:23:05 <cohosh> meskio: yeah this seems like it will eventually be a "use in extreme cases" kind of tool for us at least 16:23:21 <meskio> good luck with that, it shounds like painful to debug 16:24:13 <meskio> even if there is not builtin bridge, if stable TB supports it we can always enable it if needed in some locations by circumvention settings 16:24:32 <shelikhoo> debugging without access sounds challenging.. 16:26:06 <cohosh> yeah, to be clear, this is very much run by the conjure devs and not us which is good in many ways but it does mean that we don't have direct access or as much control as with snowflake 16:26:17 <cohosh> but i would like to help out if we can! 16:26:36 <shelikhoo> for meek we was able to domain fronting without explicit approval from cloud providers 16:26:53 <cohosh> there's a test environment setup based on libvirt that's linked the readme if anyone wants to play with it in their spare time 16:27:13 <cohosh> but i think a lot of the load would be difficult to replicate 16:27:19 <shelikhoo> but for conjure, isp have to agree to run this on their network.. 16:27:35 <cohosh> yeah 16:28:17 <cohosh> it's an advocay and business relationship job to run a station 16:28:21 <cohosh> *advocacy 16:28:53 <cohosh> and the conjure peeps have done a good job of making those relationships but it's also been difficult from what i understand 16:29:02 <shelikhoo> yes... let's see if we can get more stations... 16:29:48 <cohosh> okay i think that's all from me on this, thanks for the feedback \o/ 16:30:43 <meskio> I guess if we get some success stories with the existing ISP we might manage to convince others 16:31:24 <meskio> but, step by step, is great to see it working, and I see there are already a bunch of users reporting how it works for them 16:32:17 <meskio> anything else on this topic? 16:32:24 <meskio> should we move to the next one? 16:33:02 <meskio> the next one is snowstorm 16:33:33 <meskio> serene the original snowflake author has launched a 'snowflake succesor' or something like that: 16:33:54 <meskio> https://www.forbes.com/sites/johanmoreno/2023/02/08/as-the-internet-freedom-project-expands-snowflake-becomes-snowstorm/?sh=148126cc1c33 16:34:17 <meskio> there is not much information, besides a website comparing the two 16:34:37 <meskio> https://snowstorm.net/ 16:34:57 <meskio> and a website with some stadistics taken from tor's snowflake usage https://snowstorm.earth/ 16:36:07 <meskio> not sure if there is much to discuss here, will be great to hear more from the project and to try to learn from their experience 16:36:44 <dcf1> there is a lot of interest in having something snowflake-like that is separate from tor 16:37:03 <dcf1> I have been asked about the possibility a few times. This is the first I've heard of serene's snowstorm. 16:37:23 <meskio> yes, and we've being slow on helping that process 16:38:38 <dcf1> and we've also heard from lantern that is working on something similar 16:40:39 <meskio> seems to be some interest on webrtc and the success of snowflake 16:40:59 <shelikhoo> I also have a project named webrtcTunnel that creates a UDP tunnel between devices, without forwarding things over a third server 16:41:13 <shelikhoo> (this is how shell) 16:41:40 <meskio> :) 16:41:53 <shelikhoo> (this is how shell's VPN between IE and CN works) 16:41:53 <ggus> shellstorm :) 16:42:31 <meskio> :D 16:44:00 <shelikhoo> but anyway I have nothing more on this topic 16:44:06 <meskio> anyway, I guess is a proyect to keep an eye on and see what it brings, anything else on this topic? 16:44:37 <meskio> next topic: 'raw probe log from logcollector is available for download' 16:44:41 <meskio> shelikhoo: ??? 16:44:47 <shelikhoo> yes, this is from me 16:45:46 <shelikhoo> the raw probe log download function is already finished. and one can download the raw log from url from proberesult file 16:45:52 <shelikhoo> with a password 16:46:54 <meskio> nice 16:47:13 <shelikhoo> I am still waiting response from meskio about sharing access... but if I have made a mistake and you didn't receive the email with password, please let me know 16:47:51 <shelikhoo> the link will expire, so don't wait to download it 16:47:52 <meskio> ohh, where should I respond? 16:47:54 <cohosh> shelikhoo: that's awesome, it sounds like this will be really useful for detecting/debugging censorship 16:48:03 <cohosh> is there a plan to share it with research groups? 16:48:24 <meskio> shelikhoo: I see the email, yes, what you say sounds good 16:49:08 <shelikhoo> okay, I will share access to cohosh, dcf1, itchyonion, arma2 after this meeting 16:49:19 <meskio> :) 16:50:12 <shelikhoo> as for research group, I think they could request access and we could process it in a case by case basis 16:50:41 <shelikhoo> unless there is a better plan... 16:50:45 <cohosh> nice 16:51:21 <meskio> I don't have a better idea, that plans sounds good 16:51:31 <shelikhoo> nothing more from me about this topic 16:52:32 <meskio> good, I guess we are done with the meeting if no one has anything else 16:53:00 <shelikhoo> cohosh: yes, it is making things more convenient... 16:54:00 <meskio> #endmeeting