16:00:23 <shelikhoo> #startmeeting tor anti-censorship meeting
16:00:23 <shelikhoo> here is our meeting pad: https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469
16:00:23 <shelikhoo> editable link available on request
16:00:23 <MeetBot> Meeting started Thu Dec 12 16:00:23 2024 UTC.  The chair is shelikhoo. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:23 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:27 <shelikhoo> hi~hi~
16:00:48 <cohosh> hi
16:01:37 <onyinyang> hello!
16:04:03 <shelikhoo> dcf1: I see "open issue to disable /debug endpoint on snowflake broker" is in your todo. I would like to let you know that with the new nginx reverse proxy, this url is no longer accessible to users
16:04:40 <shelikhoo> let's start with the discussion topic
16:04:42 <shelikhoo> Ok to turn off the old snowflake broker now? https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40412
16:04:55 <dcf1> hmm, I'm sure I tested /debug while playing with the azure setup this week, and it worked.
16:05:25 <shelikhoo> I think maybe azure is directly connect to the old broker
16:05:38 <dcf1> oh, you're right, that makes sense
16:05:40 <shelikhoo> and not actually sending traffic to the new broker?
16:05:51 <cohosh> oh is it still using the bamsoftware broker domain?
16:06:00 <dcf1> yes, it is. I hadn't thought of that.
16:06:07 <shelikhoo> this could explain why there is a spike of fee
16:06:24 <shelikhoo> because there is a lot of retry with failed requests
16:06:31 <dcf1> Let me log in and change that in the azure config, that would have some client&proxies still using the old broker
16:06:37 <shelikhoo> we should either disable or amend the azure config
16:07:00 <dcf1> Also I'll update the snowflake-broker.bamsoftare.com DNS record.
16:07:32 <dcf1> I'm sorry for not thinking of that.
16:07:59 <shelikhoo> the new broker is not configured to acquire certificate for the  snowflake-broker.bamsoftare.com domain yet
16:08:06 <dcf1> It's only been this week that I've got an idea of who might still be using snowflake-broker.azureedge.net (onionwrapper) https://lists.torproject.org/mailman3/hyperkitty/list/anti-censorship-team@lists.torproject.org/message/NLECLBHRZUXHP5U5EXLQQFQDSV6ZJE5P/
16:08:41 <dcf1> You're right, with a cert it doesn't make sense, but I'll update the CDN configuration anyway.
16:09:24 <shelikhoo> anyway, I suggest to remove the record when we shutdown the old broker, as the ip could get recycled
16:10:04 <shelikhoo> I think it is in general okay to maybe shutdown but not delete the instance for a week, before deleting the instance
16:10:32 <shelikhoo> to see if there is anything still depended on it
16:11:02 <dcf1> Then I can proceed with shutting down the old broker? I'll do that right after the meeting.
16:11:31 <shelikhoo> yes, let shutdown it and not delete it
16:11:38 <shelikhoo> for the time being
16:12:44 <shelikhoo> anything more on this topic?
16:12:59 <dcf1> no
16:13:12 <shelikhoo> okay let's move to the next topic
16:13:14 <shelikhoo> what was that censorship alerts mailing list?
16:13:14 <shelikhoo> https://lists.torproject.org/mailman3/postorius/lists/anti-censorship-alerts.lists.torprojec
16:13:51 <dcf1> cohosh: I saw this question in your section, is that what you mean?
16:14:07 <shelikhoo> https://gitlab.torproject.org/tpo/tpa/team/-/issues/41907#note_3139973
16:14:22 <shelikhoo> I think there is some ongoing issue with the new mailing list system
16:14:24 <cohosh> dcf1: i'm not sure, that link fails for me
16:14:34 <cohosh> shelikhoo: no this is something different from that
16:14:38 <shelikhoo> https://lists.torproject.org/mailman3/postorius/lists/anti-censorship-alerts.lists.torproject.org/
16:14:51 <shelikhoo> ^^^ updated link
16:14:56 <cohosh> i was wondering about the mailing list that some researchers made to use tor metrics to warn about potential censorship events
16:15:13 <dcf1> oh I know the one you are thinking of
16:15:19 <shelikhoo> sorry for bad copy and paste...
16:15:58 <cohosh> no worries, i'm still getting used to the new url and didn't recognize it XD
16:16:06 <dcf1> https://arxiv.org/abs/1507.05819 "On Identifying Anomalies in Tor Usage with Applications in Detecting Internet Censorship"
16:16:19 <cohosh> yes that is exactly what i was looking for
16:16:32 <dcf1> There is a link for a mailing list somewhere. I seem to recall that when I looked for it recently it was offline, but I'm not sure.
16:16:33 <cohosh> thank you
16:17:07 <cohosh> that's fine, the explanation of how they did it is the most useful part anyway
16:17:23 <shelikhoo> quoted replay for "I'm sorry for not thinking of that." <<< no worry... it is fine
16:17:44 <shelikhoo> (shell try to stop myself to regret to not reply that message with no worry...)
16:17:46 <shelikhoo> okay
16:17:53 <dcf1> https://censorbib.nymity.ch/#Wright2018a may be a published version
16:17:58 <dcf1> 2018
16:19:57 <dcf1> "infolabe-anomalies" was the name of the mailing list and archives
16:19:59 <GeKo> cohosh: we've been talking to those folks more or less recently and they are up i think to work on that area with us if we want iirc
16:20:04 <GeKo> yeah
16:20:25 <cohosh> GeKo: oh awesome
16:20:44 <cohosh> we had some vaguely defined sponsor work that led me there, i'll reach out to you about it
16:20:54 <GeKo> sounds good!
16:21:46 <GeKo> cohosh: https://gitlab.torproject.org/tpo/network-health/team/-/issues/94 is the context fwiw
16:22:12 <GeKo> and joss is on that ticket as well
16:22:15 <cohosh> GeKo: here's the ticket on our side: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40416
16:22:27 <GeKo> i see
16:23:27 <shelikhoo> (from 4.4 Combining Features to Identify Targeted Filtering)as I understood a censorship event could either resulting in a sharp change of amount of users...
16:24:41 <shelikhoo> so basically by calculating an rolling window of deviations, we can see whether there is a hint about network censorship events
16:25:23 <shelikhoo> okay, is there anything more we would like to discuss on this topic?
16:26:01 <dcf1> shelikhoo: what you are describing is perhaps more like "An anomaly-based censorship-detection system for Tor" https://research.torproject.org/techreports/detector-2011-09-09.pdf
16:26:40 <dcf1> Which is what drives the "censorship events" at https://metrics.torproject.org/userstats-relay-country.html and has never been particularly useful imo
16:27:08 <shelikhoo> thanks dcf1, I might need to read the paper in detail to have a better summary of it
16:28:44 <dcf1> E.g. https://metrics.torproject.org/userstats-relay-country.html?start=2024-09-13&end=2024-12-12&country=de&events=on
16:29:36 <shelikhoo> and yes... I think there is so many events that can trigger an change in directly connected users
16:29:55 <dcf1> blue dot = above expected range, red dot = below expected range. Because this anomaly detector has a hard-coded interval of 1 week, you get a negative "echo" of sharp events like the one on that graph.
16:30:29 <dcf1> yeah I tried it myself a bit in grad school, it's not so easy.
16:31:42 <shelikhoo> yes it seems quite noisy...
16:32:27 <shelikhoo> maybe if we got the signaling library the connectivity feedback can be built in to gather more direct data
16:32:42 <cohosh> heh, maybe this is a little optimistic to take it on for this project then
16:33:08 <shelikhoo> but it would needs to include user privacy concerns...
16:34:59 <cohosh> i might not end up pursuing this now, but the idea is to look at what we can do with our snowflake broker metrics and maybe have alerts if they drop off suddenly
16:35:12 <shelikhoo> cohosh: I think it is hard to predict the actual achievement of such effort... If I were you I would maybe draw a few charts and see if it would work..
16:35:16 <cohosh> i don't have high aspirations for this iteration of it
16:35:22 <dcf1> There is even a dedicated page on tor metrics that counts the blue and red dots using that methodology https://metrics.torproject.org/userstats-censorship-events.html
16:37:29 <shelikhoo> yeah, anything more we would like to discuss on this topic? I feel the conclusion was this is not an easy task and more research is needed...
16:37:53 <cohosh> that is definitely too noisy, i think a more reasonable outcome of this something that issues an alert if polls from a country drop to like 10% of what they were over the course of a few hours
16:38:02 <cohosh> and go from there
16:38:40 <cohosh> in any case, thanks for the links, i'll read them and update the issue
16:38:50 <cohosh> that's all from me
16:39:01 <shelikhoo> thanks cohosh
16:39:03 <shelikhoo> the next item in today's meeting is about
16:39:11 <shelikhoo> Azure CDN from Edgio (azureedge.net) is due to be shut down as early as 2025-01-15:
16:39:29 <shelikhoo> we have previously discussed about this in this meeting
16:39:41 <shelikhoo> anything more we would like to discuss about this topic?
16:41:56 <cohosh> i'm unsure of whether our meek builtin bridge will stop working as a result
16:42:42 <cohosh> we might need to update it or make a decision to remove it as a builtin option
16:43:07 <cohosh> i'll follow up on that with micah
16:44:13 <shelikhoo> yes
16:44:46 <shelikhoo> anything more we would like to discuss in this meeting?
16:45:27 <onyinyang> nothing from me
16:46:23 <shelikhoo> pkay no need to keep everyone hostage, I will end the meeting here!
16:46:23 <shelikhoo> #endmeeting