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