16:01:42 <shelikhoo> #startmeeting tor anti-censorship meeting
16:01:42 <shelikhoo> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
16:01:42 <shelikhoo> feel free to add what you've been working on and put items on the agenda
16:01:42 <MeetBot> Meeting started Thu Jan 26 16:01:42 2023 UTC.  The chair is shelikhoo. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:42 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:01:49 <shelikhoo> okay let's me host it
16:02:08 <shelikhoo> sorry for the wait, unsure what happened
16:04:47 <itchyonion> hello
16:05:51 <cece[m]> hello
16:06:15 * arma2 adds a discussion item about https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40250
16:07:08 <shelikhoo> I didn't see a lots of new changes, let's begin the discussion phase...
16:07:36 <shelikhoo> this is a topic from last week: "does the anti-censorship team want a paid-for host to run STUN/TURN servers on?"
16:07:47 <shelikhoo> do we have any new on this topic
16:08:19 <shelikhoo> like more context about exactly what we want
16:08:32 <cohosh> i can just fill in my side of things
16:08:36 <shelikhoo> yes
16:09:07 <cohosh> ln5 sent me an email to follow up on the funding situation for stunprotocol.org and whether we were able to get support from tpo for it
16:09:25 <cohosh> (it looks like we can send them some funds but i'm still waiting to hear back on costs)
16:10:05 <cohosh> in addition, ln5 asked whether it would be useful to run STUN or TURN servers and i mentioned that what might be useful is a sort of dynamic or rotating STUN server where we can change the IP address or ports
16:10:27 <cohosh> because some places like TM appear to block both default STUN ports
16:10:48 <ln5> ohi
16:10:50 <cohosh> so this would give us a built-in STUN server that we could alter to try and avoid blocking
16:10:55 <cohosh> ln5: hey!
16:11:08 <cohosh> it's just an idea, i'm curious what others here think about it
16:11:50 <arma2> we would list it by fqdn so we could move it around and not change clients? or hm for the ports we would...put it on the bridge line and then give clients a new bridge line when we change the port?
16:12:30 <cohosh> yeah we'd have to use circumvention settings or TB updates to change the port, which may or may not work in TM anyway
16:13:06 <cohosh> that's a good point though that using a fqdn makes the task of rotating the IP more convenient for us than with our obfs4 dynamic bridges
16:13:23 <cohosh> unless they do dns blocking
16:14:09 <arma2> right, i think if our goal is to have this be useful against an active censor who knows about it... it is a losing battle
16:14:15 <shelikhoo> in order to transmit the port info in dns, we would need to use srv or txt record
16:14:29 <arma2> but if the goal is to have another tool in the toolbox for debugging against censors who don't care that much, it sounds like it could be useful
16:14:41 <shelikhoo> which is not typically used by regular users
16:15:03 <shelikhoo> (or we can be creative about the use of AAAA record)
16:15:51 <arma2> if i remember correctly, we had some surprises where pion asks stun questions way more often than it needs to? like, it could cache things but it doesn't?
16:16:20 <WofWca[m]> As long as STUN packets are not encrypted, censors can just block the STUN protocol altogether.
16:16:24 <arma2> (if yes: do we have a ticket yet for fixing that behavior? :)
16:17:26 <cohosh> arma2: i don't think we have an issue for that, no
16:17:33 <cohosh> it would be good to make one
16:18:54 <cohosh> WofWca[m]: yes, though in practice there are usually gaps between something sensors could do and what they actually do
16:19:09 * arma2 adds a note to the Actions section of the pad, for that ticket
16:19:33 <cohosh> it's possible TM is already doing some kind of DPI to detect and block STUN, but the last time we looked at it, there was an AS in TM that was only blocking 3478 and not 3479
16:19:41 <arma2> WofWca[m]: right, blocking all of the stun protocol potentially has collateral damage, in a way that blocking our specific stun server, used only by us, does not.
16:19:52 <itchyonion> I'm a little concerned that If the stun server is mainly used by us, censors can block it pretty easily without worrying about collateral damage
16:20:28 <shelikhoo> blocking STUN sometime have unintended consequence such as get government's own video chat system broken
16:20:48 <arma2> another angle of worry: using our own little stun server for debugging sounds great, but having an entire country of people use it, if it works, is a different story in terms of risk.
16:20:51 <cohosh> whoops s/sensors/censors
16:20:57 <ln5> fwiw, if the value of specific STUN/TURN services for snowflake is more "meh" than "wohoo" *and* there are no other new needs for anti-censorship services at the moment, i think we could drop the idea of seeking funding for this now and maybe revisit it later
16:21:22 <shelikhoo> so for russia, they only block pion's dtls implementation, but not browser's webrtc stack
16:22:03 <cohosh> ln5: okay that makes sense, this does sort of feel like we're just throwing things out there on the off chance it might work somewhere for a while, without a clear need right now
16:22:03 <meskio> hello (I over slept the siesta)
16:22:13 <arma2> re the 'seeking funding' side, i believe the money machine has already moved on and is thinking of pitching 'general tool cleanup and maintenance' to this funder
16:22:47 <WofWca[m]> itchyonion:  But clients do use a bunch of STUN servers already, including Google.
16:22:55 <cohosh> arma2: yeah, we're waiting on the operator of stunprotocol.org to get back to us at the moment
16:23:03 <arma2> cohosh: right. in terms of 'critical path to being unblocked', fixing the fact that russia blocks pion by dpi seems like a much clearer win. though maybe not as easy i guess.
16:23:45 <ln5> arma2, cohosh: good, let's settle the funding of operations for now
16:24:06 <cohosh> ln5: thanks for bringing this up, it was a good to discuss
16:25:32 <shelikhoo> arma2: I have already finished fixing that dtls block by russia 1 week ago, it is now waiting to be accepted into tor browser
16:25:38 <arma2> yay
16:25:39 <ln5> cohosh: thanks for bringing the idea to the meeting, when i'm too unfocused to be organised enough
16:26:10 <shelikhoo> anything more on this topic?
16:26:25 <arma2> cohosh: the idea of being able to spin up a stun server briefly, for testing, on a port/address we control, is still a good one
16:26:42 <arma2> but it wouldn't need a dedicated computer, to scale to many users, etc. it could just be a thing we ask tpa to let us spin up when needed.
16:27:06 <arma2> so, don't discard that part of the idea quite as quickly :)
16:27:09 <cohosh> yep, and it probably wouldn't cost enough to have to worry about external funding
16:27:13 <arma2> yep
16:27:15 <itchyonion> WofWca yea, I'm assuming the other ones (google, etc) are also used for general purposes like voice chat. But if a stun server is mainly used by people to escape censorship, they can block that particular server with little concern for collateral damage
16:28:40 <shelikhoo> okay, anything more about this topic?
16:28:58 <shelikhoo> snowflake fallback from domain fronting to amp cache, how/whether/when/etc to implement (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40250)
16:30:05 <arma2> right, i was the one who added this, but i probably don't have the most to say about it
16:30:26 <arma2> is snowflake good at knowing when domain fronting failed, and it would want to fail over to another try? like, does that code exist and work well?
16:30:39 <arma2> s/to another try/to try another option/
16:30:49 <meskio> I did open the issue, but I don't have much inside there
16:31:05 <shelikhoo> I think there is actually two separate issue
16:31:18 <shelikhoo> first is how to pass a longer setting into snowflake
16:31:30 <shelikhoo> and the second is how to do fallback
16:32:05 <shelikhoo> let's discuss the first one first?
16:32:27 <arma2> yes. or maybe rephrase the first one to be broader: how to best configure snowflake to know about having two options
16:32:50 <arma2> (e.g. have a longer bridge line; put it on the command line; hard code it in snowflake; etc)
16:33:18 <arma2> what does orbot do here? i hear they have amp cache on by default?
16:33:25 <cohosh> arma2: it's still the the current behaviour of tor to simultaneously connect to all Bridge lines right?
16:33:44 <cohosh> because we could push this logic to tor if there are already plans to change how it handles multiple bridge lines
16:34:21 <arma2> cohosh: yes, that is current behavior
16:34:33 <arma2> now that i am back from japan i have been thinking to go explore whether it is easy or hard to fix it,
16:34:50 <arma2> but the fix we imagined would be "shuffle your bridges at random and then only use the first two that work",
16:35:07 <arma2> not some more complicated "these are priority 1 bridges, and use those if available, but here are priority 2 bridges if not"
16:35:39 <cohosh> okay cool
16:35:42 <meskio> yes, I think the shuffle is the best to be able to provide things like the full list of builtin obfs4 bridges
16:35:43 <arma2> so, i plan to have some useful guesses for us about how hard that hack would be, by next week, if this is a direction we think we need
16:36:11 <arma2> (tor already shuffles your bridges at random and uses the first two that work -- it just also connects to all the rest of them periodically too, for no particular benefit)
16:36:14 <meskio> arma2: that will be great, thanks :)
16:36:18 <cohosh> thanks!
16:36:22 <shelikhoo> thanks!
16:36:28 <arma2> ok, i will bump that up on the priority list
16:36:30 * arma2 writes it on pad
16:37:03 <arma2> https://gitlab.torproject.org/tpo/core/tor/-/issues/40578 is the ticket
16:37:37 <shelikhoo> we can keep the topic on the pad, and skip the discussion about how to do the fallback in snowflake itself for now
16:38:15 <shelikhoo> since we are considering let C-tor do the fallback part
16:38:18 <arma2> i guess the plan would be to have n bridge lines, for each permutation of snowflake-0x and domain-fronting-or-amp-cache?
16:38:44 <arma2> and then the same number of users would use amp cache as would use domain fronting? is that ok?
16:39:33 <arma2> ..what does orbot do? :)
16:39:58 <meskio> AFAIK orbot uses domain fronting by default and have a manual configurable option to use ampcache
16:40:18 <arma2> ah ha so they don't have any auto fallback mechanism. or really any auto way at all that you might come to use amp cache.
16:40:19 <shelikhoo> I think that would be fine in my point of view
16:40:28 <meskio> I guess even if ampcache is a bit slower it should not be a huge difference, but I have tried
16:40:49 <shelikhoo> yes, and in Tor Browser I don't think there is a way to configure amp cache way in the UI
16:40:57 <arma2> i guess there are wild hacks like having 5 bridge lines that use domain fronting and only two that use amp cache. hacky hacky
16:41:06 <meskio> (maybe is not even slower)
16:42:32 <arma2> seems like we should have some plan in parallel to figure out whether the amp cache option is working the way we hope
16:42:41 <arma2> like, if we send half our users there, how will we know if it's good or bad
16:44:23 <shelikhoo> I don't think we have a system in place to run AB testing...
16:44:44 <meskio> shelikhoo: TB alpha?
16:45:04 <meskio> we could use ampcache by default in Tor Browser alpha, an see how it goes
16:45:09 <shelikhoo> oh! yes
16:45:15 <shelikhoo> we could do that
16:45:17 <arma2> maybe it is as simple as adding a 'snowflake with amp cache' line to one of the bridgestatus testers?
16:45:35 <meskio> or we could do some AB testing with Circumvention Settings, but I'm a bit more hesitant with that one
16:45:55 <arma2> all of these are plausible to me. i just wanted to bring it up as a thing we will soon wish we had thought about :)
16:46:01 <shelikhoo> yes, getting it into bridgestatus seems a reasonable step
16:46:27 <arma2> speaking of domain fronting, i talked to a contact at fastly who frowned at me when i told him we are happy users of fastly domain fronting. apparently they have been phasing it out for a while and if it is still working for us it's because we're listed as an exception.
16:47:06 <arma2> i tried to reassure him that we are a good use case, we're not sending our main traffic over it, etc. he was....partially convinced. :)
16:47:15 <cohosh> :-S
16:47:24 <meskio> ohhh
16:48:04 <shelikhoo> (we are good user until solider with assault rifle arrive at their data center)
16:48:27 <arma2> he is the fellow who runs fastly's certificate authority program. used to run mozilla's. so i guess on the plus side, i now have a good fastly contact who likes us, for when that time comes.)
16:48:37 <shelikhoo> or even a letter from government would do....
16:48:47 <shelikhoo> yes...
16:49:37 * arma2 has no more on this topic
16:50:05 <shelikhoo> anything more on this topic from anyone?
16:50:24 <shelikhoo> use ampcache in IR?
16:50:24 <shelikhoo> https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/115
16:50:24 <shelikhoo> https://gitlab.torproject.org/tpo/anti-censorship/rdsys-admin/-/merge_requests/13
16:50:33 <meskio> I added that
16:50:40 <shelikhoo> yes
16:50:55 <meskio> it looks like ASes in Iran are blocking our domain used for domain front
16:51:06 <meskio> both for snowflake and circumvention settings
16:51:26 <meskio> this spawns several problems that we need to work on (see team#115)
16:51:26 <tor> Uhm, which one of [tpo/anti-censorship/team, tpo/applications/team, tpo/community/team, tpo/core/team, tpo/network-health/metrics/team, tpo/network-health/team, tpo/operations/team, tpo/team, tpo/tpa/team, tpo/ux/team, tpo/web/team] did you mean?
16:51:31 <arma2> the idea of 'ampcache in tor browser alpha' would help there too, right?
16:51:39 <arma2> i.e. "if you're in iran, try the alpha"
16:51:48 <meskio> yes that would be nice
16:51:51 <meskio> idea
16:52:26 <meskio> as a first step I'm considering configuring in Circumvention Settings to use amp cache by default in iran
16:52:29 <arma2> oh, speaking of which, would we use amp cache for circumvention settings too? it is only built for snowflake, right?
16:52:31 <arma2> (related to https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/111 )
16:52:47 <meskio> that means this configuration will be received by people that can still use domain fronting for snowflake
16:52:56 <meskio> as the others will not be able to reach circumvention settings
16:53:01 <arma2> right
16:53:18 <arma2> can we pick a different front domain?
16:53:22 <meskio> but the configuration will be kept around and if domain fronting gets blocked in ther AS they will keep using amp cache
16:53:35 <arma2> that makes sense
16:54:22 <meskio> cool, shelikhoo do you mind having a review into rdsys-admin#13 and if everybody is ok with it I'll apply that change?
16:55:00 <shelikhoo> yes, please assign that to me
16:55:38 <meskio> that alos means we will battle test amp cache, as we have tons of iranian snowflake users...
16:55:53 <meskio> we can always roll back that configuration if we see it failing too much
16:56:01 <meskio> s/alos/aslo/
16:56:44 <meskio> if we are all good with this, lets try it and see
16:57:19 <meskio> re about using amp cache in circumvention settings, I think is a great idea, I will create an issue for that and let's explore what is needed for this to happen
16:57:30 <shelikhoo> yes, let's try it...
16:57:58 <shelikhoo> is circumvention setting accessible to user in iran right now
16:58:10 <shelikhoo> with some domain fronting domain blocked?
16:58:15 <meskio> not in the ASes that block domain fronting
16:58:25 <shelikhoo> yes...
16:58:47 <meskio> I mean, I don't expect it to be accesible there, I haven't make any tests on that
16:58:53 <shelikhoo> so we still need get ampcache setting into tor browser alpha
16:58:57 <meskio> or heared any reports...
16:59:26 <meskio> yes, getting ampcache into TB alpha I think is a good move here too
16:59:29 <arma2> let's make sure we've considered "can we pick a different front domain?" too
16:59:34 <shelikhoo> so that users with sni for fronted domain blocked can access snowflake
16:59:34 * arma2 runs off, will read backlog in a bit
16:59:51 <shelikhoo> okay, the meeting is a little longer than should
17:00:03 <shelikhoo> is there anything we need to discuss in this meeting?
17:00:12 <meskio> yep, we should find another domain front
17:00:25 <meskio> nop, we can discuss that in the issue
17:00:28 <meskio> I'm good
17:00:33 <shelikhoo> #endmeeting