15:58:48 <meskio> #startmeeting tor anti-censorship meeting
15:58:48 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:58:52 <meskio> hello everybody!!!
15:58:56 <meskio> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
15:58:58 <hackerncoder> hi!
15:59:06 <meskio> feel free to add what you've been working on and put items on the agenda
15:59:17 <shelikhoo> hi~
15:59:37 <cohosh> hi
16:00:05 <arma2> hello world
16:00:43 <ggus> 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=<random strings>' users would get something like this <shorthand-displace-protract-uninsured-surround-alarm>
16:01:07 <meskio> AFAIK no, you have emojies, but just to check that the bridgeline is fine
16:01:18 <arma2> ggus: i think more focus has been encoding the bridge info in a qr code
16:01:29 <shelikhoo> I think for information theory reasons, it is not possible to remember it by memory...
16:01:35 <shelikhoo> for most people
16:01:48 <arma2> how many bits is the obfs4 cert? quite a few i suspect
16:02:00 <meskio> 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 <arma2> and, by 'check' do you mean be confident that you're right, even under attack? :)
16:03:35 <GeKo> 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 <ggus> 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 <meskio> GeKo: ack, I will check it
16:04:44 <shelikhoo> in this way, we can actually embed checksum into the bridge line
16:04:52 <shelikhoo> instead of let user check it manually
16:05:03 <meskio> ggus: aren't emoji's enough to check if they are right?
16:05:03 <dcf1> obfs4 cert is 256 + 160 bits. 256-bit curve25519 public key and 160-bit nodeid.
16:06:27 <arma2> 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 <ggus> meskio: emojis could help on that, but the problem is copying the actual line.
16:06:51 <arma2> kind of weird to do checksums as pictures, but, maybe it works better for non-numbers people :)
16:07:09 <ggus> and type some words vs a bridge certificate is way easier
16:07:28 <arma2> ggus: i think the problem here is that it would be like 30 words, not 4
16:07:29 <meskio> I see, what you want is something that is easier to manually type if you can't copy paste
16:07:36 <meskio> qr codes?
16:08:23 <ggus> actually, i'd prefer to submit these formats (qrcodes vs words vs other thing) to user research
16:08:37 <meskio> 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 <meskio> ggus: great, let's open a ticket about it and we can produce examples of each of the options
16:09:27 <ggus> ack!
16:09:35 <meskio> will you open the issue?
16:09:41 <meskio> I'll help producing the examples
16:09:44 <ggus> yes, i'm opening now
16:09:49 <meskio> thanks
16:09:59 <ggus> nah: donuts: maybe this could be part of s30 ur? ^
16:10:17 <meskio> anything else on this topic?
16:10:27 <arma2> ggus: also, knowing what sort of platforms these users are on (android vs windows) will change the question a lot
16:10:38 <nah> ggus: if it comes in time for testing in march/april, for sure!
16:10:38 <meskio> yep
16:10:50 <meskio> but I've seeing tails scanning qr-codes from a laptop...
16:10:59 <donuts> well, we have quite a lot queued up for S30 already – so I'm not so sure
16:11:01 <meskio> I mean using the laptop to scan the qr-code
16:11:02 <donuts> we're currently working on a new circuit display
16:11:10 <arma2> meskio: fun!
16:11:14 <donuts> but we can definitely do UR for it _somewhere_
16:11:37 <meskio> :)
16:11:48 <nah> ;)
16:11:49 <donuts> i am also super excited about this idea :D
16:12:24 <donuts> maybe we could just do some light paper prototyping/figma-feedback initially
16:12:40 <dcf1> 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 <arma2> dcf1: hm!
16:13:00 <dcf1> like stretch 80 bits into 416 bits, or whatever is a comfortable security and usability threshold
16:13:14 <arma2> good outside-the-box thinking
16:13:20 <meskio> ohh, interesting idea
16:13:33 <donuts> <+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 <shelikhoo> yes, this is something we could do!
16:14:25 <shelikhoo> I think the issue here is that we can only generate private key deterministicly
16:14:48 <dcf1> shelikhoo: good point, I didn't think of that
16:15:26 <arma2> right, you would need to get involved at the "creation of the bridge" step, not after
16:15:46 <arma2> heck, by that reasoning maybe we can just shorten the cert
16:16:22 <arma2> will be good to have a ticket for organizing all of these partially-baked ideas
16:16:47 <arma2> (another partially-baked idea is that you don't *really* need the bridge fingerprint, if you trust-on-first-connection it)
16:16:59 <shelikhoo> 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 <shelikhoo> so the security part of things changes
16:17:53 <arma2> 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 <arma2> anyway, ticket :)
16:19:06 <meskio> great, let's discuss it in the issue that ggus is opening
16:19:14 <meskio> and maybe we can move to the next topic
16:19:31 <meskio> "snowflake fallback"
16:19:45 <arma2> i made a branch that implements the 'only talk to first n bridges' idea
16:19:58 <meskio> nice
16:20:01 <arma2> 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 <arma2> i can't predict whether the network team will say 'ok great' or 'wtf why would we change this'
16:20:35 <arma2> but it is reasonable to imagine it could go into 0.4.8.1-alpha, whenever that comes out
16:21:01 <arma2> 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 <arma2> the one big catch is: you can't have multiple bridge lines with the same fingerprint,
16:21:28 <arma2> so if we go this route we'd want to deploy new bridges on the snowflake servers
16:21:57 <arma2> i.e. one bridge for snowflake01+domainfronting, and a different bridge for snowflake01+ampcache
16:22:00 <ahf> 0.4.8 is not so far into the future if conflux goes in - some point in q2 i think
16:22:00 <meskio> the change in c-tor is still useful for future snowflake with more than two bridges
16:22:41 <meskio> AFAIK we have three options here for the fallback:
16:22:57 <meskio> * multiple bridge lines as arma2 just mentioned
16:23:23 <meskio> * no fallback, just different definitions in TB for snowflake-domain-front and snowflake-ampcache
16:23:40 <meskio> * do a fallback on the snowflake client somehow, like we proposed with the binary args
16:24:09 <arma2> tell us more about #2? what do you mean different definitions
16:24:33 <dcf1> like there used to be meek-google, meek-amazon visible in the settings UI
16:24:45 <arma2> oh, ah ha, let the user click one or click the other. ok.
16:24:48 <dcf1> 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 <arma2> 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 <meskio> yes
16:25:34 <meskio> it looks like we have more agency with 3...
16:25:45 <meskio> agency => we don't push work to others
16:26:13 <dcf1> 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 <dcf1> We started this conversation when ampcache was merged, noting that our rendezvous configuration mechanism is a little jank
16:27:27 <dcf1> 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 <dcf1> 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 <arma2> option 1 lets you do 'more than one at a time' but isn't good at 'priority'
16:28:54 <dcf1> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/50#discussion
16:28:59 <arma2> i think if we want genuine fallback, i.e. try this then try that, we want option 3
16:29:06 <dcf1> "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 <arma2> 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 <dcf1> This is where PT 2.0-style JSON configuration would be nice.
16:30:17 <meskio> 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 <dcf1> "rendezvous": [{"type": "domainfront", ...}, {"type": "ampcache", ...}, {"type": "dns", ...}]
16:31:18 <meskio> yes, json format would be nice, but again making more complicated to copy bridgelines...
16:31:26 <ggus> https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/117
16:31:33 <meskio> thanks
16:31:36 <arma2> 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 <shelikhoo> a lot of users might have difficulty matching the brackets in the config file..
16:32:15 <shelikhoo> based on my experience with json config... hahaha
16:32:34 <arma2> 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 <arma2> or, better yet, make it so users never have to see or paste the bridge line
16:33:50 <meskio> with snowflake there is the bridge configuration and global configuration (like signaling channel), but we put both in the bridgeline
16:34:15 <arma2> 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 <shelikhoo> 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 <meskio> 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 <meskio> not sure if shelikhoo or itchyonion have cicles for it in the near future
16:37:42 <shelikhoo> actually this is two separate problem happening at the same time, if we go with 3.
16:38:09 <arma2> right. 3a snowflake learns how to fall back, 3b bridge lines can include more info?
16:38:40 <arma2> or maybe "3b find a way to tell snowflake more parameters"
16:38:43 <shelikhoo> shelikhoo could start work on it in 2~3 weeks time, if we can decide on plan by then
16:39:19 <arma2> 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 <arma2> and then short-term, if next week we need to give snowflake+amp to iran, what is our best available hack
16:40:35 <shelikhoo> in short term, we could give user in iran a custom bridge line
16:40:45 <meskio> 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 <meskio> maybe we can move to the next topic and continue this conversation in the issue
16:42:45 <meskio> ampcache for snowflake in IR
16:43:02 <meskio> it looks like they have remove the block after 9 days
16:43:12 <meskio> anything on this topic?
16:43:50 <meskio> let's move then to 'packet loss with snowflake in china'
16:43:52 <meskio> shelikhoo: ???
16:44:14 <shelikhoo> The packet loss between snowflake client and matched proxy is too high
16:44:30 <shelikhoo> when testing from vantage point in china
16:45:01 <shelikhoo> this have result in snowflake failed to get to enough speed to get tor bootstrap
16:45:03 <dcf1> is it a recent change?
16:45:43 <dcf1> there were favorable reports of snowflake usage in China at a recent (earlier this week) meeting organized by OTF localization lab
16:45:53 <dcf1> there were reports of slwoness, but not so much of unreliability
16:47:31 <shelikhoo> I don't think this is something sudden, over the last one year the bootstrap percentage drops gradually
16:47:54 <dcf1> ok
16:48:16 <shelikhoo> we only wait for 60 seconds for snowflake-tor to bootstrap
16:48:20 <shelikhoo> before ending the test
16:48:34 <shelikhoo> we could change this to a higher value
16:48:47 <shelikhoo> to give it more chance to finish bootstrap
16:49:00 <arma2> if we are keeping track of time-until-bootstrap, giving it a longer timeout will give us more useful data
16:49:11 <arma2> we can still compute "how many would have finished by 60s" from the better data
16:49:23 <shelikhoo> yes, I intent to increase it to about 300 seconds
16:49:32 <shelikhoo> yes, I intend to increase it to about 300 seconds
16:49:45 <cohosh> this is just from the one vantage point we have right? not from user reports?
16:49:56 <arma2> 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 <shelikhoo> this is just from vantage point
16:50:05 <cohosh> it's possible that vantage is unreliable
16:50:20 <arma2> so if there is a way to annotate the data with "learned a snowflake here" that could be really useful
16:51:20 <shelikhoo> 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 <arma2> 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 <shelikhoo> let's say there is a lot of snowflake connection with 20% packet loss
16:53:31 <arma2> how does pion webrtc handle 20% packet loss? how does browser webrtc handle it?
16:53:33 <shelikhoo> 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 <shelikhoo> we use kcp to handle this part
16:54:17 <shelikhoo> we asked pion webrtc to not deal with packet loss and let kcp to deal with it
16:54:47 <cohosh> 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 <shelikhoo> I think we can have a design first, because right now, this is not an easy task for us
16:55:53 <shelikhoo> forward error correction is cpu consuming, and we are running packet reassemble at a single server
16:56:12 <shelikhoo> so i doubt there can be a simple solution to deal with this
16:56:29 <shelikhoo> forward error correction is cpu consuming, and we are running packet reassemble at a single server(or two)
16:57:02 <shelikhoo> cohosh: we can have a plan first before reassign the tickets...
16:57:09 <shelikhoo> over
16:57:18 <meskio> 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 <shelikhoo> 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 <shelikhoo> giving the limitations
16:59:27 <meskio> sounds good
16:59:46 <meskio> maybe we can move to the next topic?
16:59:50 <shelikhoo> yes
17:00:14 <meskio> conjure in nightly versions
17:00:17 <cohosh> my item can wait until next week
17:00:17 <meskio> cohosh: ???
17:00:22 <cohosh> since the meeting is running late
17:00:24 <meskio> ok
17:00:26 <meskio> sure
17:00:47 <meskio> the last point is from ahf asking about things needed reveiw for s28
17:00:55 <meskio> arma2: can you check with him about it?
17:01:00 <meskio> maybe the answer is none?
17:01:06 <ahf> i think arma2 and i can just sync about this next week
17:01:14 <meskio> cool
17:01:20 <ahf> 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 <meskio> we don't have any high priority for c-tor, but there are few things that will be nice to get :)
17:02:26 <meskio> then I guess we can finish the meeting here
17:02:29 <meskio> #endmeeting