15:59:43 <meskio> #startmeeting tor anti-censorship meeting
15:59:43 <MeetBot> Meeting started Thu Mar 10 15:59:43 2022 UTC.  The chair is meskio. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:59:43 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:59:47 <meskio> hello!!!
15:59:51 <meskio> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
15:59:56 <cohosh> hi!
15:59:57 <meskio> feel free to add what you've been working on and put items on the agenda
16:00:16 <shelikhoo> hi~
16:01:21 <meskio> I see we have an evolution of our regular point on snowflake bridges: 'Reach an agreement on distributed Snowflake'
16:01:55 <meskio> did we already reach an agreement last week?
16:02:02 <meskio> is there details we still need to discuss?
16:02:14 <meskio> or we just need to figure out who will do the work?
16:02:50 <dcf1> there are a lot of specific design details to iron out, however they seem to break into separable chunks
16:03:16 <dcf1> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/81 is the client telling the broker what bridge it wants to use
16:03:26 <dcf1> we also need:
16:03:44 <dcf1> * broker having a list of known bridge fingerprints
16:04:04 <dcf1> * proxies telling the broker what bridges they know about in their poll messages
16:04:30 <dcf1> * broker matching clients with proxies, considering not only NAT compatibility but bridge fingerprint awareness
16:04:47 <dcf1> * proxies forwarding bridge fingerprint to snowflake-server intheir websocket connection
16:05:02 <dcf1> * snowflake-server having its own internal mapping of bridge fingerprint -> ExtORPort address
16:05:35 <dcf1> all of these need some consideration and design about how to do them, potentially new versions of protocol messages
16:06:02 <dcf1> for instance, I was thinking a good next step is "* proxies telling the broker what bridges they know about in their poll messages"
16:06:28 <arlolra> I was going to pick that up
16:06:28 <dcf1> For that, we need to add a JSON list or something to the poll message, "known_fingerprints: ["AAAA...", "BBBB...", ...]".
16:06:38 <cohosh> unless we want to go the "exclude proxies that don't know about the current good set" route
16:07:07 <cohosh> it would simplify the logic at the broker but potentially affect our proxy pool
16:07:19 <dcf1> When matching a client with a bridge fingerprint *different than* the current primary one, the broker will have to match up with a bridge that is new enough to know to send that list of bridge fingerprints.
16:07:52 <shelikhoo> It is possible to just let broker instruct the proxy which websocket url it should connect to
16:08:13 <shelikhoo> in this way the proxy won't need to keep a list of known fingerprints
16:08:27 <dcf1> Right, one way to effect the matching is just to exclude all proxies that don't know about all the current bridges, any proxy that remains after that filtering is guaranteed to work
16:08:50 <dcf1> shelikhoo: I think that is possible, but it has some downsides:
16:09:33 <dcf1> * you still need a signal that that proxy (1) knows how to interpret the broker's instructions about which URL to connect to, and (2) knows how to forward the bridge fingerprint to snowflake-server
16:09:59 <dcf1> * you need to put a "*" in the WebExtension permission manifest, instead of a tightly controlled allowlist
16:10:53 <dcf1> Either way, you need to change the proxies both to gain these features, and to signal their support of these features to the broker (via a higher protocol version number or something)
16:11:19 <shelikhoo> Yes, the proxy can just signal its version to get everything working
16:11:43 <shelikhoo> the fingerprint can be included in the websocket url
16:11:58 <meskio> might be easier to update the broker with new bridges than all the proxies, extensions are easy to update (I expect browsers will do without asking) but standalone ones might be harder (but we might not care so much...)
16:12:28 <shelikhoo> the only issue is that the webextension will need to have relaxed permission
16:12:30 <dcf1> I don't mean to work through all the details now, I'm just saying that there are such details that need to be worked through
16:12:57 <shelikhoo> If there is a allowlist on the proxy, this state have to be updated somehow
16:13:10 <shelikhoo> and this will create another set of issues
16:13:51 <shelikhoo> while making it impossible to allow community to run their own snowflake-server+tor
16:14:40 <cohosh> dcf1: true, i see now how in either case the proxy would still share its list with the broker and that is a good next step
16:15:37 <shelikhoo> cohosh: If the broker just inform the proxy which websocket url it need to connect, there will be no proxy's version of list
16:15:47 <keroserene> hi folks
16:15:53 <shelikhoo> it just inform broker its version
16:15:57 <dcf1> hey serene
16:16:10 <shelikhoo> and let broker decide where to connect
16:16:10 <cohosh> shelikhoo: ah true
16:16:34 <shelikhoo> Hi~ keroserene ~
16:16:37 <cohosh> iirc we were also concerned about the ability of a malicious broker to use the proxy pool to open arbitrary websocket connections
16:17:03 <cohosh> keroserene: hey!
16:17:11 <dcf1> yes in that case the signal, instead of being "known_fingerprints: ["AAAA...", "BBBB...", ...]", can be "i_know_about_bridge_fingerprints: true"
16:17:32 <shelikhoo> Oh, that is also an issue.... We need to get broker filter this url list, not proxy
16:17:52 <arlolra> the proxies also need to be able to reach the snowflake-server and that may limit which client it is appropriate to handle
16:17:56 <dcf1> correct, having a list of known servers at each proxies lets each proxy protect itself against a malicious or compromised broker, and is a hedge against other kinds of abuse
16:18:31 <cohosh> arlolra: good point, if the proxies know their own server lists then they can do the probe test /before/ polling instead of finding out afterwards
16:18:50 <cohosh> probe test = bridge reachability test here
16:18:53 <arlolra> that's the model now, to a degree
16:18:54 <shelikhoo> dcf1: Yes, if the broker is untrusted, having a list on the proxy will be better
16:20:08 <arlolra> the broker can still hand out fake clients to connect to, so the maliscious broker isn't really helped
16:20:09 <dcf1> so there are a lot of considerations and tradeoffs, but we can take them one step at a time
16:20:40 <arlolra> keroserene: hello
16:21:09 <keroserene> hi team snowflake :)
16:21:16 <keroserene> this may be a silly question but, do we have any autoupdate mechanism (beyond what comes with extensions) and should this be a thing?
16:23:19 <shelikhoo> I don't think we have anything specific to snowflake proxy
16:23:36 <shelikhoo> things like docker support auto update if enabled
16:24:04 <shelikhoo> but there is no built-in update or even an notification for that
16:24:33 <arlolra> there's a deb of something now
16:25:34 <arlolra> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40105
16:25:40 <arlolra> the proxy
16:25:42 <gaba> wrt to distributed snowflake design, what are the next step and who is responsible of working on it?
16:25:59 <meskio> the .deb is blocked in debian sid, is in my TODO to fix it to get it into backports
16:27:48 <dcf1> last time we talked about scaling in two directions: more snowflake-servers and more bridge fingerprints per snowflake-server
16:28:16 <dcf1> currently I think we are working towards the intermediate step of "more than one snowflake-server, but still only one bridge fingerprint per snowflake-server"
16:28:36 <dcf1> by that logic, the "snowflake-server having its own internal mapping of bridge fingerprint -> ExtORPort address" is the lowest priority, because nothing else depends on it
16:29:30 <dcf1> the next steps that I see are: proxies announcing their supported bridge list / signaling awareness of multiple bridges, and matching logic in the broker
16:30:14 <keroserene> should these mutable bridge lists be pinned to package version, or updated and shared via a somewhat independent protocol which exists after some minimum version
16:30:59 <meskio> what is the advantage of running multiple bridges with one snowflake-server? will not make our life easier to assume that is a 1-to-1 map? will we actually gain much by having a single snowflake-server instead of multiple?
16:31:27 <arlolra> keroserene: see https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/81
16:31:43 <meskio> (maybe not a discussion for now, but I agree we don't need to prioritize it now)
16:33:21 <dcf1> meskio: the advantage is that we can then potentially ask multiple different groups to run bridges, they don't all need to be directly controlled by the snowflake-server operator
16:33:38 <dcf1> (see hackerncoder's question on the tor-project thread)
16:33:48 <meskio> mmm, I see
16:34:12 <dcf1> that's why I say it can be a later priority, it's not as essential as the other things
16:34:25 <dcf1> https://forum.torproject.net/t/tor-project-more-resources-required-for-snowflake-bridge/2353/2
16:34:36 <meskio> +1
16:34:59 <shelikhoo> Yes, but I think it would be possible to just let different group run snowflake-server + tor. so that we can just focus on match making....
16:35:38 <dcf1> shelikhoo: yes, the bridges will still need to be known to the broker, but snowflake-server + tor can be operated independently
16:36:14 <dcf1> multiple bridge fingerprints per snowflake-broker would allow decoupling further: decoupling snowflake-server operator from tor operator
16:37:27 <hackerncoder> (the forum is doing its "stuff" again, I never wrote anything like that)
16:37:54 <shelikhoo> so the next decision we need to make is whether proxy should have an allow-list of fingerprint, and how should that list be distributed
16:39:15 <meskio> we just mentioned the pros and cons here for it, but not sure how we reach a decision on that
16:39:30 <dcf1> hackerncoder: oh really! I had no idea there was anything weird about the forum. Sorry for misattribution.
16:39:34 <meskio> I'm happy either way
16:40:51 <dcf1> I have been reaching out in various directions for resources for snowflake bridge hosting, and I have some solid leads for multiple bridge sites when we're ready for that
16:41:33 <meskio> good
16:41:39 <dcf1> as well as a stronger host for the current singular bridge until then
16:42:00 <cohosh> nice :D
16:42:05 <gaba> great. It seems clear what to do :). Who is going to be working on this?
16:42:30 <gaba> shelikhoo: is that you leading the technical changes to make multiple bridges possible?
16:43:42 <shelikhoo> gaba: arlolra made the last commit related to this but I can take over. I think we still need to make some additional decision before the work can begin.
16:44:03 <shelikhoo> so the next decision we need to make is whether proxy should have an allow-list of fingerprint, and how should that list be distributed
16:44:44 <dcf1> I somewhat disagree, there are many parts of this, and work can begin on some without others
16:44:53 <gaba> shelikhoo: it would be good for you to bottomline this regardless of who is contributing code.
16:45:02 <dcf1> for example the current !81 is independent of how proxies signal their bridge fingerprint support
16:45:54 <shelikhoo> Yes... But the next change we need to make is on the broker+proxy
16:45:59 <dcf1> The broker matching changes can begin, by assuming bridge fingerprint 2B280B23E1107BB62ABFC40DDCC8824814F80A72 for all clients and proxies
16:46:24 <shelikhoo> Yes....
16:46:49 <dcf1> My real point is: I think these things can be worked out while implementing the changes, it doesn't necessarily have to be a big design up front
16:47:32 <shelikhoo> Yes. But I think the direction(whether proxy should have an allow-list of fingerprint, and how should that list be distributed) will be needed here
16:47:37 <dcf1> okay
16:48:07 <keroserene> yes. (also thanks arlolra, saw that). my intuition is that the allow-list distributions should be independent of actual version updates, eventually. how we get there is non-trivial, but meanwhile getting the actual bandwidth up can be done naively
16:48:40 <gaba> im a little lost on what is the disagreement here. I agree that it would be good to start working on a design although maybe not all details are worked out
16:49:54 <shelikhoo> Yes, so right now, we think there will be a allow-list on the proxy of allowed bridge fingerprint, and their websocket url
16:51:14 <shelikhoo> and this allowlist is update either together with proxy's code or another separate file download over internet?
16:51:42 <shelikhoo> and this allowlist is updated with either together with proxy's code or another separate file download over internet?
16:52:56 <shelikhoo> do we wants to have any amendment of this model?
16:53:29 <meskio> I'm wonder if this is something we need to postpone to next week, or if we can dicuss it in an issue or somewhere
16:53:44 <gaba> or maybe dicuss it in a different space tat is not only text
16:53:48 <meskio> (there was reading group planned for today and is being 54mins of meeting...)
16:55:18 <gaba> dcf1, shelikhoo, other: would you be ok if we jump into a bbb tomorrow or the beginning of next week to finish this discussion and reach to an agreement here?
16:55:22 <gaba> i can coordiante with you all
16:57:29 <shelikhoo> I have no objection.
16:57:34 <n0toose> Hello.
16:57:40 <dcf1> no, I don't think I can do a live meeting tomorrow
16:57:50 <dcf1> I trust shelikhoo to make good decisions
16:58:00 <gaba> ok
16:58:12 <n0toose> Sorry, did I get the time wrong/am I late/did I miss something?
16:58:12 <shelikhoo> Okay.
16:58:13 <gaba> so let's have shelikhoo move on and take decisions
16:58:28 <gaba> dcf1 and you all can look at the code later when reviewing
16:58:57 <cohosh> n0toose: the meeting starts at 16 utc, so an hour ago :) we're just discussing some snowflake design decisions
16:59:22 <n0toose> I thought it was at 17 UTC, not sure how I could've possibly gotten it wrong, apologies.
17:00:01 <shelikhoo> Yes. dcf1. I think we already have the general directions to work on if there is no objection to the model I have just summarized.
17:00:05 <meskio> n0toose: don't worry, you just misseed a long discussion about snowflake
17:00:27 <n0toose> Well, not really that well versed in the topic anyways. I am now here regarding the Telegram bot if needed.
17:00:51 <shelikhoo> I will post summary on the ticket, and if there is amendment purposed, we will move on to get it done
17:01:02 <shelikhoo> and I will track this issue
17:01:03 <cohosh> shelikhoo: +1 i like the allowlist model right now as well :)
17:01:32 <meskio> n0toose: great, people might want to close the meeting soon, but we can talk about the telegram bot next week or ourside the meeting
17:02:00 <meskio> is being 1h of meeting, should we postpone the reading group for next week? or people want to stay over the time?
17:03:54 <shelikhoo> cohosh: does "right now" means you originally like the trusted broker model?
17:04:31 <cohosh> shelikhoo: oh no i worded it badly i mean that i think it's the good next step
17:05:04 <shelikhoo> cohosh: Yes
17:08:17 <shelikhoo> maybe we can just postpone the reading group if that works for everyone
17:09:32 <meskio> +1
17:10:00 <meskio> anything else then for today?
17:10:41 <meskio> I'll close the meeting here
17:11:03 <meskio> #endmeeting