15:59:43 #startmeeting tor anti-censorship meeting 15:59:43 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:59:47 hello!!! 15:59:51 here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 15:59:56 hi! 15:59:57 feel free to add what you've been working on and put items on the agenda 16:00:16 hi~ 16:01:21 I see we have an evolution of our regular point on snowflake bridges: 'Reach an agreement on distributed Snowflake' 16:01:55 did we already reach an agreement last week? 16:02:02 is there details we still need to discuss? 16:02:14 or we just need to figure out who will do the work? 16:02:50 there are a lot of specific design details to iron out, however they seem to break into separable chunks 16:03:16 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 we also need: 16:03:44 * broker having a list of known bridge fingerprints 16:04:04 * proxies telling the broker what bridges they know about in their poll messages 16:04:30 * broker matching clients with proxies, considering not only NAT compatibility but bridge fingerprint awareness 16:04:47 * proxies forwarding bridge fingerprint to snowflake-server intheir websocket connection 16:05:02 * snowflake-server having its own internal mapping of bridge fingerprint -> ExtORPort address 16:05:35 all of these need some consideration and design about how to do them, potentially new versions of protocol messages 16:06:02 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 I was going to pick that up 16:06:28 For that, we need to add a JSON list or something to the poll message, "known_fingerprints: ["AAAA...", "BBBB...", ...]". 16:06:38 unless we want to go the "exclude proxies that don't know about the current good set" route 16:07:07 it would simplify the logic at the broker but potentially affect our proxy pool 16:07:19 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 It is possible to just let broker instruct the proxy which websocket url it should connect to 16:08:13 in this way the proxy won't need to keep a list of known fingerprints 16:08:27 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 shelikhoo: I think that is possible, but it has some downsides: 16:09:33 * 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 * you need to put a "*" in the WebExtension permission manifest, instead of a tightly controlled allowlist 16:10:53 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 Yes, the proxy can just signal its version to get everything working 16:11:43 the fingerprint can be included in the websocket url 16:11:58 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 the only issue is that the webextension will need to have relaxed permission 16:12:30 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 If there is a allowlist on the proxy, this state have to be updated somehow 16:13:10 and this will create another set of issues 16:13:51 while making it impossible to allow community to run their own snowflake-server+tor 16:14:40 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 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 hi folks 16:15:53 it just inform broker its version 16:15:57 hey serene 16:16:10 and let broker decide where to connect 16:16:10 shelikhoo: ah true 16:16:34 Hi~ keroserene ~ 16:16:37 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 keroserene: hey! 16:17:11 yes in that case the signal, instead of being "known_fingerprints: ["AAAA...", "BBBB...", ...]", can be "i_know_about_bridge_fingerprints: true" 16:17:32 Oh, that is also an issue.... We need to get broker filter this url list, not proxy 16:17:52 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 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 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 probe test = bridge reachability test here 16:18:53 that's the model now, to a degree 16:18:54 dcf1: Yes, if the broker is untrusted, having a list on the proxy will be better 16:20:08 the broker can still hand out fake clients to connect to, so the maliscious broker isn't really helped 16:20:09 so there are a lot of considerations and tradeoffs, but we can take them one step at a time 16:20:40 keroserene: hello 16:21:09 hi team snowflake :) 16:21:16 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 I don't think we have anything specific to snowflake proxy 16:23:36 things like docker support auto update if enabled 16:24:04 but there is no built-in update or even an notification for that 16:24:33 there's a deb of something now 16:25:34 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40105 16:25:40 the proxy 16:25:42 wrt to distributed snowflake design, what are the next step and who is responsible of working on it? 16:25:59 the .deb is blocked in debian sid, is in my TODO to fix it to get it into backports 16:27:48 last time we talked about scaling in two directions: more snowflake-servers and more bridge fingerprints per snowflake-server 16:28:16 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 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 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 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 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 keroserene: see https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/81 16:31:43 (maybe not a discussion for now, but I agree we don't need to prioritize it now) 16:33:21 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 (see hackerncoder's question on the tor-project thread) 16:33:48 mmm, I see 16:34:12 that's why I say it can be a later priority, it's not as essential as the other things 16:34:25 https://forum.torproject.net/t/tor-project-more-resources-required-for-snowflake-bridge/2353/2 16:34:36 +1 16:34:59 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 shelikhoo: yes, the bridges will still need to be known to the broker, but snowflake-server + tor can be operated independently 16:36:14 multiple bridge fingerprints per snowflake-broker would allow decoupling further: decoupling snowflake-server operator from tor operator 16:37:27 (the forum is doing its "stuff" again, I never wrote anything like that) 16:37:54 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 we just mentioned the pros and cons here for it, but not sure how we reach a decision on that 16:39:30 hackerncoder: oh really! I had no idea there was anything weird about the forum. Sorry for misattribution. 16:39:34 I'm happy either way 16:40:51 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 good 16:41:39 as well as a stronger host for the current singular bridge until then 16:42:00 nice :D 16:42:05 great. It seems clear what to do :). Who is going to be working on this? 16:42:30 shelikhoo: is that you leading the technical changes to make multiple bridges possible? 16:43:42 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 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 I somewhat disagree, there are many parts of this, and work can begin on some without others 16:44:53 shelikhoo: it would be good for you to bottomline this regardless of who is contributing code. 16:45:02 for example the current !81 is independent of how proxies signal their bridge fingerprint support 16:45:54 Yes... But the next change we need to make is on the broker+proxy 16:45:59 The broker matching changes can begin, by assuming bridge fingerprint 2B280B23E1107BB62ABFC40DDCC8824814F80A72 for all clients and proxies 16:46:24 Yes.... 16:46:49 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 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 okay 16:48:07 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 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 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 and this allowlist is update either together with proxy's code or another separate file download over internet? 16:51:42 and this allowlist is updated with either together with proxy's code or another separate file download over internet? 16:52:56 do we wants to have any amendment of this model? 16:53:29 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 or maybe dicuss it in a different space tat is not only text 16:53:48 (there was reading group planned for today and is being 54mins of meeting...) 16:55:18 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 i can coordiante with you all 16:57:29 I have no objection. 16:57:34 Hello. 16:57:40 no, I don't think I can do a live meeting tomorrow 16:57:50 I trust shelikhoo to make good decisions 16:58:00 ok 16:58:12 Sorry, did I get the time wrong/am I late/did I miss something? 16:58:12 Okay. 16:58:13 so let's have shelikhoo move on and take decisions 16:58:28 dcf1 and you all can look at the code later when reviewing 16:58:57 n0toose: the meeting starts at 16 utc, so an hour ago :) we're just discussing some snowflake design decisions 16:59:22 I thought it was at 17 UTC, not sure how I could've possibly gotten it wrong, apologies. 17:00:01 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 n0toose: don't worry, you just misseed a long discussion about snowflake 17:00:27 Well, not really that well versed in the topic anyways. I am now here regarding the Telegram bot if needed. 17:00:51 I will post summary on the ticket, and if there is amendment purposed, we will move on to get it done 17:01:02 and I will track this issue 17:01:03 shelikhoo: +1 i like the allowlist model right now as well :) 17:01:32 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 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 cohosh: does "right now" means you originally like the trusted broker model? 17:04:31 shelikhoo: oh no i worded it badly i mean that i think it's the good next step 17:05:04 cohosh: Yes 17:08:17 maybe we can just postpone the reading group if that works for everyone 17:09:32 +1 17:10:00 anything else then for today? 17:10:41 I'll close the meeting here 17:11:03 #endmeeting