16:01:36 <Shelikhoo[mds]> #startmeeting tor anti-censorship meeting
16:01:36 <MeetBot> Meeting started Thu Jan  8 16:01:36 2026 UTC.  The chair is Shelikhoo[mds]. Information about MeetBot at https://wiki.debian.org/MeetBot.
16:01:36 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:01:36 <Shelikhoo[mds]> here is our meeting pad: https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469
16:01:36 <Shelikhoo[mds]> editable link available on request
16:01:40 <Shelikhoo[mds]> hi hi
16:01:43 <cohosh> hi
16:01:48 <theodorsm> Hey!
16:01:49 <unic3rn> hello
16:01:50 <onyinyang> hellooo!
16:04:25 <Shelikhoo[mds]> happy new year welcome back everyone
16:04:32 <Shelikhoo[mds]> let's start with the first topic
16:04:33 <Shelikhoo[mds]> Relay connect tests / feedback if proxies cannot reach the Snowflake bridge
16:04:33 <Shelikhoo[mds]> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/4050
16:04:40 <Shelikhoo[mds]> cohosh:?
16:04:53 <Shelikhoo[mds]> I think this is from cohosh
16:04:57 <cohosh> yes
16:05:25 <cohosh> we sometimes see an increase in snowflake proxies from a region that is experiencing censorship, when a censorship event happens
16:05:31 <cohosh> that seems to be the case now
16:05:55 <cohosh> we saw an increase in specifically iptproxy snowflakes in IR
16:06:22 <cohosh> this might not be an issues, censorship is sometimes regional
16:06:29 <cohosh> as long as the proxy can reach the bridge, it is useful
16:06:48 <cohosh> but, we don't have checks in place to make sure a proxy can reach the bridge before it polls
16:06:57 <dcf1> do I understand right that if a browser proxy cannot preliminarily connect to snowflake.freehaven.net, then it will not poll and start being assigned clients?
16:07:05 <cohosh> that's true
16:07:13 <Shelikhoo[mds]> personally I think we should fix the test in webext and provide a friendly notification to users
16:07:13 <cohosh> the webext code will check snowflake.freehaven.net
16:07:19 <dcf1> or is the behavior different in browser proxies and iptproxy?
16:07:21 <Shelikhoo[mds]> and add test to standalone proxy
16:07:27 <cohosh> iptproxy uses the Go library
16:07:52 <dcf1> ok, and the go library does not do the same preliminary proxy check, so neither do the standalone proxies ?
16:08:02 <cohosh> that's correct
16:08:11 <cohosh> so iptproxies and standalone proxies are not doing the check
16:08:22 <cohosh> the question is what domain(s) do we check?
16:08:25 <dcf1> ok, I see. I though I remembered having implemented a bridge-first check at some point.
16:08:43 <cohosh> dcf1: i thought so too but i couldn't find evidence of it in the logs
16:08:53 <cohosh> it might have only ever been implemented for browser-based proxies
16:08:59 <dcf1> right, I had not appreciated that the relay patterns complicates this, as relays do not know in advance all the bridges they may be asked to connect to.
16:09:17 <cohosh> yes, hardcoding a domain to check sort of defeats the purpose of our design
16:09:37 <Shelikhoo[mds]> Or we can let the proxy detect it was unable to connect to the bridge
16:09:46 <dcf1> well, hardcoding snowflake.freehaven.net (snowflake-01) is a 90% solution, as I see it
16:09:49 <Shelikhoo[mds]> and increase time before it poll next time
16:10:38 <dcf1> if a snowflake proxy is blocked from any bridge that a client may want to use, then it is probably blocked from snowflake-01. in other words, a low-cost partial solution would be to implement the same check the browser does, even if it is simplictic
16:10:45 <cohosh> dcf1: if we go that route, i think we should change it to snowflake.torproject.net since this is the default relay pattern
16:10:48 <cohosh> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/blob/32d44f6415e41be20eb50108fa72b515443e834f/config.js#L58
16:10:55 <dcf1> yes good idea
16:12:07 <Shelikhoo[mds]> yes, I think both way would work, both connection failure -> increase poll time, and check a hard coded domain
16:12:41 <cohosh> sure, the 90% solution is a good short-term fix, that we could also remove later if we have evidence of more diverse relay patterns
16:13:29 <Shelikhoo[mds]> we should make sure this hard coded domain can be adjusted with command line parameter, since there are also testing environment deployments
16:14:16 <Shelikhoo[mds]> I am happy with the checking a static domain approach as well.
16:14:17 <cohosh> Shelikhoo[mds]: yes, good catch
16:15:16 <cohosh> ok let's move forward with that
16:15:37 <Shelikhoo[mds]> nice!
16:15:38 <cohosh> nothing more from me on this
16:16:05 <Shelikhoo[mds]> okay let's move to the next topic from interesting links
16:16:06 <Shelikhoo[mds]> https://filter.watch/english/2026/01/05/network-monitorig-december-2025-internet-repression-in-times-of-protest/
16:16:59 <cohosh> this was an initial report shared with us, though things have changed since it was posted
16:17:26 <Shelikhoo[mds]> yeah, situation in Iran is rapidly changing
16:17:45 <Shelikhoo[mds]> or pretty much rest of the world as well
16:18:19 <Shelikhoo[mds]> The next interesting link is
16:18:19 <Shelikhoo[mds]> https://opencollective.com/censorship-circumvention/projects/snowflake-daily-operations/updates/2025-december-update
16:18:19 <Shelikhoo[mds]> €4,129.50 for snowflake-01 bandwidth in 2025 https://opencollective.com/censorship-circumvention/projects/snowflake-daily-operations/expenses/278172
16:19:29 <dcf1> donations to Snowflake Daily Operations are tracking to not be enough for 2026 bandwidth, so I added some extra donation encouragement in the most recent monthly report
16:20:23 <unic3rn> Wait, so funding the Snowflake broker is separate from donating to the Tor Project?
16:20:32 <theodorsm> ^
16:20:52 <dcf1> not the snowflake broker, but the snowflake-01 bridge specifically, which is not run by the tor project
16:20:53 <Shelikhoo[mds]> yeah, I wonder if we have an AS with free peering would helped with the situation...
16:23:08 <unic3rn> oh, is the 01 bridge the server through which the snowflake proxy then connects to?
16:23:45 <Shelikhoo[mds]> yes, it is about the 01 and 02 server
16:24:08 <dcf1> unic3rn: there are two bridges, snowflake-01 and snowflake-02. clients may choose to connect through either one of them. the bridge is the actual interface to the tor network (high bandwidth), unlike the broker which is just a matchmaker between clients and proxies and does not carry traffic itself.
16:24:09 <theodorsm> Is it possible to donate compute to run extra bridges?
16:24:36 <Shelikhoo[mds]> The distributed relay system is supposed to support more than just 2 snowflake bridges
16:25:17 <Shelikhoo[mds]> if we have maybe more snowflake bridges, the cost can be spread across more operators
16:25:27 <dcf1> compute is not the issue. bandwidth is the major expense, and I believe we are already getting a good deal on bandwidth. additional bridges with low-cost or paid-by-someone-else bandwidth may help, at the cost of added maintenance and bookkeeping
16:26:59 <dcf1> anyone running a bridge needs to be aware that they can expect roughly the same amount of costs, at least the low thousands per year, and they need to be on the ball with respect to keeping the server running and updated, otherwise it causes big headaches for us
16:27:27 <theodorsm> What is the order of bandwidth the bridges are running with?
16:27:36 <theodorsm> Or would be helpfull?
16:28:04 <Shelikhoo[mds]> It would be nice if snowflake can operate like webtunnel or obfs4
16:28:10 <theodorsm> Would be more robust with more than two bridges also?
16:28:24 <dcf1> theodorsm: the connection needs to be 10 Gbit/s, 1 Gbit/s is not sufficient. You can see actual levels in the report: https://opencollective.com/censorship-circumvention/projects/snowflake-daily-operations/updates/2025-december-update
16:28:30 <Shelikhoo[mds]> but I understand it is more complex than that
16:28:55 <theodorsm> dcf1: ack, thanks!
16:29:11 <dcf1> More bridges would *decrease* robustness imo, because it's more to manage and more things that can break. it may be worth doing for reasons of capacity (which hasn't been an issue for a couple of years now) or to reduce costs.
16:29:45 <dcf1> theodorsm: you can find bandwidth CSV files at https://gitlab.torproject.org/dcf/snowflake-graphs
16:30:12 <unic3rn> So the snowflake bridge differs from other bridge types by looking like WebRTC traffic, right? Clients can either connect to the snowflake bridge via a snowflake proxy or directly to it.
16:31:03 <Shelikhoo[mds]> in theory if users can just switch bridges then maybe adding more bridges will not decrease reliability, but this would require some user action
16:31:17 <Shelikhoo[mds]> and the bookkeeping burden would be increased
16:31:29 <dcf1> unic3rn: no, the connection to the bridge is websocket, not webrtc. client<->proxy is webrtc, proxy<->bridge is websocket. in theory a client could directly connect to the bridge over websocket but that's not a supported configuration in the software we ship, anyway (and it would not be blocking-resistant)
16:32:21 <Shelikhoo[mds]> but I agree we should not focus on getting more snowflake servers right now
16:32:37 <dcf1> unic3rn: see https://www.bamsoftware.com/papers/snowflake/#p29 "The choice of WebSocket for this link is arbitrary, and another protocol might be substituted in its place. It does not need to be blocking-resistant..."
16:33:22 <dcf1> Shelikhoo[mds]: right, I'm not saying there is anything necessarily to be solved right now, just giving a status update
16:33:54 <unic3rn> ok, so snowflake bridges require snowflake proxies to be run for Snowflake in Tor to work
16:34:17 <Shelikhoo[mds]> yes, we need both bridge, broker, and proxy for clients to connect
16:34:55 <Shelikhoo[mds]> anything more we wish to discuss on this topic
16:35:06 <Shelikhoo[mds]> there is a discuss group for a paper next
16:35:18 <Shelikhoo[mds]> We will discuss "CenPush: Blocking-Resistant Control Channel Using Push
16:35:18 <Shelikhoo[mds]> Notifications" on January 8th, 2026
16:35:18 <Shelikhoo[mds]> https://petsymposium.org/popets/2025/popets-2025-0153.pdf
16:36:43 <Shelikhoo[mds]> anyone volunteer to summarize this "avoid blocking of metadata by using mobile OS push notification as a block resistant channel" ?
16:38:25 <Shelikhoo[mds]> In this paper, the use of Android and iOS push notification channel as a way to deliver anti-censorship metadata to client was explored
16:39:27 <cohosh> oops, i suppose i could summarize but maybe it's better if someone else does
16:39:31 <theodorsm> cohosh: very interesting work!
16:39:56 <onyinyang> yes, great work cohosh and the other authors :D
16:39:57 <Shelikhoo[mds]> for Android, Google Firebase Cloud Messaging and iOS Apple Push Notification service was used
16:40:01 <cohosh> thanks
16:41:33 <theodorsm> I anonomized censorship circumvention system was deployed with push notifications to update configuration, and the authors evaluated if push notifications were censored (which they were not by a good margin)
16:41:33 <Shelikhoo[mds]> Since this service is usually provided by operating system and usually cannot be replaced by applications themselves
16:41:45 <theodorsm> They*, not I
16:41:55 <theodorsm> A*, Not I
16:42:35 <Shelikhoo[mds]> it provides makes the decision to block them very costly
16:43:16 <theodorsm> Snowflake is included in orbot right?
16:43:20 * meskio just noticed the meeting is not in 15min but already running, sorry
16:43:24 <Shelikhoo[mds]> the authors also analysised whether the traffic shape would be recognizable
16:44:27 <Shelikhoo[mds]> and other other proprieties of the push notification channel
16:44:46 <Shelikhoo[mds]> like the amount of data a single push message can carry
16:45:42 <Shelikhoo[mds]> Anything I am missing that is important? free free to add
16:46:18 <theodorsm> Having push notifications on can be a privacy risk
16:46:49 <unic3rn> Yes, Snowflake is in Orbot. Can applications copy the push notification values and use them in-app or would the user only be able to see them in the notification bar?
16:47:05 <cohosh> this isn't the first look at using push notifications for censorship circumvention, there's also Diwen and Roya's FOCI paper from 2023: https://www.petsymposium.org/foci/2023/foci-2023-0009.pdf
16:47:45 <theodorsm> unic3rn: the settings can be applyed by pressing apply link in the notification
16:48:56 <cohosh> theodorsm: that's right, mobile phones with push notifications on maintain a consistent connection to the push notification service, which means that service can see when the user is online or offline, changes in IP address, and which applications that user receives push notifications from
16:49:30 <Shelikhoo[mds]> Personally I think one of the issue of mobile app push notification is that the app can be deplatformed quite easily
16:49:52 <Shelikhoo[mds]> (about 6.3 Platform Censorship and Geo-restriction)
16:50:24 <meskio> as in they might cut the push notifications "account" or as in they might remove the app from the store?
16:50:27 <cohosh> unic3rn: the orbot implementation described in the paper is not deployed, so it was more an exploration of what a UX could look like
16:51:06 <meskio> shutting down the account is a similar risk we have with other signaling channels
16:51:09 <Shelikhoo[mds]> they can do either or all of them
16:51:23 <Shelikhoo[mds]> they can either remove the app
16:51:33 <Shelikhoo[mds]> or disable push notification channel
16:51:55 <Shelikhoo[mds]> the risk with apple store and google service is higher
16:52:02 <Shelikhoo[mds]> as they requires non-resetable id
16:52:31 <meskio> as in the id is connected to the app itself?
16:52:34 <Shelikhoo[mds]> like passport, and company registration information, bank account info to open an developer account
16:52:52 <meskio> I see
16:52:52 <theodorsm> Notification could be read from another application via AccessibilityService, so the channel could be distributed through other apps which would mitigate the deplatforming of one app, but it introduces more privacy issues.
16:53:56 <Shelikhoo[mds]> in apple's case, the push notification account and the app store connect(app publishing account) have to be the same
16:54:10 <Shelikhoo[mds]> this is not the same case for google's play store and firebase
16:54:28 <theodorsm> true
16:54:48 <theodorsm> Off-topic, but I have to run very soon: Anyone here, or from the Tor Project, going to FOSDEM this year?
16:54:57 <Shelikhoo[mds]> I think maybe a better approach is to use web push instead
16:55:20 <cohosh> i also see the deplatforming issue as similar to other signaling channels
16:56:04 <meskio> theodorsm: there are people from Tor going, I think ahf is, I was considering it but I don't think I'll be able
16:56:05 <Shelikhoo[mds]> it is not great from user usability point of view, since it would require more user action
16:56:13 <cohosh> domain fronting providers have already deplatformed us in a similar way
16:56:37 <theodorsm> mesiko: ok, thanks:)
16:56:40 <cohosh> orbot already faces the risk of being removed from app stores
16:56:42 <Shelikhoo[mds]> but it would be harder to block completely by the push provider
16:56:54 <cohosh> Shelikhoo[mds]: yeah i think web push is a good avenue to explore
16:57:00 <meskio> theodorsm: I'll poke you if I end up going
16:57:22 <Shelikhoo[mds]> cohosh: i think the difference is that, while cdn and domain fronting providers are interchangeable
16:57:31 <theodorsm> meskio: cool, I'm not sure myself, just polling around if there any reasons to go and meet people:)
16:57:49 <Shelikhoo[mds]> google, and apple have a monopoly on Android and iOS apple publishing channel
16:58:04 <Shelikhoo[mds]> which is hard to replace without user noticeable\ change
16:58:11 <theodorsm> Have to run off, see you all next time, happy new year!
16:58:36 <cohosh> theodorsm: thanks for joining!
16:59:12 <Shelikhoo[mds]> let's say of apple closed the developer account, we can't just update the setting and let user keep using our service
17:00:02 <Shelikhoo[mds]> I think for this reason the developer's cost of getting banned by Apple and Google is higher
17:00:07 <cohosh> Shelikhoo[mds]: yeah that's a good point, and it's adjacent to some other reasons i had for not reaching a deployable implementation
17:00:13 <Shelikhoo[mds]> EOF comment from me
17:00:38 <Shelikhoo[mds]> yes, we could try if web push would work...
17:00:47 <cohosh> both the distributor side and the client side require a bespoke implementation for sending and receiving push notifications
17:01:54 <cohosh> unlike domain fronting, which is simple and consistent across providers
17:02:00 <Shelikhoo[mds]> EOF from me
17:02:26 <cohosh> web push would likely be much more worth the implementation cost if we can easily switch between providers
17:02:59 <onyinyang> oooh push notifications for Lox reachability credentials
17:03:02 <onyinyang> nice idea
17:03:09 <cohosh> and a lot of the lessons from this work can be applied to web push, such as the privacy analysis in section 5.1.2
17:03:54 <Shelikhoo[mds]> yes, BTW we can also use this in reverse
17:04:02 <meskio> we should add a link to cenpush in https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Signaling-Channels/Push-Notifications
17:04:34 <Shelikhoo[mds]> if the censor don't want websites operates in their region to be cut off from pushing notification to users anywhere
17:04:48 <Shelikhoo[mds]> they cannot block the push message broker
17:05:04 <Shelikhoo[mds]> so we can run a few browser on the server
17:05:19 <Shelikhoo[mds]> and allow clients to push message to this browser
17:05:41 <Shelikhoo[mds]> so that client can upload some infos as well
17:05:45 <Shelikhoo[mds]> like the push token
17:05:58 <Shelikhoo[mds]> without direct connection to the server
17:06:04 <cohosh> Shelikhoo[mds]: oh that's interesting
17:06:48 <Shelikhoo[mds]> okay EOF from me
17:07:06 <meskio> that is a cool idea to make it bidirectional
17:07:30 <onyinyang> yeah!
17:08:23 <Shelikhoo[mds]> nice
17:08:24 <Shelikhoo[mds]> #endmeeting