16:03:33 <shelikhoo> #startmeeting tor anti-censorship meeting
16:03:33 <shelikhoo> here is our meeting pad: https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469
16:03:33 <shelikhoo> editable link available on request
16:03:33 <MeetBot> Meeting started Thu May 29 16:03:33 2025 UTC.  The chair is shelikhoo. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:33 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:03:38 <shelikhoo> hi~ hi~
16:04:08 <meskio> ups, I'm around, but with a bad connection, thank you for running it
16:04:12 <meskio> hello
16:04:52 <shelikhoo> okay, we all get bad connections in turn...
16:06:00 <meskio> in exchange I have a nice sea view from my van :)
16:06:26 <shelikhoo> oh nice!!!
16:06:45 <cohosh> :)
16:07:15 <shelikhoo> I didn't see any messages about discussion topics
16:07:30 <shelikhoo> please send something if there is anything we would like to discuss in this meeting
16:07:32 <cohosh> i just looked at last week's meeting and i have a comment about happy families
16:08:21 <shelikhoo> cohosh, please go ahead about family
16:08:29 <cohosh> happy families does not solve the fundamental bridges + exits issue
16:09:57 <meskio> ohh, I thought it did
16:10:05 <dcf1> because bridges are a special case that are not handled the same as normal circuit selectioN?
16:10:06 <cohosh> there are two things going on: one is that families currently ask operators to disclose the fingerprints on their other relays, that is solved by happy families
16:10:09 <cohosh> https://gitlab.torproject.org/tpo/core/tor/-/blob/36cd4a50fc9d861c6c35a0f6dcb22f29cb39a53e/src/feature/relay/relay_config.c?page=2#L1169-1173
16:10:27 <cohosh> dcf1: yes, the second problem is how circuit selection works
16:10:53 <cohosh> that's described here: https://gitlab.torproject.org/tpo/core/tor/-/issues/40935#note_3090023
16:11:03 <cohosh> Tor picks exit relays first, and then picks a guard
16:11:36 <cohosh> with bridges like snowflake, conjure, and meek (where the first restriction doesn't event apply), the client is very restricted in which entry point it can select
16:12:11 <cohosh> we have one conjure bridge and effectively one meek bridge
16:12:47 <cohosh> even though we have more than one snowflake bridge, the tor source code currently ignores family restrictions for bridges
16:13:17 <cohosh> also for each of these bridges, the original concern that happy families is set to solve doesn't apply because we don't care about a censor learning the bridge's IP address or fingerprint
16:13:36 <cohosh> it only really applies to obfs4 or webtunnel
16:13:48 <dcf1> what are you referring to with "the first restriction"? you mean the restriction that bridges are not permitted to list MyFamily?
16:14:11 <cohosh> sorry that should have been the first concern doesn't even apply
16:14:23 <cohosh> (being the leakage of bridge fingerprints to a censor)
16:14:29 <dcf1> got it, thanks
16:15:28 <cohosh> there are arguments that family and same subnet restrictions don't really matter when it comes to practical attacks on anonymity
16:16:22 <cohosh> and conflux is also complicated things, where even with 2 snowflake bridges, is it better to make circuits through both of them for conflux vs excluding one because of family or subnet restrictions?
16:17:05 * cohosh slows down typing to make fewer mistakes ^_^`
16:17:21 <meskio> I see, I did missunderstood how nodes are selected
16:19:27 <cohosh> me too, until i looked at the code
16:20:05 <cohosh> i saw that original log message and thought we could just remove that for snowflake/meek/conjure
16:20:21 <cohosh> but it is much more complicated than that
16:20:51 <cohosh> here is a proposal for relaxed restrictions: https://spec.torproject.org/proposals/354-relaxed-restrictions.html
16:21:32 <cohosh> that has some more recent thinking on threat models
16:22:35 <cohosh> i'm a bit torn. i feel like having separate operators for large and high impact bridges is best, but if that's all we can find then it's better than nothing
16:24:22 <dcf1> I don't quite understand. Would proposal #354 mitigate the problems with circuit selection and bridges?
16:24:50 <cohosh> no, it is an argument for why families and subject restrictions shouldn't apply to circuits with bridges
16:25:59 <dcf1> is that thinking assuming the secret kind of bridges?
16:26:57 <cohosh> no
16:27:04 <cohosh> my summary is:
16:27:32 <cohosh> there is a tradeoff between guard discovery attacks and end-to-end traffic correlation attacks
16:29:50 <cohosh> and then some arguments about how families and same subnet restrictions don't do a lot to preferent e2e traffic correlation
16:30:01 <cohosh> and how these attacks aren't as practical as guard discovery attacks
16:30:37 <cohosh> this argument applies to the case where there are only a small number of bridges configured
16:32:07 <cohosh> and then there is a proposal for some adjustments to path selection
16:34:14 <cohosh> the proposal as i understand it would be an improvement to circuit building with bridges, but doesn't fully implement the family and subnet restrictions as they are currently understood for non-bridge circuits
16:35:45 <meskio> I wonder if we have any path forward to be able to let exit operators to also run bridges (I mean in general and not for specific needs that we don't have another option like snowflake)
16:38:17 <cohosh> i think the fundamental difference with bridges that makes the most impact is that users typically only configure 1-3 bridges
16:38:35 <cohosh> where typical is using snowflake/conjure/meek or using only the obfs4/webtunnel bridges they get from bridgedb
16:38:54 <cohosh> whereas directly connecting tor users can pick from a larger set of guards
16:41:28 <cohosh> i think the path selection changes in prop 354 make sense
16:42:47 <cohosh> other things we could do to help diversity are 1) hand out more bridges (there are enumeration tradeoffs here), 2) try to run and configure more bridges for snowflake/meek/conjure, 3) modify tor to not make a connection to every single bridge we configure as we ramp up the number of bridges we're giving users
16:44:05 <meskio> many of our distributors hand different set of bridge each day, for things like webtunnel bridges we might not have enough bridges to hand out 3 some days, but we could aim for it
16:44:24 <meskio> but yes, enumeration is a problem
16:44:29 <cohosh> i don't have a good sense for how important or worth it that tradeoff is
16:45:01 <meskio> I have the feeling that is more important enumeration, but that might be because I'm in the anti-censorship bubble more than in the privacy one
16:45:37 <meskio> but anyway we get very much enumerated with our currently distribution methods...
16:45:57 <cohosh> yeah
16:46:29 <shelikhoo> yeah.. telling the difference between real user and someone pretend to be a user is quite hard
16:46:39 <cohosh> it's also a good point that people who self-declare families only protects against e2e attacks by operators honest enough to report that
16:46:55 <meskio> maybe this is a topic we should bring with the network team on the next tor-meeting, or whatever in person event
16:47:31 <cohosh> sure
16:47:44 <shelikhoo> yeah, I think it will be maybe 1 year away?
16:48:04 <meskio> yes, but doesn't look like there is any urgency to solve it before
16:48:54 <shelikhoo> yes, that's true
16:49:28 <shelikhoo> anything more we would like to discuss in this meeting?
16:49:32 <cohosh> yeah i mostly wanted to clear up some misunderstandings of how happy families impacts bridges
16:49:45 <meskio> thank you for the clarifications
16:50:07 <meskio> I don't have anything more for this meeting
16:50:52 <shelikhoo> #endmeeting