15:57:32 #startmeeting tor anti-censorship meeting 15:57:32 Meeting started Thu Feb 29 15:57:32 2024 UTC. The chair is meskio. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:57:32 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:57:36 hello everybody!!! 15:57:39 here is our meeting pad: https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469 15:57:39 hi! 15:57:41 ask me in private to give you the link of the pad to be able to edit it if you don't have it 15:57:43 I'll wait few minutes for everybody to add you've been working on and put items on the agenda 15:58:14 interesting pad number, i wonder how that is generated ;) 15:58:53 ah sorry, I thought I was facilitating this week and changed some things in the pad 15:59:33 onyinyang: ahh, that makes sense 15:59:39 I saw my name nad I thought was my turn 15:59:41 sorry 15:59:45 no problem 15:59:47 I can put you for next week 15:59:51 sounds good :) 16:00:12 anarcat: this is what you get when you put a pad private 16:00:50 ooh, readonly, interesting! 16:00:56 nice, thanks! 16:01:19 Oh no... 16:01:38 It is probably me put meskio's name last week 16:01:50 anarcat: yes, we get often trolls deleting the pad 16:02:56 and I am not really following an exact rule when it comes to nominating that 16:03:54 I think you did right, onyinyang updated it and I jump after that :) 16:04:17 anyway, let's start 16:04:30 anything to note on the recent elections? 16:04:45 I saw there has being blockades in nigeria and chad 16:05:28 the first discussion point: 16:05:30 Mysterious reported snowflake issue in China has maybe gone away as of 2024-02-26 16:05:38 Mysterious reported snowflake issue in China has maybe gone away as of 2024-02-26 16:05:49 The user who originally reported it, snowflake had not worked for them for a month 16:06:10 They now say that it was started working again, but just barely, worse than meek they say 16:06:10 https://github.com/net4people/bbs/issues/325#issuecomment-1963226429 16:06:30 Nigeria is questionable. There are nationwide union protests going on, but it seems like outages might have been in only a few regions. It's hard to say if it was a shutdown or any number of other things. 16:06:36 Last time we discussed this, we discovered some correlation with 10% bootstrap bridge test restults from china, but we have not gotten to the bottom of it 16:07:21 I rebased my https://gitlab.torproject.org/dcf/snowflake/-/commits/handshake-padding branch and sent that, but it's unclear if it had an effect because it was after it had already started kind-of working again 16:07:55 I don't know what further to do. Just FYI. I do have another round of log files from a user if you want to examine them. 16:08:11 I think snowflake is working unreliably for sure, and last time it looks like either ip is in accessible, or dtls handshake couldn't finish 16:08:53 but since the remote end isn't directly controlled by us, it is unsure how it is actually block 16:09:05 The last round of logs for sure showed DTLS data channel transfer (got past the handshake), but the connections did not live very long 16:10:57 more packet loss maybe 16:11:17 the thing we could do include use another broker to see if the connection is blocked by protocol 16:11:44 and send/replay udp packets with limited ttl to see where it got dropped 16:12:25 both of them requires some time investment 16:12:46 I have definitely gotten contradictory reports though, another tester in China reported to me they had no problems with Snowflake 16:13:10 So just fyi I guess, I don't know what more to do, other than as shelikhoo says, do some dedicated tests from a vantage point 16:14:45 if we can't see the problem from a vantage point it might be hard to debug it by asking people to try things 16:15:54 https://gitlab.torproject.org/tpo/anti-censorship/connectivity-measurement/bridgestatus/-/blob/dc663e36d7dc81467a63f59c5d435b9f93e9e3ab/recentResult_cnnext#L89 16:15:58 Don't worry we can 16:16:25 :) 16:16:25 it seems snowflake in our vantage point are not always able to bootstrap 16:16:43 some time ago, all attempts are failed 16:17:17 and in more recent tests, there are some connection via snowflake that were successful 16:19:12 Can you identify a threshold where there was a change? was it 2024-02-26? 16:20:02 It should be possible in theory, but it will need some time 16:20:13 so I don't have it now 16:20:30 on a fast look 2024-02-23 was also failing 16:20:42 That's fair. We of course need to prioritize. 2 users on BBS reported something similar, but that's all I've heard. 16:21:24 shelikhoo: what do you think? is it worhit investigate? do you have time for this? or let's keep with other things and look at this in the future if it keeps happening? 16:22:35 meskio: I wish to investigate it, and it will be an background task to work on 16:23:02 and other tasks with firm deadline will take precedence 16:23:09 sounds good, can you open an issue for that? or we could reuse a previous issue, but maybe is too noisy? 16:24:15 Yes, I think I could just open a new ticket 16:24:25 the old ones are quite noisy already 16:24:39 dcf1: that reminds me the unrliable networks work in snowflake was waiting for your review: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/219 16:24:56 this will not solve the bootstrap, but might improve the speed... 16:25:44 I know, I am sorry about not reviewing that yet. 16:26:11 don't worry, I understan that things take time, I'm just checking you didn't forget :) 16:26:35 don't worry I have other on going tasks as well.., and was not blocked by the review 16:26:56 should we move to the next topic? 16:27:25 eof from me on this topic 16:27:33 go ahead 16:27:46 Unclear whether AWS will allow public disclosure of credentials 16:27:48 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40337 16:27:54 cohosh: ?? 16:28:34 I think correctly scoped token is supposed to be public 16:28:49 yes apparently aws has a way to scrape github repos for iam keys, which we have disclosed itnentionally 16:29:28 and they caught us doing that from mpu's bbs post: https://github.com/net4people/bbs/issues/335 16:29:41 I recall reading that github has some service doing that 16:29:52 the problem is that unless we convince them that our use-case is valid, they'll suspend my aws root account 16:30:28 so far i've only managed to convince the front line support person that this disclosure was intentional 16:31:12 they keep saying it's against the terms of service to make it public 16:31:18 is there any technological means we could do to avoid being cancelled by aws? 16:31:32 let's say base64 encode it? 16:31:39 right now i'm waiting for someone else to take a look at the support case and decide if an exception can be made 16:32:14 shelikhoo: yeah that was my thought too, it might be worth trying 16:32:24 :D 16:32:48 i think they also have some anomaly detection in place though, and will notice if many different IPs are using the same key 16:33:03 because that was part of the back-and-forth process 16:33:17 they told me how many different IPs had accessed it and asked if i was using a VPN 16:34:06 the funny thing is, they automatically apply a "quarantine" policy to leaked credentials, but the quarantine policy is less restrictive than the policy that was already applied to these 16:34:32 haha 16:34:47 XD 16:34:51 anyway, hopefully this rendezvous method isn't immediately killed by a ToS 16:35:02 I have some friends in AWS, I'll ask to see if I can get some inside on this 16:35:13 hshaha, I think it designed to "quarantine" unintentional leaks 16:35:44 I might need some help to be able to form a coherent question, as I'm not sure I understand what we are doing there 16:36:09 meskio: okay cool :) it's worth trying 16:36:21 the main challenge so far is convincing people that i really did mean to do this 16:36:25 we live in a world even view source may break law, so using service in an unintended way is always going to be challenging 16:36:56 cohosh, do you think aws' ToS would have a reason not to support this usecase and they just never considered it might be used like this? 16:37:36 onyinyang: it's possible they will dislike our usage for the same reason cloud providers dislike domain fronting 16:37:38 bringing back dcf1 talk, I wonder if we end up playing an arm's race with the cloud providers 16:37:56 yeah, that's what I'm wondering 16:38:07 but i don't think we're getting that pushback yet 16:38:23 so far it's just them worried that we're leaking root passwords or accidentally sharing credentials 16:38:38 and it's against their ToS to not properly secure your account 16:39:07 meskio: lol yes 16:39:30 they say credit check is to protect people from taking too much debt... 16:39:58 so it is more likely AWS just wish to protect themselves in reality 16:40:08 but a decision to not allow this may not give us more information on the reasons that they actually don't want us to do this. It could be stated as a "just following orders" rather than, we're opposed to you doing this for x reasons. 16:40:30 sure, in the end they will do what is best and less risk for them 16:40:31 or "result from AI" 16:40:50 ugh, yeah shelikhoo 16:41:29 we'll see what happens, i'm waiting for them to respond after explaining why we're using sqs this way 16:42:03 that's it from me on this for now 16:42:06 yes, let's see what they respond 16:42:12 anything else for today 16:42:35 ? 16:42:42 eof from me 16:43:13 I close the meeting then 16:43:16 #endmeeting