16:00:13 <shelikhoo> #startmeeting tor anti-censorship meeting 16:00:13 <shelikhoo> here is our meeting pad: https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469 16:00:13 <shelikhoo> editable link available on request 16:00:13 <MeetBot> Meeting started Thu Aug 22 16:00:13 2024 UTC. The chair is shelikhoo. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:13 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 16:00:16 <shelikhoo> hi! 16:00:46 <meskio> hellohello 16:02:18 <meskio> dcf1: congrats for the presentation in usenix, I hear it was really good, I hope the video gets released 16:02:44 <onyinyang> hihi sorry got a bit distracted 16:02:45 <dcf1> thanks. I will update the bbs thread and tor forum thread when there's a video. 16:02:51 <onyinyang> also congrats dcf1 16:03:01 <meskio> nice 16:03:16 <shelikhoo> congrats dcf1! 16:03:45 <theodorsm> congrats! 16:06:02 <shelikhoo> okay. let's start today's meeting 16:06:19 <shelikhoo> the first topic is: 16:06:20 <shelikhoo> - Snowflake debian package is outdated: 16:06:20 <shelikhoo> - Is there a plan for updates? If AC-Team wants to increase the number of snowflake standalone proxies, we need to maintain deb packages. Should we start a call for maintainers? If so, what are the requirements? 16:06:20 <shelikhoo> - MR: https://gitlab.torproject.org/tpo/web/community/-/merge_requests/386/diffs Please note that every new string added to the community portal is localized. If this is a temporary issue, I don't think it worth merging it. (gus) 16:06:47 <meskio> I think ggus added it but is not around today 16:07:14 <shelikhoo> yes, that being said the topic was quite self-explanatory 16:07:15 <meskio> anyway, yes the snowflake package in debian is pretty outdated and I have being failing to find the time and motivation to update it 16:07:55 <shelikhoo> I think this is one of the issue with debian: old package 16:07:59 <meskio> we are starting soon P146 where we plan to work on snowflake and one of the deliverables is to improve our packaging of snowflake 16:08:14 <shelikhoo> I think we should consider make generating debian package automated 16:08:19 <meskio> so the answer is yes, we do plan to work on this, but maybe not very soon 16:09:06 <shelikhoo> This would be the same as the general direction of making everything automated 16:09:11 <meskio> I'm not sure what to recommend for the community portal, but I'll write there saying that we do plan to update it but will take some months 16:09:53 <meskio> there are some manual steps always to publish into debian, but I guess we could automate most of it 16:10:18 <meskio> I've being maintaining this package, but I'm not that skilled on packaging for debian 16:10:27 <WofWca[m]> It's worth to mention that it's apparently not just outdated but non-functional due to incompatibility with other components. 16:10:30 <meskio> and I wish someone else that knows better can take over 16:11:02 <WofWca[m]> *components of Snowflake 16:11:08 <meskio> WofWca[m]: I see, that is sad 16:11:10 <shelikhoo> A think a easier way would be just package the binary in debian with an self-hosted repo 16:11:36 <meskio> yes, we have deb.torproject.org we can try to get this package pushed there as part of P146 16:12:15 <shelikhoo> the debian moderation standard is quite time consuming, if we couldn't meet its demand in a timely manner, we should find another way 16:12:17 <shelikhoo> yes 16:12:30 <shelikhoo> anything more on this topic? 16:12:48 <meskio> not from me 16:13:07 <shelikhoo> https://github.com/eyedeekay/blizzard/ "Blizzard: The I2P Snowflake donor Plugin" 16:13:07 <shelikhoo> should we ask them to use a diferent identifier than "standalone" to find them in the stats? 16:13:51 <meskio> that was me 16:14:00 <meskio> this is an IsP snowflake proxy 16:14:06 <meskio> based on our proxy library 16:14:10 <meskio> we mentioned it last week 16:14:26 <meskio> they are not changing the name, so AFAIK in our stats will appear as standalone 16:14:47 <meskio> I wonder if we should poke them to use a different name so we can see them in the metrics 16:14:59 <shelikhoo> yeah, personally I love it. I just hope they can update their package when we do 16:15:04 <meskio> do I recall correctly that there is an easy way to change that name? 16:16:00 <dcf1> Isn't there a change required on the Tor Metrics side as well, to add a new recognized proxy type? At least I thought there was some kind of "whitelist" of known names and names not on the list become unrecognized. 16:16:23 <meskio> mmm, that rings a bell 16:16:24 <cohosh> the broker does some validation for sure 16:16:38 <dcf1> That's it, it needs a coordinated change in the broker 16:16:40 <shelikhoo> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/proxy/lib/snowflake.go?ref_type=heads 16:17:01 <meskio> I wonder if is worth it here, not sure how many contributors will bring 16:17:02 <cohosh> shelikhoo: you beat me to it :D 16:17:17 <shelikhoo> I think we just need to change the value here, plus add the name to the allow list 16:17:42 <shelikhoo> then it should be fine, that being said, I don't think this value can be set via command line 16:17:47 <cohosh> well it's not the worst thing to have them counted as unknown, which is what will happen if they specify a name we don't recognize 16:17:50 <hiro> uhm I do not think we use proxy types... 16:17:53 <dcf1> I documented a history of how there was a time where we were missing "iptproxy" labels because the broker hadn't redeployed yet 16:17:56 <dcf1> https://github.com/turfed/snowflake-paper/blob/98cf35650ef8d9021b4f1fda1adb56ba61d2891a/figures/proxies/proxy-type.r#L17 16:18:13 <meskio> hiro: we do in grafana 16:18:17 <dcf1> hiro: you're right, I was mistaken, it is not Tor Metrics that needs a change, but the Snowflake broker. 16:18:28 <hiro> ah ok so you meant your metrics 16:18:38 <hiro> xD 16:18:54 <cohosh> shelikhoo: it can be set in the SnowflakeProxy struct which is what they're using 16:19:06 <cohosh> https://github.com/eyedeekay/blizzard/blob/9123dd706cc0a1e3b0d64ffcb5199ad67d216d8a/main.go#L39 16:19:28 <shelikhoo> cohosh: yes! I didn't read their source.. 16:19:45 <shelikhoo> it seems they are already compiling it on their own 16:19:49 <meskio> ok, then I'll open an issue on their side to ask them to set a different name 16:19:52 <dcf1> "After [2020-12-03], attribute unknown proxy types until 2022-06-21 to iptproxy. IPtProxy reported its type as "iptproxy", but this value was not recognized by the broker until the deployment of 2022-06-21." 16:19:59 <meskio> and we'll see about the update on the broker side 16:20:04 <cohosh> sounds good 16:20:14 <shelikhoo> so we just need to add a new name to broker allow list 16:20:17 <shelikhoo> nice! 16:20:32 <meskio> cool, I'll inform on whatever they said 16:21:05 <shelikhoo> anything more on this topic? 16:21:17 <meskio> nop 16:21:17 <shelikhoo> archive https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-mobile 16:21:18 <dcf1> var KnownProxyTypes = map[string]bool 16:21:21 <dcf1> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/b73add155074657cb763fcf12a3f7d2e9e22316d/common/messages/proxy.go#L19 16:21:50 <shelikhoo> yes, here is the list of proxy that are known and accepted 16:22:01 <shelikhoo> yes, here is the list of proxy type that are known and accepted 16:22:47 <meskio> I have archived snowflake-mobile repo, it has being updated for 3 years, not sure if it has ever being used, let me know if I should revert the archival 16:23:27 <cohosh> thanks, that was a good call 16:23:42 <shelikhoo> I think it is the right decision, we don't have too much time in working on it, and tools like orbot already have similar features 16:23:59 <shelikhoo> anythig more on this topic? 16:24:07 <meskio> not from me 16:24:16 <shelikhoo> PT binary size updates 16:24:16 <shelikhoo> https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42607 16:24:16 <shelikhoo> Remove conjure from android as a last resort 16:24:36 <shelikhoo> okay, it seems there is another squeeze of bytes 16:25:30 <cohosh> yeah, we've been trying a few things but none of them have had a good effort to results ratio 16:25:57 <shelikhoo> both Google and Apple impose some kind of size limit on some size 16:26:27 <shelikhoo> as a result, we are keep spending time on subsiding them 16:26:40 <cohosh> i offered the option of just removing conjure from android versions 16:26:51 <cohosh> we still have a few tricks up our sleeve but they require some time 16:27:22 <cohosh> conjure is pretty minimally supported by us anyway so i don't think we will lose a lot there 16:27:49 <cohosh> here is its recent usage: https://metrics.torproject.org/rs.html#details/A84C946BF4E14E63A3C92E140532A4594F2C24CD 16:28:07 <meskio> I agree, is ok to remove conjure for now in android 16:28:14 <shelikhoo> I think Google was trying to push https://developer.android.com/guide/app-bundle 16:29:21 <shelikhoo> It is a way to split app in to many chunks, and let google serve them 16:29:46 <shelikhoo> the downside is they are requiring app developers to surrender apk signing keys 16:30:36 <cohosh> shelikhoo: hm, might be worth mentioning on the issue 16:30:44 <cohosh> this one: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42607 16:31:03 <cohosh> but yeah i suspect the signing keys thing will be a dealbreaker 16:32:53 <shelikhoo> yeah, I think eventually distribution over play store would be discontinued 16:32:58 <shelikhoo> but anyway 16:33:09 <shelikhoo> anything more on this topic? 16:34:17 <cohosh> nope 16:35:03 <shelikhoo> Manifest V3 Deployment pending, will proceed on next week 16:35:30 <shelikhoo> the last discussion topic: I plan to deploy manifest v3 on chrome next week 16:35:44 <cohosh> that's great :) 16:35:44 <shelikhoo> should we delay it, or we should go ahead 16:36:09 <shelikhoo> this would be the last step in throwing away the ticking bomb! 16:36:27 <cohosh> i think it's a good idea to go ahead with it. It is definitely functional in its current state 16:36:34 <WofWca[m]> shelikhoo: FYI CWS has a phased rollout feature, i.e. you can roll our the release to only a certain percentage of users. 16:36:42 <meskio> yeah!!! 16:36:50 <shelikhoo> I will try to prepare for it on Monday, and hit the big button on Tuesday 16:36:59 <meskio> :) 16:37:05 <cohosh> i didn't know about the rollout WofWca[m] that's a good tip 16:37:26 <shelikhoo> yes, we could do it, but anyway we just need to watch out for complaints 16:37:32 <shelikhoo> or feedbacks 16:37:35 <cohosh> the main missing part is getting the popup to turn green when there's a user right? 16:37:56 <cohosh> i think we have the error messages propagating 16:38:06 <shelikhoo> the missing part is when there is an error there is no detailed error reason 16:38:16 <shelikhoo> and there is user count display 16:38:18 <cohosh> oh i see 16:38:30 <cohosh> that's right 16:38:37 <shelikhoo> right now the only error supported is the consent error 16:38:45 <cohosh> i still think it's worth it to deploy since we're past the deadline 16:38:47 <shelikhoo> any other error is not yet shown to the user 16:38:49 <shelikhoo> yes 16:39:29 <shelikhoo> okay, let's move to the next thing: discussion group on the paper 16:39:30 <shelikhoo> Bridging Barriers: A Survey of Challenges and Priorities in the Censorship Circumvention Landscape 16:39:46 <shelikhoo> https://www.usenix.org/conference/usenixsecurity24/presentation/xue-bridging 16:40:45 <meskio> I can try to produce an introduction to the paper 16:40:56 <shelikhoo> yes, please@ 16:40:57 <shelikhoo> ! 16:41:12 <meskio> the researchers have done interviews to users and providers of Circumvention Technologies (CT) 16:41:39 <meskio> looking on how their expectations and use differs 16:42:54 <meskio> they have look into the motivation to use them, the bootstrap/discover and the usage 16:43:23 <meskio> not sure what else to add to the summary 16:43:47 <dcf1> I wonder if we have any authors here? They said they might be. 16:43:50 <shelikhoo> thanks! 16:44:19 <dcf1> Yes it's very interesting that this study looks at two sides: the providers and the users. 16:44:26 <shelikhoo> thanks for the summary from meskio, I think we can start the first discussion topic about this paper 16:44:29 <shelikhoo> What aspects of the paper are questionable? 16:44:36 <theodorsm> I found it a bit too focused on VPNs, but some good points about how people in censored areas learn about CTs and people are making money on selling that information. 16:44:53 <shelikhoo> they also interviewed anti-censorship tool developers as well 16:45:22 <meskio> theodorsm: yes, at the same time users do mention their need for privacy and they do point towards Tor there 16:45:36 <dcf1> The "VPN" terminology question is tricky, a lot of people don't know the difference, as they say in a footnote on page 7. "Surveyed users often used the two terms interchangeably." 16:46:15 <dcf1> Tor itself is engaging with with such a problem with the name of Tor VPN, if I am not mistaken. 16:46:36 <meskio> I see two interesting places where users and providers have different perspective: 16:47:03 <shelikhoo> I think for non-tech users application layer proxy, transport layer proxy and packet layer proxy isn't that difference if they serve the same purpose 16:47:08 <meskio> 1. on the motivations users mention people not caring about bypassing censorship, while providers talk about people not knowing about censorship 16:47:46 <shelikhoo> my complaints is that when they asked for what assistance would be appreciated, they didn't mention assistance from who 16:47:56 <meskio> 2. on the trust users mention the need for privacy and anonymity while providers talk on how it is not so important 16:48:24 <shelikhoo> I assume it is just about assistance from academic community, but may there are most to ask for other part of society 16:48:52 <cohosh> the trust discussion was interesting to me too 16:49:11 <meskio> I agree, it shows how Tor is valuable there :) 16:49:41 <dcf1> good observation meskio. "there's so much distrust and snitching going on that unfortunately I just can’t trust anyone." (U14) 16:50:05 <cohosh> yeah, i was going to say that Tor helps for sure, since we can't see what users are accessing through our tools, but there is some non-neglible trust in the sense that we do see their IP addresses, being the first hop 16:50:10 <theodorsm> How does Tor collaborate with organzations such as Amnesty, could they for example also educate people who need CTs and anonymity? 16:50:39 <shelikhoo> yeah, the "airport" space is quite... contested... especially when both provider and user can land in prison 16:50:48 <cohosh> some ac tools and bootstrapping requires accessing servers run by tor the org/community, some bridges run by volunteers we don't know 16:51:22 <shelikhoo> (we are now also discussing: 16:51:22 <shelikhoo> Are there immediate actions we can take based on this work? 16:51:22 <shelikhoo> Are there long-term actions we can take based on this work?) 16:52:07 <meskio> I guess those questions are related to what cohosh is saying 16:52:18 <dcf1> Section 6 is about future priorities and challenges, maybe we can discuss how much we vibe with those 16:52:27 <meskio> users do put some trust on those bridges 16:52:47 <cohosh> i would be curious to know a bit more about the privacy risks users are worried about: is it mostly what they are visiting, or whether they are using the tools 16:53:19 <meskio> in section 6 they talk about "streamlining the bootstraping and server rotation process" wich connects a lot with the work we want to do with signaling channels library 16:53:23 <shelikhoo> I think one of the issue is that they do wish to use these AC-tool to do what normal netizen do 16:53:26 <dcf1> * Bootstrapping Challenges 16:53:26 <dcf1> * Outreach & Feedback Channels 16:53:26 <dcf1> * Flexible Funding 16:53:26 <dcf1> * Academic Priorities vs. On-the-ground Needs 16:53:26 <dcf1> * User Education 16:53:29 <dcf1> * Collaboration & Community 16:53:34 <onyinyang> in section 6 they mention faster turn around time for surge and sustain funding but this also likely implies an over reliance on known and established entities and funding directed only to them 16:53:47 <shelikhoo> I often hear user discussing how to get their proxy to work with ChatGPT 16:53:55 <shelikhoo> Netflix 16:54:02 <dcf1> shelikhoo: that's interesting 16:54:06 <shelikhoo> register account at Google... 16:54:10 <onyinyang> so there's kind of an inherent friction between having this kind of funding available and creating more dynamic CT approaches. . .maybe? 16:54:20 <dcf1> "Private grants or donations could serve as viable alternative funding avenues." any ideas about that? 16:54:52 <shelikhoo> So, as Tor, if we wants to attract more user, we need to make Tor (exit) more useful when it comes to actually accessing website and services 16:55:18 <dcf1> I do appreciate the discussion of existing funding channels creating an unintentional and undesirable competition between CT providers. 16:55:35 <dcf1> '"we are in this together" mindset' 16:55:45 <shelikhoo> and let's say Edit Wiki, Register Account without phone number, and Access ChatGPT 16:55:50 <dcf1> This is related to my own frustration with research groups not talking to one another, perhaps. 16:56:15 <onyinyang> yes, that is something that frustrates me too dcf1 16:56:20 <onyinyang> and a lot of people in the community 16:56:33 <dcf1> theodorsm: I don't know the answer to your question about Amnesty etc. OONI does some outreach and training, I'm not sure about others. 16:56:47 <shelikhoo> Just let you know these "airport"s frequently DDoS each other 16:56:48 <meskio> yes, I see there is some collavoration for funding, we do have grants together with other parties, but maybe something to improve more 16:57:37 <shelikhoo> and they also have alliance with public announcement channel to punish "airport" they don't like 16:57:59 <shelikhoo> "unless you change your course you will be DDoSed" 16:58:02 <shelikhoo> something like that 16:58:04 <meskio> theodorsm: no idea about amnesty, we'll need to ask ggus about it, I know we do colavorate with other outreach organizations 16:59:02 <shelikhoo> Is there future work that we want to call out in hopes that others will pick it up? 16:59:10 <shelikhoo> okay the last minute! 16:59:18 <shelikhoo> let's chat about future works 16:59:58 <meskio> I think their future priorities are good, I personally care more about the bootstrapping challenges and the academic priorities, as it touches my work more closely 17:00:21 <dcf1> meskio: +1 17:00:42 <shelikhoo> I will keep the meeting open for 3 minutes to have everyone's voice remembered, but to avoid overtime the meeting is officially ended! Thanks everyone! 17:01:14 <cohosh> "“the more 17:01:15 <dcf1> The questions about how users go from zero to somehow bootstrapping into a CT is maybe the most groundbreaking part of this survey. 17:01:16 <cohosh> steps you have, the fewer people can do" 17:01:34 <cohosh> obfs4 requires quite a few steps, some with trial and error 17:01:37 <dcf1> cohosh: thank you for your advocacy of publishing in HTML and not PDF :) 17:01:46 <cohosh> hahaha 17:02:07 <shelikhoo> I think in general that the first step will be assisted by friends 17:02:10 <shelikhoo> in person 17:02:29 <shelikhoo> especially for those without the skills 17:02:30 <dcf1> it's quite true, though in Tor and probably elsewhere we have been making progress, with moat, connection assist 17:02:58 <cohosh> that's right we do have a more automated way of getting obfs4 bridges now :) 17:03:02 <shelikhoo> that being said, a lot of clients are quite easy to use, with an subscription link, the rest will be taken care of bv the client 17:03:18 <dcf1> shelikhoo: so do you believe it starts with a lower level of awareness-building? 17:03:50 <shelikhoo> dcf1: yes, I think the user need to be aware of the wall, and then be shown the value of bypassing it 17:04:41 <shelikhoo> many users I know are there to access tools or information they know they couldn't get inside the wall, such as the update on their favorite singer's social media account, or ChatGPT 17:05:27 <dcf1> Yes, I guess ChatGPT would be an example of the kind of sudden "crisis" like Molly Roberts et al. talk about, where there is something people want to access that there is no ready replacement for. 17:05:36 <shelikhoo> I will end the meeting here to put an end to over time, but feel free to keep chatting! 17:05:43 <shelikhoo> #endmeeting