16:01:42 #startmeeting tor anti-censorship meeting 16:01:42 here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 16:01:42 feel free to add what you've been working on and put items on the agenda 16:01:42 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:01:49 okay let's me host it 16:02:08 sorry for the wait, unsure what happened 16:04:47 hello 16:05:51 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 I didn't see a lots of new changes, let's begin the discussion phase... 16:07:36 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 do we have any new on this topic 16:08:19 like more context about exactly what we want 16:08:32 i can just fill in my side of things 16:08:36 yes 16:09:07 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 (it looks like we can send them some funds but i'm still waiting to hear back on costs) 16:10:05 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 because some places like TM appear to block both default STUN ports 16:10:48 ohi 16:10:50 so this would give us a built-in STUN server that we could alter to try and avoid blocking 16:10:55 ln5: hey! 16:11:08 it's just an idea, i'm curious what others here think about it 16:11:50 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 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 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 unless they do dns blocking 16:14:09 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 in order to transmit the port info in dns, we would need to use srv or txt record 16:14:29 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 which is not typically used by regular users 16:15:03 (or we can be creative about the use of AAAA record) 16:15:51 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 As long as STUN packets are not encrypted, censors can just block the STUN protocol altogether. 16:16:24 (if yes: do we have a ticket yet for fixing that behavior? :) 16:17:26 arma2: i don't think we have an issue for that, no 16:17:33 it would be good to make one 16:18:54 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 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 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 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 blocking STUN sometime have unintended consequence such as get government's own video chat system broken 16:20:48 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 whoops s/sensors/censors 16:20:57 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 so for russia, they only block pion's dtls implementation, but not browser's webrtc stack 16:22:03 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 hello (I over slept the siesta) 16:22:13 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 itchyonion: But clients do use a bunch of STUN servers already, including Google. 16:22:55 arma2: yeah, we're waiting on the operator of stunprotocol.org to get back to us at the moment 16:23:03 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 arma2, cohosh: good, let's settle the funding of operations for now 16:24:06 ln5: thanks for bringing this up, it was a good to discuss 16:25:32 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 yay 16:25:39 cohosh: thanks for bringing the idea to the meeting, when i'm too unfocused to be organised enough 16:26:10 anything more on this topic? 16:26:25 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 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 so, don't discard that part of the idea quite as quickly :) 16:27:09 yep, and it probably wouldn't cost enough to have to worry about external funding 16:27:13 yep 16:27:15 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 okay, anything more about this topic? 16:28:58 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 right, i was the one who added this, but i probably don't have the most to say about it 16:30:26 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 s/to another try/to try another option/ 16:30:49 I did open the issue, but I don't have much inside there 16:31:05 I think there is actually two separate issue 16:31:18 first is how to pass a longer setting into snowflake 16:31:30 and the second is how to do fallback 16:32:05 let's discuss the first one first? 16:32:27 yes. or maybe rephrase the first one to be broader: how to best configure snowflake to know about having two options 16:32:50 (e.g. have a longer bridge line; put it on the command line; hard code it in snowflake; etc) 16:33:18 what does orbot do here? i hear they have amp cache on by default? 16:33:25 arma2: it's still the the current behaviour of tor to simultaneously connect to all Bridge lines right? 16:33:44 because we could push this logic to tor if there are already plans to change how it handles multiple bridge lines 16:34:21 cohosh: yes, that is current behavior 16:34:33 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 but the fix we imagined would be "shuffle your bridges at random and then only use the first two that work", 16:35:07 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 okay cool 16:35:42 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 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 (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 arma2: that will be great, thanks :) 16:36:18 thanks! 16:36:22 thanks! 16:36:28 ok, i will bump that up on the priority list 16:36:30 * arma2 writes it on pad 16:37:03 https://gitlab.torproject.org/tpo/core/tor/-/issues/40578 is the ticket 16:37:37 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 since we are considering let C-tor do the fallback part 16:38:18 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 and then the same number of users would use amp cache as would use domain fronting? is that ok? 16:39:33 ..what does orbot do? :) 16:39:58 AFAIK orbot uses domain fronting by default and have a manual configurable option to use ampcache 16:40:18 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 I think that would be fine in my point of view 16:40:28 I guess even if ampcache is a bit slower it should not be a huge difference, but I have tried 16:40:49 yes, and in Tor Browser I don't think there is a way to configure amp cache way in the UI 16:40:57 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 (maybe is not even slower) 16:42:32 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 like, if we send half our users there, how will we know if it's good or bad 16:44:23 I don't think we have a system in place to run AB testing... 16:44:44 shelikhoo: TB alpha? 16:45:04 we could use ampcache by default in Tor Browser alpha, an see how it goes 16:45:09 oh! yes 16:45:15 we could do that 16:45:17 maybe it is as simple as adding a 'snowflake with amp cache' line to one of the bridgestatus testers? 16:45:35 or we could do some AB testing with Circumvention Settings, but I'm a bit more hesitant with that one 16:45:55 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 yes, getting it into bridgestatus seems a reasonable step 16:46:27 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 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 :-S 16:47:24 ohhh 16:48:04 (we are good user until solider with assault rifle arrive at their data center) 16:48:27 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 or even a letter from government would do.... 16:48:47 yes... 16:49:37 * arma2 has no more on this topic 16:50:05 anything more on this topic from anyone? 16:50:24 use ampcache in IR? 16:50:24 https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/115 16:50:24 https://gitlab.torproject.org/tpo/anti-censorship/rdsys-admin/-/merge_requests/13 16:50:33 I added that 16:50:40 yes 16:50:55 it looks like ASes in Iran are blocking our domain used for domain front 16:51:06 both for snowflake and circumvention settings 16:51:26 this spawns several problems that we need to work on (see team#115) 16:51:26 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 the idea of 'ampcache in tor browser alpha' would help there too, right? 16:51:39 i.e. "if you're in iran, try the alpha" 16:51:48 yes that would be nice 16:51:51 idea 16:52:26 as a first step I'm considering configuring in Circumvention Settings to use amp cache by default in iran 16:52:29 oh, speaking of which, would we use amp cache for circumvention settings too? it is only built for snowflake, right? 16:52:31 (related to https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/111 ) 16:52:47 that means this configuration will be received by people that can still use domain fronting for snowflake 16:52:56 as the others will not be able to reach circumvention settings 16:53:01 right 16:53:18 can we pick a different front domain? 16:53:22 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 that makes sense 16:54:22 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 yes, please assign that to me 16:55:38 that alos means we will battle test amp cache, as we have tons of iranian snowflake users... 16:55:53 we can always roll back that configuration if we see it failing too much 16:56:01 s/alos/aslo/ 16:56:44 if we are all good with this, lets try it and see 16:57:19 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 yes, let's try it... 16:57:58 is circumvention setting accessible to user in iran right now 16:58:10 with some domain fronting domain blocked? 16:58:15 not in the ASes that block domain fronting 16:58:25 yes... 16:58:47 I mean, I don't expect it to be accesible there, I haven't make any tests on that 16:58:53 so we still need get ampcache setting into tor browser alpha 16:58:57 or heared any reports... 16:59:26 yes, getting ampcache into TB alpha I think is a good move here too 16:59:29 let's make sure we've considered "can we pick a different front domain?" too 16:59:34 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 okay, the meeting is a little longer than should 17:00:03 is there anything we need to discuss in this meeting? 17:00:12 yep, we should find another domain front 17:00:25 nop, we can discuss that in the issue 17:00:28 I'm good 17:00:33 #endmeeting