15:58:48 #startmeeting tor anti-censorship meeting 15:58:48 Meeting started Thu Feb 2 15:58:48 2023 UTC. The chair is meskio. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:58:48 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:58:52 hello everybody!!! 15:58:56 here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 15:58:58 hi! 15:59:06 feel free to add what you've been working on and put items on the agenda 15:59:17 hi~ 15:59:37 hi 16:00:05 hello world 16:00:43 hey ac-team, do you know if there is a ticket or a proposal about making bridge lines into human-memorable addresses? For example, instead of typing 'obfs4 IP:OBSF4_Port cert=' users would get something like this 16:01:07 AFAIK no, you have emojies, but just to check that the bridgeline is fine 16:01:18 ggus: i think more focus has been encoding the bridge info in a qr code 16:01:29 I think for information theory reasons, it is not possible to remember it by memory... 16:01:35 for most people 16:01:48 how many bits is the obfs4 cert? quite a few i suspect 16:02:00 ggus: do you want to be able to check if you got the same bridge? or to actually share full bridge information encoded there? 16:03:13 and, by 'check' do you mean be confident that you're right, even under attack? :) 16:03:35 meskio: i am in a different meeting, just one request from my side: could you check https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/150? we have some questions and it seems this is blocked by you 16:04:02 meskio: i want to share a bridge with users on frontdesk and then it would be easier to spot if they copied the wrong word. right now people are having a lot of issues copying such lines, ie, copying just a piece of it, removing part of the line, etc 16:04:17 GeKo: ack, I will check it 16:04:44 in this way, we can actually embed checksum into the bridge line 16:04:52 instead of let user check it manually 16:05:03 ggus: aren't emoji's enough to check if they are right? 16:05:03 obfs4 cert is 256 + 160 bits. 256-bit curve25519 public key and 160-bit nodeid. 16:06:27 re emojis, i guess the idea would be "copy this bridge line in, and if you got it right your emoji should look like this" 16:06:49 meskio: emojis could help on that, but the problem is copying the actual line. 16:06:51 kind of weird to do checksums as pictures, but, maybe it works better for non-numbers people :) 16:07:09 and type some words vs a bridge certificate is way easier 16:07:28 ggus: i think the problem here is that it would be like 30 words, not 4 16:07:29 I see, what you want is something that is easier to manually type if you can't copy paste 16:07:36 qr codes? 16:08:23 actually, i'd prefer to submit these formats (qrcodes vs words vs other thing) to user research 16:08:37 a list of words will be pretty long, we can make numbers of how long, but I expect long enough that people will also fail on copying them 16:09:07 ggus: great, let's open a ticket about it and we can produce examples of each of the options 16:09:27 ack! 16:09:35 will you open the issue? 16:09:41 I'll help producing the examples 16:09:44 yes, i'm opening now 16:09:49 thanks 16:09:59 nah: donuts: maybe this could be part of s30 ur? ^ 16:10:17 anything else on this topic? 16:10:27 ggus: also, knowing what sort of platforms these users are on (android vs windows) will change the question a lot 16:10:38 ggus: if it comes in time for testing in march/april, for sure! 16:10:38 yep 16:10:50 but I've seeing tails scanning qr-codes from a laptop... 16:10:59 well, we have quite a lot queued up for S30 already – so I'm not so sure 16:11:01 I mean using the laptop to scan the qr-code 16:11:02 we're currently working on a new circuit display 16:11:10 meskio: fun! 16:11:14 but we can definitely do UR for it _somewhere_ 16:11:37 :) 16:11:48 ;) 16:11:49 i am also super excited about this idea :D 16:12:24 maybe we could just do some light paper prototyping/figma-feedback initially 16:12:40 there is also the possibility that obfs4proxy could be modified to generate its cert deterministically using some password-based key derivation over a shorter, more memorable list of words 16:12:58 dcf1: hm! 16:13:00 like stretch 80 bits into 416 bits, or whatever is a comfortable security and usability threshold 16:13:14 good outside-the-box thinking 16:13:20 ohh, interesting idea 16:13:33 <+meskio> ggus: great, let's open a ticket about it and we can produce examples of each of the options <- this will be very useful, thank you! 16:13:39 yes, this is something we could do! 16:14:25 I think the issue here is that we can only generate private key deterministicly 16:14:48 shelikhoo: good point, I didn't think of that 16:15:26 right, you would need to get involved at the "creation of the bridge" step, not after 16:15:46 heck, by that reasoning maybe we can just shorten the cert 16:16:22 will be good to have a ticket for organizing all of these partially-baked ideas 16:16:47 (another partially-baked idea is that you don't *really* need the bridge fingerprint, if you trust-on-first-connection it) 16:16:59 the issue is that if the client would need to have the seed to generate the private key to generate its public key 16:17:09 so the security part of things changes 16:17:53 yep, if there's a trapdoor in key generation that results in fewer real bits of key, everything might be simpler just to use shorter keys from the beginning 16:18:44 anyway, ticket :) 16:19:06 great, let's discuss it in the issue that ggus is opening 16:19:14 and maybe we can move to the next topic 16:19:31 "snowflake fallback" 16:19:45 i made a branch that implements the 'only talk to first n bridges' idea 16:19:58 nice 16:20:01 it was a bit more complicated than expected, because i uncovered and fixed a few other, erm, tor surprises along the way 16:20:16 i can't predict whether the network team will say 'ok great' or 'wtf why would we change this' 16:20:35 but it is reasonable to imagine it could go into 0.4.8.1-alpha, whenever that comes out 16:21:01 if we need to push for having it in 0.4.7.x, which tor browser users would get sooner, that could happen but would require more convincing 16:21:17 the one big catch is: you can't have multiple bridge lines with the same fingerprint, 16:21:28 so if we go this route we'd want to deploy new bridges on the snowflake servers 16:21:57 i.e. one bridge for snowflake01+domainfronting, and a different bridge for snowflake01+ampcache 16:22:00 0.4.8 is not so far into the future if conflux goes in - some point in q2 i think 16:22:00 the change in c-tor is still useful for future snowflake with more than two bridges 16:22:41 AFAIK we have three options here for the fallback: 16:22:57 * multiple bridge lines as arma2 just mentioned 16:23:23 * no fallback, just different definitions in TB for snowflake-domain-front and snowflake-ampcache 16:23:40 * do a fallback on the snowflake client somehow, like we proposed with the binary args 16:24:09 tell us more about #2? what do you mean different definitions 16:24:33 like there used to be meek-google, meek-amazon visible in the settings UI 16:24:45 oh, ah ha, let the user click one or click the other. ok. 16:24:48 which was a workaround for the fact that the UI did not offer a way to change specific settings for one bridge line 16:25:14 so option 1 is mainly c-tor work, option 2 is mainly tor browser+ux work, option 3 is mainly snowflake work? 16:25:28 yes 16:25:34 it looks like we have more agency with 3... 16:25:45 agency => we don't push work to others 16:26:13 This is effectively what Orbot and Onion Browser do. "Snowflake method 1" and "Snowflake method 2" https://forum.torproject.net/t/iran-circumventing-censorship-with-tor/4590#orbot-for-android-28 16:27:00 We started this conversation when ampcache was merged, noting that our rendezvous configuration mechanism is a little jank 16:27:27 it was only a kind of happy coincidence that the ampcache could use the existing url= and front= parameters, and only added an ampcache= one 16:27:55 but other conceivable rendezvous methods could use an entirely different set of parameters, and we don't have a way to specify more than one at a time, let alone priority, etc. 16:28:38 option 1 lets you do 'more than one at a time' but isn't good at 'priority' 16:28:54 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/50#discussion 16:28:59 i think if we want genuine fallback, i.e. try this then try that, we want option 3 16:29:06 "The AMP cache rendezvous happens to coexist nicely with domain fronting rendezvous with respect to command-line options, because it needs the same two pieces of information (-url and -front), in addition to the new -ampcache. But conceptually, ..." etc. 16:29:50 last week, this problem was urgent, i.e. iran users needed some change urgently. this week it seems it is less urgent. can we predict next week? :) 16:29:58 This is where PT 2.0-style JSON configuration would be nice. 16:30:17 I think the best would be to encode in the bridgeline all the fallback options, but right now we have a limitation on size for the bridgeline 16:30:36 "rendezvous": [{"type": "domainfront", ...}, {"type": "ampcache", ...}, {"type": "dns", ...}] 16:31:18 yes, json format would be nice, but again making more complicated to copy bridgelines... 16:31:26 https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/117 16:31:33 thanks 16:31:36 dcf1: yep! and see also this ticket on an independent module to provide these options to anybody who needs a signaling channel: https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/111 16:32:05 a lot of users might have difficulty matching the brackets in the config file.. 16:32:15 based on my experience with json config... hahaha 16:32:34 shelikhoo: yeah, you might want to encode the bridge line into one big base64 blob or something -- using the ideas in gus's new ticket 16:32:56 or, better yet, make it so users never have to see or paste the bridge line 16:33:50 with snowflake there is the bridge configuration and global configuration (like signaling channel), but we put both in the bridgeline 16:34:15 meskio: maybe one way forward in your options is to learn if there is a snowflake developer who wants to implement fallback, and/or if there is an anti-censorship dev who wants to take charge of bridge line formats and fix them 16:35:24 json in base64 is also quite popular in v2ray ecosystem... often used to share a connection setting... I in general works fine until someone decided to add an extension to the scheme, which isn't an issue for Tor's use case 16:36:54 arma2: yes, I'm not sure how to prioritize it, as who knows when will it be needed again, but we can consider it part of s96 work 16:37:18 not sure if shelikhoo or itchyonion have cicles for it in the near future 16:37:42 actually this is two separate problem happening at the same time, if we go with 3. 16:38:09 right. 3a snowflake learns how to fall back, 3b bridge lines can include more info? 16:38:40 or maybe "3b find a way to tell snowflake more parameters" 16:38:43 shelikhoo could start work on it in 2~3 weeks time, if we can decide on plan by then 16:39:19 taking a step back, i think we have two decisions to make. one of them is: long-term, how do we want this problem solved? like, what is the actual right answer? 16:39:43 and then short-term, if next week we need to give snowflake+amp to iran, what is our best available hack 16:40:35 in short term, we could give user in iran a custom bridge line 16:40:45 I think that is a good framing, let's map the options in the issue and see what we are happy with there 16:42:17 maybe we can move to the next topic and continue this conversation in the issue 16:42:45 ampcache for snowflake in IR 16:43:02 it looks like they have remove the block after 9 days 16:43:12 anything on this topic? 16:43:50 let's move then to 'packet loss with snowflake in china' 16:43:52 shelikhoo: ??? 16:44:14 The packet loss between snowflake client and matched proxy is too high 16:44:30 when testing from vantage point in china 16:45:01 this have result in snowflake failed to get to enough speed to get tor bootstrap 16:45:03 is it a recent change? 16:45:43 there were favorable reports of snowflake usage in China at a recent (earlier this week) meeting organized by OTF localization lab 16:45:53 there were reports of slwoness, but not so much of unreliability 16:47:31 I don't think this is something sudden, over the last one year the bootstrap percentage drops gradually 16:47:54 ok 16:48:16 we only wait for 60 seconds for snowflake-tor to bootstrap 16:48:20 before ending the test 16:48:34 we could change this to a higher value 16:48:47 to give it more chance to finish bootstrap 16:49:00 if we are keeping track of time-until-bootstrap, giving it a longer timeout will give us more useful data 16:49:11 we can still compute "how many would have finished by 60s" from the better data 16:49:23 yes, I intent to increase it to about 300 seconds 16:49:32 yes, I intend to increase it to about 300 seconds 16:49:45 this is just from the one vantage point we have right? not from user reports? 16:49:56 i also wonder, how many of the timeouts come from having a snowflake but it is slow or loses packets, vs how many come from spending most of that time without a snowflake 16:50:01 this is just from vantage point 16:50:05 it's possible that vantage is unreliable 16:50:20 so if there is a way to annotate the data with "learned a snowflake here" that could be really useful 16:51:20 based on my own experience, the network connection between china and outside world is unreliable, and high packet loss is in general expected 16:51:22 also related to many long term goals, like being able to stripe over multiple snowflakes, which here would have the simpler benefit of "if there are two, and one never really works, at least the other might" 16:52:48 let's say there is a lot of snowflake connection with 20% packet loss 16:53:31 how does pion webrtc handle 20% packet loss? how does browser webrtc handle it? 16:53:33 I think we might wants to find a way to compensate for packet loss to increase connection speed despite the packet loss 16:53:42 we use kcp to handle this part 16:54:17 we asked pion webrtc to not deal with packet loss and let kcp to deal with it 16:54:47 i can unassign the kcp tuning tickets from myself btw, i don't have time to work on that for the next while, if you want to tackle it 16:55:19 I think we can have a design first, because right now, this is not an easy task for us 16:55:53 forward error correction is cpu consuming, and we are running packet reassemble at a single server 16:56:12 so i doubt there can be a simple solution to deal with this 16:56:29 forward error correction is cpu consuming, and we are running packet reassemble at a single server(or two) 16:57:02 cohosh: we can have a plan first before reassign the tickets... 16:57:09 over 16:57:18 shelikhoo: what is the plan here? will you continue investigating that and see if there is anything we can do there? do you need help there? 16:59:14 I think we can have a discussion at a ticket... I don't have a plan for how to deal with this issue right now... 16:59:26 giving the limitations 16:59:27 sounds good 16:59:46 maybe we can move to the next topic? 16:59:50 yes 17:00:14 conjure in nightly versions 17:00:17 my item can wait until next week 17:00:17 cohosh: ??? 17:00:22 since the meeting is running late 17:00:24 ok 17:00:26 sure 17:00:47 the last point is from ahf asking about things needed reveiw for s28 17:00:55 arma2: can you check with him about it? 17:01:00 maybe the answer is none? 17:01:06 i think arma2 and i can just sync about this next week 17:01:14 cool 17:01:20 it's more so we don't suddenly get a huge influx in stuff to review while people are fighting conflux finishing too 17:02:00 we don't have any high priority for c-tor, but there are few things that will be nice to get :) 17:02:26 then I guess we can finish the meeting here 17:02:29 #endmeeting