15:58:38 <cohosh> #startmeeting tor anti-censorship meeting
15:58:38 <MeetBot> Meeting started Thu Jan 21 15:58:38 2021 UTC.  The chair is cohosh. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:58:38 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:58:42 <cohosh> hi everyone!
15:58:45 <gaba> hi!
15:58:46 <agix> hi
15:58:50 <hanneloresx> hi!
15:58:51 <phw> o/
15:58:56 <cohosh> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
15:59:21 <anadahz> hi
16:00:00 <cohosh> the first announcement is that we hav a job opening for our anti-censorship team: https://www.torproject.org/about/jobs/software-developer-anticensorship/
16:02:08 <cohosh> we'd love to see people here apply :)
16:02:48 <cohosh> next for discussion we have a postmortem for the drop in PT users we saw this week
16:03:39 <cohosh> dcf1 pointed out that our snowflake usage dropped to 0: https://lists.torproject.org/pipermail/anti-censorship-team/2021-January/000133.html
16:03:45 <dcf1> from https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40282 I still don't understand what happened
16:04:38 <cohosh> dcf1: yeah i'm also a bit confused about that
16:04:45 <cohosh> the consensus is that it's a tor bug
16:04:57 <dcf1> `set_options(): Bug: Acting on config options left us in a broken state. Dying.`
16:05:01 <cohosh> but it was only triggered when DisableNetwork was set to 1
16:05:21 <cohosh> and I don't see that any torrc files that TorBrowser generated for me
16:05:46 <cohosh> and it only happened for default bridges for me
16:06:36 <anadahz> Is this bug always reproducible or it is related to specific network(s)?
16:06:56 <cohosh> both phw and i were able to reproduce it
16:07:42 <phw> in my case i simply started tor browser alpha, made it use snowflake, and boom
16:09:02 <cohosh> same, it happened for me with any default bridge. and also with starting tor on the command line with a torrc file that contained DisableNetwork 1
16:10:09 <dcf1> according to https://gitlab.torproject.org/tpo/applications/tor-browser-bundle-testsuite/-/issues/40012 the first bad commit was https://gitweb.torproject.org/tor.git/commit/?id=ea52705e4b1753a75aac77ec0bc828d70327a4ad which was a fix for #25528
16:10:32 <dcf1> https://gitlab.torproject.org/tpo/core/tor/-/issues/25528
16:11:05 <dcf1> But yeah I guess the postmortem discussion is how/why this didn't come to the attention of the team sooner
16:11:25 <cohosh> yup
16:11:53 <phw> a user first filed this 3 weeks ago and we found out about it the other day
16:12:32 <cohosh> i think we discussed this in a previous postmortem, but an alert when PT usage drops significantly would have been helpful (but also, too late in this case)
16:14:03 <phw> one answer can be: teams need to get better at notifying each other of problems. another answer can be: we need to get better at finding anti-censorship issues that aren't filed in an anti-censorship repository
16:14:59 <cohosh> dog fooding is an interesting suggestion, i used to dogfood snowflake quite a bit and then stopped recently because of some things i wanted a faster connection for
16:15:15 <cohosh> it would be hard for us to dogfood all of our tools frequently
16:16:01 * cohosh imagines a script that randomly edits Tor Browser's torrc files to switch between transports
16:16:33 <anadahz> In fact ooniprobe legacy version in Python has a nice test to do exactly this.
16:17:01 <phw> there will always be subtle bugs that we won't catch but in this case there was an actual issue that we didn't see. that cannot happen
16:17:12 <anadahz> The python version of ooniprobe is not maintained any more.
16:17:50 <anadahz> But for an easy way to daily test x numbers of PTs it may be very useful.
16:17:52 <phw> in the past, i'd join the irc channel that streams all new trac tickets and my irc highlights would help finding any anti-censorship related bugs. there's probably a gitlab equivalent for this
16:18:29 <cohosh> anadahz: in this specific case ooni probe wouldn't have caught it though, since it required the specific torrc combination that Tor Browser was using
16:19:09 <dcf1> I was going to mention the tor-qa list, but it seems to be only stables that are announced there https://lists.torproject.org/pipermail/tor-qa/2020-December/thread.html
16:20:22 <arlolra> make it part of the release process for TB to test all the pts?
16:20:58 <gaba> phw: nobody at Tor saw this issue as something that should be in anti-censorship team plate. I think in the general it would be good to call people when they need to know about an issue. This is not something only for the team to do
16:23:41 <cohosh> arlolra: yeah, or we could keep track of new releases and make sure we test the PTs when they roll out
16:23:57 <phw> gaba: i think it was clear that this was censorship-related, e.g. "All bridges fail, but moat works." to be clear, i'm obviously not blaming other teams but there should be a way for us to find tickets that were filed in other repos
16:24:25 <gaba> yes, what im saying is that this is not only responsability of the anti-censorship team to find
16:24:33 <anadahz> cohosh: The code of the test may be tweaked to mirror the torrc config of Tor Browser. https://github.com/ooni/probe-legacy/blob/master/ooni/nettests/blocking/bridge_reachability.py
16:24:36 <phw> i think the biggest problem here is that we don't have enough insight into what's filed on our bug tracker
16:25:07 <gaba> maybe we need to discuss this at an all hands as a reminder to make a note to other people when something like this issue is filled
16:25:14 <cohosh> that and finding the bug required manually checking the usage metrics instead of an auto alert
16:25:51 <gaba> I personally try to read all issues that are filled in gitlab im subscribe to everything) but clearly didnt realize this issue was not seen by you all
16:26:51 <phw> it may be helpful to ingest more data into prometheus. i have a dashboard in my browser that i use to monitor bridgestrap and rdsys. whenever something breaks, i find out very quickly
16:26:59 <phw> but that's more of a long-term solution
16:27:15 <cohosh> anadahz: yeah, what i mean is that it would be difficult for us to know ahead of time which torrc options + tor version + tor browser UX steps would break something. i think there's only so far we can get with automated testing
16:27:39 <cohosh> phw: does it send auto alterts, or you just keep it open and occassionally test it?
16:27:47 <cohosh> *check it
16:28:22 <dcf1> another thing to consider is that this is the kind of thing an alpha release is supposed to catch
16:28:36 <dcf1> for us with Snowflake, alpha is prod, so there's no fallback
16:28:37 <gaba> right
16:28:39 <phw> cohosh: i believe it can send auto alerts but i've just been keeping an eye on it
16:28:41 <cohosh> true
16:29:02 <dcf1> but if a change like this went into an alpha release and we still had a stable release that works, arguably that's what the alpha is for
16:30:00 <phw> i suppose that's the silver lining: the process worked as intended
16:30:03 <cohosh> yeah that's true. in some ways everything was working as it should
16:31:32 <cohosh> okay so, increased communication and auto alerts are two things we can continue to explore
16:31:38 <cohosh> should we move on to the next discussion item?
16:32:47 * cohosh takes crickets as a yes
16:32:53 <gaba> yes
16:32:54 <gaba> :)
16:33:17 <cohosh> okay so... after this gets fixed we're going to want to get more alpha users of snowflake before we can move it to stable
16:33:41 <cohosh> for a couple reasons
16:33:52 <cohosh> we want to shake out bugs and learn more about what the quality of connections is like
16:34:10 <cohosh> but also we want to see if the system can handle a lot more users
16:34:33 <cohosh> we had about 75-100 snowflake users
16:34:44 * ggus is here
16:35:00 <cohosh> which is a lot fewer than we'd expect if it was in stable
16:35:05 <cohosh> ggus: hi!
16:35:40 <cohosh> so ggus and dunqan are going to help us get more users and set up an optional survey to get feedback
16:35:55 <dunqan> (hello!)
16:35:56 <cohosh> i'd like some feedback on 1) what survey questions or data is useful to us?
16:36:21 <cohosh> and 2) how many users do we need before moving snowflake to stable?
16:36:40 <cohosh> here's a ticket about this with more info: snowflake#40007
16:38:58 <ggus> cohosh: right now is possible to use snowflake on OnionBrowser, do we want to tell people to also try onionbrowser+snowflake too?
16:39:12 <phw> i can help with revising the survey questions. i once spent a lot of time worrying about phrasing and question design in a research project
16:39:43 <cohosh> ggus: oh yeah that would also be helpful
16:39:48 <cohosh> phw: thanks!
16:41:00 <cohosh> okay we can move on to our needs help with
16:41:16 <ggus> cohosh: wait
16:41:26 <cohosh> okay
16:41:32 <ggus> how long we should do this survey?
16:41:53 <cohosh> i guess that depends on how much feedback we get
16:42:24 <dunqan> yeah, for ux surveys I normally pick a minimum duration and then just monitor the volume of responses
16:42:57 <cohosh> cool, is 2-3 weeks typically enough? i've never run a survey before >.<
16:43:58 <dunqan> for snowflake users recruited over our social channels I'm not sure, but let's just say yes and I'll keep an eye on it and report back :)
16:44:16 <cohosh> okay great, thanks dunqan and ggus!
16:44:40 <cohosh> any other questions/feedback on that?
16:44:41 <ggus> cohosh: should we try to include people in censored networks too, like china?
16:44:54 <cohosh> ah, that would be helpful
16:45:00 <ggus> i dont remember if snowflake is working in china right now
16:45:02 <cohosh> i've been wondering what the connection quality is like there
16:45:09 <cohosh> ggus: it should work
16:45:11 <phw> i wonder if we can add a link to the survey in tor browser alpha's landing page
16:45:18 <cohosh> if it doesn't i'd love to know more
16:45:38 <cohosh> phw: oo that's a good idea
16:45:39 <phw> ...because the population of snowflake users is already a small one, and the intersection between that population and the people following our outreach channels is even smaller
16:46:20 <ggus> when we will have tb-alpha release?
16:47:10 <dunqan> phw: we're actually adding a banner to stable for a UX survey next month
16:47:32 <dunqan> so we could potentially co-opt that and add a snowflake version to alpha
16:47:40 <phw> dunqan: if this was gitlab, i'd award you the pineapple of excellence!
16:47:52 <dunqan> it would obviously appear for all alpha users though
16:47:52 <ggus> hahah
16:47:55 <dunqan> ha!
16:48:03 <cohosh> ggus: that fixes the current issue? i'm not sure, GeKo or sysrqb would know more
16:48:44 <cohosh> AlwaysLivid: hey!
16:48:58 <AlwaysLivid> hello!
16:49:02 <cohosh> okay let's go on to assigning reviews and continue this discussion in the ticket
16:49:10 <cohosh> since we're approaching the 1 hour mark
16:49:18 <AlwaysLivid> wow. i got the timezone wrong didn't i.
16:49:27 <AlwaysLivid> wew, i did!
16:49:42 <cohosh> AlwaysLivid: we're about the start the reading group after this
16:49:47 <cohosh> so you are on time for that :)
16:50:00 <AlwaysLivid> oh, so there's still a bit of time for me to budge in
16:50:16 <cohosh> i can use a review of snowflake!26 but i'm not going to deploy it quite yet so there's not rush on that
16:50:31 <dcf1> I'll do snowflake!26
16:50:36 <cohosh> thanks dcf1!
16:50:42 <AlwaysLivid> (apologies, see you next week :P)
16:50:56 <cohosh> AlwaysLivid: there is time!
16:51:10 <cohosh> i have on my todo list to give feedback on sproutsbot
16:51:38 <AlwaysLivid> uhh okay i'm not sure what I can fit within the given timeframe but another thing I was wondering about is using rdsys alongside with onionsproutsbot
16:51:53 <cohosh> yeah i'm working on rdsys#32 right now
16:51:55 <AlwaysLivid> but obviously i have to be done with the original idea first and actually deliver binaries
16:52:11 <cohosh> that needs to be done first before we look at the specifics of the telegram distributor
16:52:14 <AlwaysLivid> hm, i will take a look and see how i'll implement this in my own code when it's done
16:52:15 <AlwaysLivid> yup!
16:52:23 <AlwaysLivid> alongside dozens of other things
16:52:29 <cohosh> :)
16:52:43 <AlwaysLivid> uh okay 5 minutes and 15 seconds left
16:52:58 <cohosh> yeah anything else before we move on to the reading group discussion?
16:53:07 <hanneloresx> i have a quick question
16:53:14 <cohosh> hanneloresx: go for it :)
16:53:31 <hanneloresx> i think i can suggest something for gettor!34058
16:53:36 <hanneloresx> but i'm not a member of the project
16:53:44 <hanneloresx> so i can't make a new merge request
16:53:50 <hanneloresx> what's the best way to send in my patch?
16:54:02 <cohosh> oh, i can make you a member
16:54:15 <hanneloresx> oh, kk. i didn't see a way to request access
16:54:27 <hanneloresx> thanks!
16:54:28 <cohosh> i didn't know that gitlab users cannot submit MRs by default :/
16:54:49 <rustom> Hi! I’m new here and would love to contribute, and I just submitted request for access on gitlab as well
16:54:52 <hanneloresx> yeah visitors cannot, reporters and above can, apparently
16:54:54 <gaba> cohosh: i think they can. they just need to fork the repo?
16:55:13 <cohosh> hanneloresx: did you fork the repo?
16:55:24 <cohosh> rustom: hey and welcome :)
16:55:26 <hanneloresx> hm not yet. i'll look into that
16:55:35 * dcf1 manual zwiebelbot https://gitlab.torproject.org/tpo/anti-censorship/gettor-project/trac/-/issues/34058
16:55:56 <cohosh> okay the right workflow is to fork it and make a branch on your own fork
16:56:04 <cohosh> and then submit a mr for that branch
16:56:12 <hanneloresx> got it, will try that! thank you!
16:56:22 <cohosh> rustom: hopefully that helps you as well
16:56:26 <AlwaysLivid> Speaking of that link involving #34058: I'm trying to implement the Telegram distributor without using any logs that involve the user (which prohibits using databases), is that a correct approach BTW?
16:56:56 <cohosh> yes we should not be logging individual user information
16:56:58 <GeKo> ggus: next tuesday/wednesday
16:56:58 <AlwaysLivid> obviously a rough party can obviously just log or something somehow
16:57:00 <AlwaysLivid> got it.
16:57:04 <rustom> makes sense!
16:57:13 <AlwaysLivid> how about the anti-spam system though cohosh
16:57:21 <cohosh> alright let's move on to the reading group
16:57:33 <cohosh> and continue these other convos after on #tor-dev
16:57:38 <AlwaysLivid> no worries!
16:57:50 <AlwaysLivid> all good
16:58:00 <AlwaysLivid> to-do: change the calendar date/time date
16:58:12 <AlwaysLivid> (my calendar)
16:58:14 <ggus> GeKo: thanks!
16:58:20 <cohosh> our reading today was on the early detenction of censorship events with psiphon network data: https://tics.site/proceedings/2019a/icn_2019_7_10_38005.pdf
16:58:53 <cohosh> i sent an email to the authors, but i'm not sure if they made it to the meeting
16:59:06 <dcf1> with three case studies in Iran, Iraq, Turkmenistan in 2018
16:59:19 <kmc> @cohosh Hi there!
16:59:19 <cohosh> anyone have a quick summary they want to share?
16:59:23 <cohosh> kmc: oh hey!
16:59:34 <cohosh> our regular meeting went a bit longer than usual, glad you could make it
16:59:39 <cohosh> (and on such short notice)
16:59:42 <dcf1> kmc must be author Keith McManamen, hi Keith
17:00:01 <ggus> hey keith o/
17:00:07 <kmc> @dcf1 hi!
17:01:00 <kmc> Glad I didn't miss it. Thanks all for discovering this short paper. Mostly wanted to put some thoughts and data down on paper, as a jumping off point for future methodology work and discussion.
17:01:04 <anadahz> also thanks for highlighting a paper from TICS ;)
17:01:28 <cohosh> :D
17:01:35 <kmc> I'd be happy to answer any questions people have and looking forward to hearing comments, feedback, critiques and so forth.
17:02:12 <cohosh> kmc: i also saw that you publish some real-time psiphon stats: https://psix.ca
17:03:18 <dcf1> there was an IMV talk (Internet Measurement Village) that talked about psix.ca: https://github.com/net4people/bbs/issues/37#issuecomment-646661420
17:03:24 <kmc> Yes, that was an output of the Psiphon Data Engine or PDE project, which was an effort to harmonize data from circuvmention tools with other open data showing the censorship landscape, network performance etc.
17:05:03 <kmc> In *near* real-time. But as a basis for future research and for responses to blocking events, outages, and other network disruptions. One of the issues with delving into such events is that the data is scattered across many different places. So having a dashboard that you can view various indicators along the same time series is really useful.
17:05:41 <cohosh> nice!
17:05:43 <kmc> (OONI metrics were included there but there was a shuffle after the recent pipeline update, so that's temporarily on the to-do list)
17:06:05 <dcf1> So if I may interpret the common pattern in the graphs of the paper: complete shutdown -> Psiphon goes to zero (obviously); restrictions on certain apps -> Psiphon goes up; relaxation of restrictions -> Psiphon goes down.
17:07:16 <kmc> @dcf1 yes that's bvasically the general trend. If you look at UG on the dashboard you should see what a blocking event + outage situation looks like
17:08:31 <kmc> There are several other great data sources that would be really useful to include on the public dashboard over time
17:08:49 <cohosh> yeah i like the idea of overlaying different sources in the same place
17:09:12 <cohosh> i have a question about the case study in turkmenistan
17:09:17 <cohosh> where you saw dpi blocking
17:09:55 <cohosh> you mentioned there was a gradual decrease in users, do you know why it was gradual and not sudden?
17:10:23 * phw has to leave early for another appointment o/
17:10:26 <cohosh> like, was the dpi not fully effective, but it decreased usability?
17:12:21 <kmc> It's likely that large-scale blocking like that which is able to completely shift connection types on the network, yes, makes some protocols non-viable. But for the remaining ones, even if users can connect, may also decrease their performance and relative throughput.
17:13:26 <kmc> Since the disruptions identified in that case study has ensued a basically 2 year saga of cat+mouse
17:14:25 <cohosh> so you think the dpi technqiues are expensive and decrease connection quality overall?
17:14:51 <cohosh> (enough to see some users decide it isn't worth it)
17:16:54 <kmc> If the censors successfully degrade session quality to a certain point, for example increase time-to-connect by like 5 minutes, indeed some users may find it not worthwhile. There are also social factors that influence circumvention tool use as times, like intimidation from the authorities.
17:17:18 * cohosh nods
17:18:16 <anadahz> I have a question about psix: How far in the past do the historical go?
17:18:20 <kmc> In the latest chapter of that, it seems like TM mostly or completely blocked major ports, like 22 and 53. Which is hard for any network traffic to contend with.
17:19:40 <kmc> @anadahz I think retention is set for 14d currently.
17:20:53 <cohosh> the paper says that psiphon shifted traffic to more resilient protocols when blocking occurred. we're planning on making some changes to tor browser to more automatically detect with transports will work
17:21:37 <cohosh> i'm curious about the advantages or disadvantages of different methods of deciding what works and what doesn't
17:22:02 <cohosh> like whether each individual client tries all of them, or if the decision is made based on larger trends in metrics from a specific region
17:22:47 <kmc> I think that would be a really positive development. Some of you may remember back in the day, Psiphon allowed users to manually select their transport mode between I think SSH, SSH+(OSSH), and VPN. Eventually we removed that function, believing that we shouldn't allow users to intentionally select a "worse" mode.
17:23:38 <kmc> And nowadays with a much larger arsenal of protocols, the network does a much more complete job of diagnosing which connections and servers will have the best performance, and making the right choice.
17:24:31 <kmc> (here's a snap I found of the old Windows UI: https://s3.amazonaws.com/0ubz-2q11-gi9y/image09.png)
17:24:33 <cohosh> we have tor-browser#40259 for a manual version of this
17:25:17 <cohosh> aha nice
17:25:41 <cohosh> for our transports, there doesn't seem to be a strictly linear placement of which protocol is better
17:26:06 <cohosh> mostly because obfs4 really depends on how good the region is at enumerating bridges
17:26:18 <cohosh> while meek mostly works but is overloaded and a bit slow
17:26:29 <cohosh> while private obfs4 bridges seem to work really well
17:26:31 <kmc> Both- there are a bunch of quick tests for RTT, liveness, and as well we can implement tactics on a regional basis informed by other knowledge we may have.
17:26:52 <cohosh> okay cool that's interesting
17:27:17 <cohosh> does implementing tactics require a software update, or can you do it live?
17:27:29 <cohosh> (feel free not to answer heh)
17:28:03 <kmc> There's much we can do from the server side without requiring client updates
17:28:07 <cohosh> i find this adaptability very cool
17:28:20 <cohosh> and it's something we'd like to make tor browser better at
17:30:11 <cohosh> back to the paper, a lot of our metrics don't have as a clean a pattern as dcf1 pointed out a bove
17:30:45 <cohosh> matt green pointed out recently on twitter our bridge connection metrics from china and iran
17:30:49 <kmc> Users will often be in the dark when something is not working or working poorly, and not necessarily able to make an informed choice as to what transport is optimal.
17:31:04 <dcf1> Tor graphs have the additional complication that for historical reasons, they split into bridge and non-bridge graphs
17:31:48 <dcf1> And because censors find non-bridge tor relatively easy to block, there will often be a pattern where non-bridge tor goes down (because it's being blocked) and bridges go up simultaneously (because people are starting to circuvment)
17:33:50 <kmc> It would be helpful to be able to look at direct connections and bridges on the same viz
17:34:13 <dcf1> kmc: I hacked up my own version of that because Tor Metrics doesn't have it
17:34:13 <cohosh> we also had this spike in bridge use in 2019 from iran: https://metrics.torproject.org/userstats-bridge-country.html?start=2019-10-23&end=2021-01-21&country=ir
17:34:17 <dcf1> https://people.torproject.org/~dcf/metrics-country.html
17:34:31 <dcf1> https://people.torproject.org/~dcf/metrics-country.html?country=ug
17:34:31 <cohosh> which i think we decided was because an existing app suddenly shipped with tor browser configured to use bridges?
17:35:09 <kmc> Another paper Simin and I worked on has an example of how the flip from direct connections to bridges corresponded to protocol changes on the Psiphon network (pg 14) https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3244046#
17:35:21 <dcf1> On correlating bridge and non-bridge users, Section 4.4 of this paper (which Keith's paper cites) has something about it: https://arxiv.org/abs/1507.05819
17:35:50 <dcf1> They have a mailing list with daily posts of anomalies in tor, but I don't know if anyone is monitoring it. http://lists.infolabe.net/archives/infolabe-anomalies/
17:36:34 <cohosh> ah cool, i didn't know about that until now heh
17:37:27 <anadahz> The mailist list posts daily Tor anomalies reports.
17:38:43 <anadahz> Every mail (report) includes also 3 PDF files with daily, weekly and monthly graphs.
17:39:53 <anadahz> You can also find all the archives on the link dcf1 mentioned: http://lists.infolabe.net/archives/infolabe-anomalies/
17:40:21 <kmc> As @cohosh and @dcf1 mentioned earlier about the less clean patterns in tor connection metrics, I think we talked about it in our presentation in relation to Joss's paper. The countries identified to be the most 'anomalous' aren't necessarily the most harshly censored regions, but either have a very low user base to begin with or just rather erratic usage patterns- eg. Moldova, Mongolia, Nepal, Senegal, Syria.
17:42:27 <cohosh> i wonder if psiphon's use as more of a vpn-style tool makes these patterns more apparent
17:43:12 <cohosh> like, orbot allows sending arbitrary apps over tor (as long as the apps can be configured to use a local proxy)
17:43:23 <kmc> I think it does have a much more clear-cut logic as to which protocols get applied. And the second benefit is often scale, as a snapshot of internet usage in a country is concerned.
17:43:38 <cohosh> but orbot oftem has different PTs than Tor Browser
17:47:33 <cohosh> kmc: thanks for joining the discussion
17:48:24 <cohosh> i am happy to be learning more from psiphon about how to respond to censorhsip events
17:48:25 <dcf1> yes, much appreciated
17:49:07 <kmc> Thanks a lot for the invite, and for all the thoughtful commentary!
17:49:26 <cohosh> i should head out soon, any last comments or discussion before we wrap up the reading group?
17:49:49 <kmc> It was suggested that we get together in the not so distant future for a more indepth discussion about metrics, I would be happy to do that sometime
17:49:58 <cohosh> yes that would be great!
17:50:03 <cohosh> i will follow up with you on that
17:50:14 <anadahz> I have a question not related to the reading group.
17:50:21 <kmc> Cool, sounds great.
17:50:38 <anadahz> Where/how one can report a Tor censorship event?
17:50:38 <cohosh> anadahz: go for it, i think we're pretty much done
17:51:10 * cohosh searches for link
17:51:24 <kmc> ^ same
17:51:25 <cohosh> https://gitlab.torproject.org/tpo/metrics/timeline
17:51:47 <cohosh> this is for reporting events that impact tor metrics
17:52:18 <cohosh> (it's also linked to at the bottom of the page on https://metrics.torproject.org/userstats-relay-country.html
17:52:39 <dcf1> trac used to have a "censorship analysis" label for tickets, but I don't know if there's anything for gitlab now
17:52:44 <anadahz> What if the event has no impact to Tor metrics?
17:52:50 <cohosh> and they are displayed along with metrics graphs based on the time frame selected
17:52:58 <kmc> I remember the thing that was on trac
17:53:13 <kmc> It looked similar to this
17:53:36 <dcf1> apparently we have https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues
17:53:44 <cohosh> ah yup
17:54:18 <cohosh> hmm i'll make a note to clean that up a bit
17:54:32 <anadahz> (perhaps this info is a good candidate for the anti-censorship wiki page)
17:54:33 <cohosh> i don't think it's been looked at much since the trac migration
17:55:01 <anadahz> thx for the info
17:55:34 <cohosh> anadahz: thanks!
17:55:50 <cohosh> okay i'll end the meeting here, thanks for joining everyone!
17:55:54 <cohosh> #endmeeting