16:00:14 #startmeeting anti-censorship meeting 16:00:14 Meeting started Thu Oct 21 16:00:14 2021 UTC. The chair is cohosh. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:14 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:00:29 welcome and here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 16:00:32 hello 16:00:45 * anadahz around 16:00:55 o/ 16:01:21 First agenda item is just a follow-up from last week on broker domain names 16:01:44 the code has been merged, i haven't deployed it yet 16:01:45 Those got merged in snowflake and snowflake-webext 16:01:58 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/59 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/merge_requests/22 16:02:10 nice 16:02:29 oh, haven't noticed https://gitlab.torproject.org/torproject-pusher before 16:03:38 yea i'm not quite sure how it works but it shows up whenever i merge from the command line 16:03:48 it syncs from gitolite to gitlab 16:04:02 so when you push to git-rw.torproject.org it shows up on gitlab right after 16:04:11 I see, thanks 16:05:34 the next item is about a bridge campaign 16:05:35 Regarding "Run a Bridge", https://gitlab.torproject.org/tpo/community/relays/-/issues/24 16:05:55 hey! o/ 16:06:01 One positive outcome of such a campaign would be to encourage people to join discussion groups and support one another in bridge operation 16:06:14 e.g. tor-relays or another forum 16:06:46 yeah, and in november forum.torproject.net will be official 16:06:54 oh great 16:07:05 :D 16:07:49 also, i know this goal for snowflakes comes from a grant, but we have already met it 16:07:58 we're at > 12,000 unique snowflake ips 16:08:04 i'm still looking my calendar to find a date to start the campaign 16:08:06 (/day) 16:08:08 woah!!! 16:08:26 what is the status of non-nat snowflake bridges? do we have enough for now? 16:08:54 is the campain to focus on those? 16:09:07 whoa 16:09:08 well, we could. 16:09:11 congratulations 16:09:31 meskio: from the prometheus metrics it looks like we're doing okay 16:09:33 ggus: Is there any specific requirement for bridges? 16:09:51 To put it differently what kind of bridges would you like to have? 16:09:54 anadahz: i believe they need to be 'obfs4' bridges 16:10:03 we have many more idle snowflakes for clients with restrictive NATs than denials 16:10:32 Does it make sense to ask people to prioritize and use port 80 and 443? 16:10:48 (on their bridge config) 16:10:52 cohosh: nice, looks pretty healthy :) 16:11:56 clients with symmetric NATs do still get denied sometimes but it's probably only takes 1-2 tries to get a proxy 16:12:32 so it would be nice to have more :) 16:13:07 yes, will be nice if people that runs bridges is conscious that we also need standalone snowflake proxies, that the browser plugin is not enough 16:13:31 ggus: is there anything else we can do to help you plan for this? 16:13:37 meskio: should we reward standalone snowflake proxies? 16:13:57 that will be nice 16:14:06 but I don't think those report their email address or uptime 16:14:18 maybe is something to add into the roadmap to implement 16:14:24 cohosh: i'm planning to write a blog post for the campaign. i'll try to find a volunteer to do the social media banner design 16:14:47 cohosh: i will need help to track the new bridges and to test them 16:17:21 I missed the Snowflake presentation from PTIM yesterday. Was there anything shared that's necessary to know now? 16:17:23 hrm, i think we shouldn't add features that are only useful for campaigns 16:17:50 especially since we have already been successful in getting lots of snowflakes 16:18:27 dcf1: not really, the main takeaway was that calyx ran their own snowflake proxy campaign and got (i think ~50?) people to install the extension 16:18:42 cohosh: yes, I understand, keep it simple 16:18:48 ok, thanks 16:19:40 someone asked in that session whether their campaign would have been successful had they not incentivized it with tshirts 16:20:23 What's the secret of our success in recruiting proxies so far? Conference talks and goodwill? 16:20:23 and i thought it was kind of funny to ask since we have > 12,000 people running proxies with very few getting tshirts afaik 16:20:35 Social media promotion? 16:20:44 i also thought about asking vouchers for some ISPs. but i don't know if that's a good idea or people tried before. 16:20:49 I know comms team has been helping. 16:20:52 ggus has done a lot of social media promotion 16:21:20 and also jacobo in mexico 16:21:27 that's right 16:21:37 i don't think we have a good idea of how many proxies come from which outreach 16:22:43 Referring to the interesting links, in discussion with Brandon Wiley at PTIM, I learned of these proposals that are candidates for future standardization: 16:22:50 https://github.com/Pluggable-Transports/Pluggable-Transports-spec/blob/70bc1c5115639411cf05eec300c52645c174312b/proposals/ 16:23:20 Among them is a proposal for the EVENT message by dgoulet and ahf: https://github.com/Pluggable-Transports/Pluggable-Transports-spec/blob/70bc1c5115639411cf05eec300c52645c174312b/proposals/0004-ClientEventMessage.pdf 16:23:50 (3 years old...) 16:24:01 I informed that EVENT has been superseded in Tor's spec by STATUS, and it sounded like Brandon and other people with the PT spec were going to check on getting in touch and updating their proposal 16:24:01 good we didn't block the deliverables back then on that getting approved lol 16:24:19 cool! 16:24:22 yeah 16:24:23 is this similar to the STATUS message? 16:24:40 EVENT was the original design sketch for what later become STATUS 16:25:05 https://gitlab.torproject.org/tpo/core/tor/-/issues/28181 16:26:05 cohosh: i will update the ticket with a date for the campaign. i'm planning to close the campaign one week after the cybermonday. 16:26:17 There is also a proposal related to logging, though from my reading it serves a different purpose: it is more about standardizing an API and info/warning/debug/etc. log levels. 16:26:40 maybe mentioning to Dr. Wiley that we now have a use-case for STATUS as well to add the version feedback mechanism back to the host process 16:26:42 ggus: meskio: awesome! maybe we can chat in irc about how to validate the running of standalone proxies 16:27:00 it would be cool if there's a way to do it that fits with snowflake's current setup 16:27:00 The version= use case for STATUS came up in the discussion at the meeting 16:27:19 That's all I had on that topic 16:27:48 for the webextension, we were asking people to share a screenshot 16:27:50 but i'm also okay if it's not 100% catching people who just want tshirts, that is hopefully the minority of people participating? 16:27:52 heh :) 16:28:17 it should be snow-related merch 16:28:17 we could ask the same for the proxy, something showing that the process is being running for some time 16:28:20 ski jackets 16:28:26 XD 16:28:42 touques 16:28:58 +1 16:29:22 dcf1: ahf: i am curious what you thought about the criticisms of having a single library API/spec that came up during the meeting 16:29:48 that not all PTs have to have the same interface (especially when it comes to Go libraries) 16:30:07 sorry more for dcf1 than ahf i guess since tor definitely needs to have a defined spec 16:30:11 at least at the moment 16:30:17 I don't know, my impression is that the spec is working against a lot of inertia 16:30:28 i don't know what the criticism is. was not in the meeting 16:30:53 People seem to have mostly settled on code sharing/forking and seem pretty happy with it. whether or not it follows the spec to the letter. 16:32:44 dcf1: yeah, so it's more like the library spec has been a suggestion or guidance on how to make your PT easily called as a library 16:33:45 at some point when we do PT's for Arti, i think we should take a bit of a brutal look of how the interaction between the host and its PT can be made better, but in a way such that we can still execute PT processes, but also load them as libraries. i think static libraries are the most interesting though since most of the integration work is hard for mobile integrators 16:34:28 ahf: yea it would be good to look at how this PTv2 library spec has played out in the space when those discussions come up 16:34:34 ye 16:34:58 to summarize, someone made a comment on how it might not be necessary or desired for all PTs to have the same library API 16:35:05 it wasn't a long discussion as i remember it 16:37:02 yeah 16:37:35 okay i'm getting distracted by PTIM again XD 16:37:40 anything else for today? 16:38:17 is all for me, I'm also intersted on the cuban talk in PTIM 16:38:20 are people unhappy with Tor not supporting the new PT spec stuff or does it not matter much? 16:38:48 oh idk, i haven't heard anything specific 16:39:03 I think they care more about being able to use PTs in their tools than producing PTs for Tor 16:39:05 the PT spec stuff is more relevant for the transport side of things rather than the tor side of things 16:39:05 ok good good 16:39:10 they => people at PTIM 16:39:19 ahf: ppl do care about Tor supporting the new PT spec 16:39:30 anadahz: how so? 16:39:42 anadahz: as in they are unhappy with us being in sort of a strange intermediate step between v1 and v2? 16:39:47 afaik the v2 inter-process spec is pretty similar to tor's spec 16:40:04 but it uses JSON and we have moved to our own K/V thing iirc 16:41:07 ah 16:41:58 cohosh, ahf in general there is a "voluntarily" discussion for PTs to support/review/update the PT spec. If there are things that you don't like or should be changed we should try to fix that. 16:42:52 anadahz: but dude, in this meeting we have just talked about how a spec that was proposed in late 2018 is now being discussed. i have no time for that kind of timeline :-S 16:44:14 ahf: No worries, sorry I wasn't there in 2018.. catching up. 16:44:29 no worries, is good people are looking into this 16:46:04 That's all for today, sounds like? 16:46:09 yeah i'll end it here 16:46:15 thanks everyone 16:46:17 #endmeeting