16:00:19 <cohosh> #startmeeting tor anti-censorship meeting
16:00:19 <MeetBot> Meeting started Thu Oct  8 16:00:19 2026 UTC.  The chair is cohosh. Information about MeetBot at https://wiki.debian.org/MeetBot.
16:00:19 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:24 <cohosh> welcome
16:00:26 <jah> hi
16:00:43 <cohosh> here is our meeting pad: https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469
16:01:25 <jah> can I please get the link to add content to the pad?
16:01:46 <cohosh> jah: yes i'll send it to you in a private message
16:01:50 <jah> ty cohosh
16:02:32 <cohosh> i'll give another min for people to add to the agenda
16:03:40 <cohosh> okay our first announcement is that there will be no meeting next week (october 15th)
16:03:55 <cohosh> a lot of people will be away at an in person meeting
16:04:35 <cohosh> for discussion, we have first an upcoming snowflake broker deployment
16:04:52 <cohosh> but i think a lot of the snowflake devs are missing from this meeting, so it might be better to discuss this another time
16:05:20 <cohosh> next up we have security audit items to be made public
16:06:01 <cohosh> i made a few of them visible yesterday, i'm not 100% about the one linked but i can follow up with shell on whether it should be made public today
16:06:48 <cohosh> we have some others that are still private until they are deployed and rolled out to users
16:07:14 <jah> (the link point to a "work item not found" - but maybe it is because it is not public)
16:07:35 <cohosh> jah: yes that's right, once it's visible, the link will work :)
16:08:01 <cohosh> next up we have protocol distributions for upgen/proteus
16:08:13 <cohosh> jah: is this your discussion item?
16:08:37 <jah> yes cohosh
16:08:50 <jah> I guess we would need robgjansen[mds] I wasn't sure if they would join this meeting
16:10:19 <cohosh> okay yeah it seems like a small meeting today
16:10:31 <jah> at least your are not alone ;p
16:10:45 <cohosh> we can wait a few minutes to see if anyone else shows up but this might have to wait until the next meeting (oct 22)
16:11:01 <cohosh> jah: hehe yes ty for joining
16:11:14 <jah> okay let's wait and see, thank you cohosh
16:11:47 <cohosh> fwiw i did recommend the signalling channel as a way to update proteus protocol files
16:11:58 <cohosh> so i can share my reasons for doing so
16:12:13 <cohosh> this is in answer to the question: What are the risks/costs/advantages to use a signaling channel to distribute upgen/proteus protocols as opposed to rely purely on a seed?
16:12:40 <jah> yes I would love to hear them cohosh
16:14:05 <cohosh> if i understand the argument you posted here, you're saying that if you write a specification that is randomized in some way, this randomization does a lot of heavy lifting in keeping the protocol unblocked, and that if it is blocked, you can ship a new version with regular software updates
16:14:29 <cohosh> one of the challenges with relying on software updates is that these can be slow, and it's also possible for the update channel to get blocked
16:15:06 <cohosh> a signalling channel (if it's not blocked) allows users to exchange less information than a software update that could potentially unblock their PT and therefore their update channel
16:15:27 <cohosh> and more quickly
16:15:59 <jah> cohosh: well I can see that, but that does not answer my original question. what is the point of potential restricting the search space of protocols?
16:16:19 <cohosh> ah that part of it i don't understand, how does it restrict the space of protocols?
16:16:24 <jah> anyway update have to go to the bridges as well, and until it is fully deployed client will have to use the old one
16:17:09 <jah> cohosh: well I guess I don't see any point in having a signaling channel if it does not restrict the search space of protocols in any way, beside the update point you just mentioned, what is the aim of having such signaling channel?
16:17:39 <jah> a way to rephrase my point: if you don't restrict the search space (or plan to potentially do it in future), what does a signaling channel give us?
16:17:56 <cohosh> my understanding is that the signalling channel would be used to distribute updates to the proteus PSF files
16:18:54 <jah> cohosh: would that affect only new bridges? or would that also affect bridges that already got a protocol?
16:18:58 <cohosh> what i imagine would happen is this: a bridge operator discovers that their bridge has been blocked. they generate a new PSF file, store it in a PSF file database that the client can then access over a signalling channel
16:19:02 <jah> (when a change happen I mean)
16:19:31 <jah> cohosh: ah okay, then I don't think it is a good idea
16:19:44 <jah> if a bridge get blocked it is safer to regenerate a complete identity in my opinion
16:19:53 <cohosh> i don't think there are any restrictions on what the PSF file can be in this case
16:19:54 <jah> I can motivate that argument better but I'll need time
16:20:07 <jah> I see, I understand your motivation now cohosh
16:20:07 <cohosh> by identity, you mean IP address?
16:20:18 <cohosh> you might have a point, this assumes that the bridge is blocked by protocol and not by IP
16:20:23 <jah> cohosh: no, I mean bridge line the bridge ID
16:20:30 <cohosh> i believe blocking by IP address is fairly common
16:21:06 <jah> if it get blocked, I think the bridge line should be considered
16:21:08 <jah> moot
16:21:17 <jah> not moot, sorry bad wording
16:21:20 <jah> but like deprecated
16:21:40 <jah> if a bridge get blocked you don't know how much the attacker know about that bridge
16:21:50 <jah> they might got the bridge line and can monitor it
16:22:23 <cohosh> jah: i think blocking by bridge fingerprint is analogous to IP-based blocking here
16:22:40 <cohosh> with the fingerprint, a censor can get the IP address, which is the mechanism they'd likely use to block it
16:22:56 <jah> cohosh: I'm pretty sure that is not true, and even it is true today you have no guarantee it will be true tomorrow
16:23:36 <jah> if you consider an ISP than know both who is running the bridge and have the bridge line, you can imagine some attacks
16:23:41 <jah> that know*
16:24:15 <jah> the ISP might know who is running the bridge not with an IP addresse, but something more low-level, like what subscriber this is
16:24:46 <jah> in the context of China it is not crazy to think that the attacker could be the ISP
16:25:00 <cohosh> you mean a censor coercing a bridge operator into taking their bridge offline?
16:25:25 <jah> cohosh: that's one case, an other case would be monitoring if someone is connecting to a specific bridge
16:25:44 <cohosh> in anycase, more on topic and to your point: there is blocking that is not protocol based blocking (like for example IP-based blocking) in which using a signalling channel to update the PSF would not solve the problem
16:26:22 <cohosh> so the question here is: is there enough protocol based blocking that could be circumvented by using a signalling channel to update PSF files to warrant the extra infrastructure
16:26:41 <jah> that is an interesting angle as well, for sure
16:26:55 <cohosh> but it's also a question of convenience of distributing the initial PSFs
16:27:04 <jah> cohosh: in this case changing the protocol, could put other users of the bridge at risk of being identified as Tor users
16:27:18 <cohosh> ideally we'll have multiple bridge operators, each with their own PSF
16:27:23 <jah> that is why we should not rotate protocol on a single bridge, I think both me and robgjansen[mds] agree on that
16:27:40 <jah> cohosh: yeah, each bridge should have a unique PSF, in my opinion
16:27:49 <jah> this is one the thing I was arguing with rob
16:27:57 <cohosh> and it would be slow and painful for our applications team to ship a new release for every new proteus bridge operator
16:28:16 <jah> no no, we can derive them randomly using a seed
16:28:26 <jah> by having a deterministic protocol generator
16:28:31 <jah> I did that in my prototype
16:28:49 <cohosh> okay, this is just a different model of PT than proteus then
16:29:10 <cohosh> this is restricting the set of available protocols to ones that can be randomly generated from a seed
16:29:17 <cohosh> whereas proteus is a lot more flexible
16:29:51 <jah> I don't think that's true
16:30:04 <jah> we can most likely cover all possible protocolos for proteus if we want
16:30:15 <jah> for a given version of proteus, that is
16:30:29 <jah> but anyway, that must be well specified (the search space of all protocols)
16:30:41 <jah> in other words: why not embedding the PSF in the bridge line?
16:31:12 <cohosh> the proteus PSFs at least can be much longer than the maximum bridge line length
16:31:38 <jah> not if we have a determinstic generator for PSFs that can build them using a short seed
16:33:46 <cohosh> i think i'll need to read up on your approach before commenting further
16:33:47 <jah> also: if the space of possible protocols is bigger with proteus than with what is done with upgen, what is the point of that? why those combination are not part of the upgen generation then?
16:34:14 <jah> cohosh: I'll try to write something digestable about it, so it can be used a reference for future discussions
16:34:32 <jah> now that I understand your main motivation it will be easier for me to describe it
16:34:55 <cohosh> jah: iiuc, upgen is a generator of PSFs, not a PT in and of itself
16:35:37 <jah> cohosh: that's right, but my last point still stand in that context
16:36:06 <jah> in other words: what are you trying to do besides supporting upgen protocols by doing a proteus PT?
16:36:11 <meskio> I belive the matrix bridge is failing, I was wondering why so much silence, and I see my messages didn't arrive (anyway they were not important)
16:36:28 <jah> oh that explains our loneliness
16:37:30 <cohosh> ah ok that explains the large amount of joins just now
16:37:58 <meskio> :D
16:38:07 <jah> I think it was not failing when we started though
16:38:15 <jah> ten minutes ago it crashed, apparently
16:38:37 <meskio> I could read you at the beggining
16:38:44 <meskio> but none of my messages has made it here
16:39:54 <cohosh> jah: are you advocating for running upgen at both the client and the bridge and sending a seed for it in the bridge line?
16:40:55 <jah> cohosh: that is what I was initially advocating, now I do question myself if I could advocate my seed-based approach even if you want to run full proteus on both sides.
16:40:55 <jah> I do question the meaning fo running full proteus vs upgen.
16:41:08 <cohosh> i think the reason upgen isn't distributed in that way is because the models are potentially large and the generation somewhat costly to run
16:41:30 <jah> cohosh: well the cost happen only once
16:41:33 <cohosh> i think it might also be difficult to coordinate updates to the model so that clients and bridges are using the same version
16:41:38 <jah> so it is very well ammortized
16:41:59 <jah> cohosh: rob did mention the version thing, I don't think it is a good argument if you design the generator properly and version it
16:42:07 <cohosh> jah: well we have to care about the size of the model: on mobile applications we have some pretty tight restrictions on how big the app downloads can be
16:42:56 <jah> cohosh: arguably if you remove the stuff that proteus have but upgen don't use, it's not that big
16:43:03 <jah> I believe (to be confirmed)
16:43:10 <jah> but we can prototype this, I could do it
16:43:15 <jah> to show what would be the size
16:43:44 <meskio> having all the information in the bridgeline as a seed will make things way easier, as no extra infraestructure will be needed
16:44:03 <jah> cohosh: any way I think it is not a good argument what you just said, because even without generator, you will need the complete model
16:44:19 <jah> so the generator code won't be significant in term of binary size, in my opinion
16:44:32 <jah> meskio: yes this also reduce risk of censorship
16:44:36 <jah> or corruption
16:44:37 <cohosh> jah: that's not true, you only need the PSF with the architecture as it's described in the upgen paper
16:45:17 <jah> cohosh: okay but the model of the PSF is pretty much the same size (even bigger) as the model used by upgen (I would have to prove that, for sure)
16:45:30 <cohosh> that is definitely not true
16:45:53 <jah> well, if you implement upgen without relying on proteus I think it can be true
16:46:07 <jah> but you did not motivate why having a proteus PT instead of just upgen
16:46:14 <jah> so I'm still wondering what is the point of that
16:46:32 <cohosh> i think that's the point of the proteus PSF design, that they are lightweight outputs of the generator that can be easily distributed
16:47:30 <jah> I see it as a testbed for protocol research, I did not interpret it that way but I'll digg more
16:47:54 <jah> anyway, again a seed is very easily distributed
16:48:43 <cohosh> ok, i understand the argument you're making, i think there are some claims that need to be validated, if the generator and model are small enough and easy to update in backward compatible way, then i can see how treating upgen as a PT would work
16:49:05 <jah> at the end, if we can find a way to distribute PSF embedded in the bridge line I think we would all be happy but I'm not sure how realistic that is. I wll study this first.
16:49:39 <jah> if I don't find any I will motivate my original point in a backward compatible manner.
16:49:45 <jah> cohosh: sounds good?
16:50:44 <cohosh> yeah, thanks for joining and discussing
16:51:34 <jah> thanks a lot to you for motivating the current design, that was super helpful
16:52:26 <cohosh> meskio: anything you'd like to add from earlier before we close the meeting?
16:52:27 <meskio> it was fun to read :)
16:52:35 <meskio> no, nothing important
16:52:43 <meskio> thank you for keeping it up
16:53:16 <cohosh> cool :) i'll end the meeting here then, thanks everyone!
16:53:25 <jah> thanks a lot cohosh! see ya meskio
16:53:31 <cohosh> #endmeeting