16:00:17 <phw> #startmeeting anti-censorship team meeting
16:00:17 <MeetBot> Meeting started Thu May 14 16:00:17 2020 UTC.  The chair is phw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:17 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:26 <phw> here's our meeting pad for today: https://pad.riseup.net/p/tor-anti-censorship-keep
16:00:39 <antonela> o/
16:01:11 <cohosh> hi
16:01:13 <agix> hi
16:01:27 <juggy> yo
16:01:28 <gaba> ///////hi
16:01:33 <gaba> ha :)
16:01:34 <phw> brief announcement: i set up a monit instance on my personal vps, which is now monitoring our anti-censorship services and machines. all alerts go to anti-censorship-alerts@lists.tp.o
16:01:52 <phw> the configuration is here: https://gitlab.torproject.org/torproject/anti-censorship/monit-configuration
16:02:01 <gaba> thanks phw! great
16:02:01 <phw> let me know if you want anything monitored!
16:02:10 <arma2> https://lists.torproject.org/pipermail/anti-censorship-alerts/2020-May/thread.html
16:02:17 <arma2> for those wondering what the traffic looks like
16:02:26 <juggy> Machines as in like bridge servers?
16:03:04 <phw> juggy: for now, default bridges, services (bridgedb, gettor, snowflake)
16:03:35 <juggy> nice
16:04:25 * antonela barking at deamons, love it
16:04:40 <cohosh> lol
16:04:50 <phw> next announcements: our colleagues from the iclab censorship measurement platform sent me a batch of measurements of our default bridges
16:05:09 <phw> we should spend some time mining the data for insights as part of #29277
16:05:41 <phw> i spent an hour or so digging into it and can offer a python parser with some preliminary analysis if anyone's interested in working on this
16:06:17 <phw> my only insight is: there's really not much data left once you remove the data you cannot trust
16:06:50 <phw> fwiw, the data is a simple csv file. it's easy to work with
16:07:40 <arma2> is the data public somewhere? is the plan to make it public? and, can you expand on 'cannot trust'?
16:07:41 <phw> let's move on to our discussion section
16:08:38 <phw> arma2: it isn't yet but it probably can be. i need to ask its author if it's ok to publish it.
16:09:13 <phw> one example: the data has many measurements of a machine that no longer was a default bridge when they started their experiment
16:09:27 <arma2> ah ha
16:09:53 <phw> then there seem to be plenty of transient issues, like "no route to host"
16:10:18 <phw> and potential issues in the way they ran their experiments...? i see some "invalid argument" measurements
16:10:58 <dcf1> I have some old iclab-related code at https://archive.org/details/proxy-probe-data, in the iclab/ directory for prox-probe.git. This was also used with default bridges.
16:11:03 <phw> once you remove all of these, you end up with a rather small set of measurements that didn't exhibit any interesting patterns at first glance; but like i said, i haven't spent enough time on it yet
16:11:17 <arma2> huh. ok. so it is "woah what's going on", not "that client is a not worthy of trust"
16:11:36 <arma2> ok. thanks.
16:12:00 <phw> well, both. as i understand it, these measurements were done on vps systems all around the world. some of these lie about their location and are indeed not worthy of trust
16:12:16 <phw> ...which is obviously not iclab's fault
16:12:45 <phw> either way, more work needs to happen
16:13:30 <phw> let's move on. next up is arma2's bridgedb/gettor email: https://lists.torproject.org/pipermail/anti-censorship-team/2020-May/000097.html
16:13:45 <arma2> right. cecylia was talking about a gettor rewrite, and i realized that gettor and bridgedb overlap a lot
16:14:09 <arma2> see also cecylia's response email. it sounds like she and phw should chat. i don't have more on that topic. unless somebody else does. :)
16:14:28 <cohosh> tl;dr is i'm in favour of this idea
16:14:55 <cohosh> but i'm concerned about pushing more stuff into bridgedb without being able to spend time on code quality
16:15:56 <phw> cohosh: my thoughts exactly. the reason i've been implementing new functionality as external services is that it's really darn hard to extend bridgedb and test it properly
16:17:17 <phw> i think the way forward is to have reliable and lightweight tools talk to each other. they should have one purpose and one purpose only
16:17:18 <cohosh> modularity is good, i think we want to aim for that
16:17:28 <cohosh> if we can do that while also sharing code that both services need that would be ideal
16:18:18 <cohosh> like if we can handle the first step of email processing, and string translations through the same code base that would remove a bunch of duplicate work we've been doing
16:18:38 <phw> all of these are reasonable things to work on but given our small capacity, we have to choose very carefully what we actually do :/
16:18:46 <cohosh> yup
16:19:33 <arma2> i'm definitely not trying to create new work. i also am hoping that some smarter work might benefit both tools, and simplify the future
16:19:44 * phw needs to actually read the email and cohosh's response, and will stop rambling now
16:20:19 <cohosh> this *will* create new work. that new work might also be needed tbh
16:20:47 <cohosh> our code bases have a reputation for getting monolithic and spaghetti-ized(?)
16:21:28 <phw> part of the problem is that maintainers change every so often. it's very difficult to make deep architectural changes in code you don't fully understand :/
16:21:34 <phw> at least that's my experience with bridgedb
16:21:39 <cohosh> same with gettor
16:23:25 <cohosh> idk how to move forward with this right now, maybe we need to let it marinate a bit?
16:23:37 <arma2> we need to let phw read the emails, for starters :)
16:24:03 <phw> yes, agreed. i suggest we continue (and later revisit) this discussion on the email thread -- unless anyone has more thoughts?
16:24:54 <phw> next uuuup is "run a call for testing snowflake"
16:25:02 <antonela> yes!
16:25:06 <antonela> so during the tb release meeting we briefly talked about the need for snowflake testing in tb
16:25:20 <antonela> i want to run this call for testing and i wonder which feedback from users is relevant/useful for us to collect at this point
16:25:31 <antonela> this will be qualitative feedback, maybe breakage or "this website doesn't work" or "this is slow"
16:26:07 <antonela> i added some questions in the pad, specially if we consider sharing some tasks with users to run and wait for feedback
16:26:17 <cohosh> the goal for this is to ramp up snowflake usage and test out our new features
16:26:28 <cohosh> dcf1 made a good comment on #34043
16:26:42 <cohosh> about how we don't know if snowflake will handle a stable release amount of users
16:27:02 <cohosh> right now we have an average of 10-ish
16:27:19 <antonela> so basically, bringing users to snowflake is enough (no tasks but recurrent users)
16:27:32 <cohosh> many of those users are just us testing things
16:27:38 <antonela> i bet yes
16:27:56 <dcf1> During the development of turbotunnel I posted a few invitations for testing, but sadly did not get much response other than from anti-censorship developers.
16:27:59 <dcf1> https://lists.torproject.org/pipermail/tor-talk/2020-February/045499.html
16:28:02 <dcf1> https://lists.torproject.org/pipermail/tor-talk/2020-March/045544.html
16:28:04 <dcf1> https://lists.torproject.org/pipermail/tor-talk/2020-April/045563.html
16:28:09 <antonela> i know dcf1
16:28:11 <cohosh> antonela: yeah but i think it's also useful to come up with specific questions like you mentioned
16:28:26 <antonela> i can draft something next week and we can review together
16:28:56 <cohosh> that sounds great :)
16:28:58 <antonela> we can reuse some dcf1 wording as well
16:29:18 <arma2> my two user-perspective feedback points would be "sometimes it's slow" [when it has a bad snowflake] and "sometimes it doesn't work" [when it has a snowflake it is can't use or is down]. those are pretty rare for me these days, but if i were on a crappy train wifi connection i imagine i'd be saying different sentences. :)
16:29:41 <cohosh> do we want to wait to get ux testing until after we solve more of #19001?
16:29:58 <cohosh> or does that not matter?
16:29:59 <arma2> in theory there shouldn't be any "this website doesn't work" except maybe from latency / throughput issues
16:30:11 <cohosh> like do we basically have one shot at getting feedback before we go to stable?
16:30:31 <antonela> if we want to reach stable in 9.5 we dont have too much time
16:30:37 <antonela> if we want to reach stable in 10, then we do
16:30:38 <cohosh> we don't, we're aiming for 10
16:30:47 <antonela> we can have more than one so
16:31:33 <cohosh> do you have an idea of how many users we can get out of this testing?
16:31:40 <antonela> i like that we are thinking about this for TB10 because by then we should be have been working on making bridge selection smarter and that is connected with those use cases
16:31:45 <antonela> cohosh: dozens?
16:31:50 <arma2> dcf1 / cohosh: re "will our snowflakes handle a lot of users", this is a great question. are there monitoring things we can/should put into place to help us learn how it's going / whether we're getting into the bad world?
16:32:12 <cohosh> hmm okay maybe we can brainstorm other ways of pushing our usage to the 100s?
16:32:31 <antonela> yes, we can
16:32:45 <dcf1> cohosh: I think that having it in a regular alpha release can give us >100 users
16:32:54 <antonela> but not in alpha
16:32:55 <antonela> right
16:33:17 <cohosh> dcf1: it's already in regular alpha though? or do you mean in regular alpha with the tt improvements will get more usage?
16:33:38 <dcf1> I mean in alpha with turbotunnel
16:33:39 <arma2> i definitely would want people to test the snowflake+turbotunnel that i've been using
16:33:42 <cohosh> dcf1: seems like we at least need to advertise that it's better right?
16:33:46 <arma2> the one from dcf's packages
16:34:05 <dcf1> maybe yes maybe no, surely some people try it now but then give up on it because it doesn't work
16:34:06 <arma2> and i agree, making that be the thing you get by default in tor browser alpha would be a good step forward
16:34:17 <dcf1> new people trying it for the first time when it does work, may keep on using it
16:34:31 <cohosh> yeah good point
16:35:27 <cohosh> and then we have the orthogonal thing of working with antonela to get specific UX feedback :)
16:35:53 <cohosh> cool, i'm excited
16:36:05 <cohosh> arma2: that's a good point about monitoring
16:36:28 <cohosh> i'd like to make sure we're checking in on our metrics of "how many clients ask for a proxy but don't get one because we ran out"
16:36:29 <dcf1> snowflake+turbotunnel will be in the new TB alpha, that's #34043
16:36:43 <phw> fwiw, we also know several individuals in places like iran. they could give us quality feedback beyond "it (doesn't) work"
16:36:46 <arma2> cohosh: seems like if the broker has run out of snowflakes and is responding with "oops none", something should notice and tell us. and/or record how much of the time it's being happy.
16:37:10 <cohosh> yeah
16:37:34 <cohosh> there are some nobs we can adjust to deal with more load
16:37:34 <antonela> phw: yes, we can ping partner orgs directly
16:37:41 <dcf1> If we need a short-term increase in proxy capacity we can under #32129 and allow proxies to poll more frequently.
16:37:43 <arma2> cohosh: and then somebody should make a list of all the obvious ways it could fail "because scale", and we should think about whether we can watch each of them
16:38:02 <cohosh> dcf1: yup! that or let browser proxies take 2 clients
16:38:06 <tomcat> Yes, I tried it and give up:(
16:38:52 <dcf1> *undo #32129
16:38:54 <cohosh> tomcat: if you're willing to try snowflake again, dcf1's work has made it much more usable :)
16:39:35 <arma2> cohosh: speaking of UX in particular, my earlier debugging made me file #33746 ("Show users a bandwidth graph or activity spinner during slow loads")
16:40:16 <arma2> (not a short term thing though)
16:40:23 <antonela> oki, so to wrap up, let's do this call after tb9.5 stable release? by then alpha series will have snowflake+tt and we can plan to ping orgas directly + lists call
16:41:14 <cohosh> sounds good to me
16:41:35 <antonela> awesome, i'll follow this up
16:41:40 <phw> thanks antonela
16:41:45 <antonela> next item is gaba's but is also mine
16:41:48 <antonela> S30 UX work
16:42:06 <gaba> antonela: it is mostly for you to talk about your work here
16:42:26 <antonela> i've been listening tunde's interviews, he said hi today in otf-talk :), i'm almost finishing with them and drafting some ideas for personas
16:42:46 <antonela> my plan is finish that part this month so i should back here soonish with those drafts
16:42:59 <gaba> so mostly working on Tor personas related to scenarios of censorship
16:43:06 <antonela> yes
16:43:14 <arma2> nice
16:43:21 <antonela> and discuss together if those escenarios are a good scope for this sponsor work
16:43:35 <antonela> (for framing this sponsor work)
16:44:22 <antonela> also for s30
16:44:28 <antonela> i wonder how ooni data is flowing here, is that working? ooni tor probes are arriving? is that data usable for making bridges selection smarter? not yet? will be in the future?
16:44:51 <phw> antonela: we're working on this right now
16:45:03 <phw> in fact, arturo mentioned he will be looking into our api today
16:45:10 <antonela> oh nice
16:45:35 <antonela> so you are talking and working on making it work
16:45:37 <antonela> awesome :)
16:45:53 <phw> yes, a software tool that sits alongside bridgedb will provide ooni probes with bridges to test
16:46:09 <phw> we then periodically fetch ooni's test data to teach bridgedb which bridges it shouldn't be handing out
16:46:11 <antonela> i worked with ooni last month on shipping the tor test in ooni apps but i didnt know if it was working on our side
16:46:19 <antonela> super
16:46:41 <antonela> oki, that is all on my side folks, i hope speed up on this work in the next weeks after tb release is done
16:46:57 <phw> great news, thanks antonela!
16:47:01 <antonela> thanks you!
16:47:21 <phw> shall we move on to our 'needs help with' sections?
16:47:27 <phw> remember that we also have a reading group today
16:48:13 <phw> i have #34212 and was wondering if dcf1 can provide some tips
16:48:47 <phw> cohosh has #27330 and #34222
16:48:57 <dcf1> I will leave a comment on #34212
16:49:02 <phw> agix has #31528
16:49:05 <phw> thanks dcf1
16:49:05 <cohosh> #27330 fell through the cracks from last week
16:49:26 <phw> agix: i'll take #31528. sorry that my reviews take so long :/
16:49:35 <agix> phw: no problem :)
16:49:45 <phw> and thanks for working on this!
16:50:02 <phw> i can do #27330
16:50:14 <cohosh> thanks
16:50:15 <phw> oh, wasn't that the ticket that hiro wanted to do?
16:50:26 <cohosh> yeah idk what happened exactly
16:50:44 <cohosh> but i'd like a review
16:50:55 <agix> phw: let me know if you need any more changes on #33835
16:50:59 <cohosh> i don't think hiro has time for gettor stuff
16:51:16 <phw> anyway, it's been a week without review, so i'll go ahead and review it
16:52:25 <phw> agix: i haven't had a chance to take a look at it yet. i'll let you know! i think the overall approach is fine and i just wanted to play around with it to convince myself that it's sound
16:52:42 <agix> phw: cool
16:53:13 <phw> #34222 is for our git admins, so i think we're done with reviews
16:53:26 <phw> any last words before we start our reading group?
16:54:44 <phw> ok, let's start our reading group
16:55:02 <phw> today's topic is the salmon paper: https://censorbib.nymity.ch/#Douglas2016a
16:55:10 <phw> agix: i believe you have a summary?
16:55:16 <agix> yep
16:55:24 <agix> <summary>
16:55:32 <agix> Salmon is a system concept designed for censorship circumvention that relies on a network of volunteers in uncensored countries to run proxy servers.
16:55:44 <agix> It claims to significantly reduces the amount of users that can be cut off from access by a censor, compared to other systems like rBridge, while making the system easily accessible to the general public and at the same time make it difficult for the censor-agents to infiltrate the system.
16:55:54 <agix> The algorithm entails identifying some users as especially trustworthy or suspicious, based on their actions.
16:56:00 <agix> The salmon algorithm is based on 3 components:
16:56:15 <agix> 1. Suspicion: probability that a user is a censor-agent. Every time a bridge that has been assigned to n amount of users is blocked, the suspicion that one of the users is a spy rises.
16:56:33 <agix> 2 .Trust: Users who knew a server address for months without the server getting blocked, seem less likely to be censor-agents.
16:56:33 <agix> Higher trusted users will be served with higher-quality servers and will keep them better isolated from new users, which are more likely to be censor-agents. Possible censor-agents are only revealed if a bridge has been blocked in a certain country.
16:56:48 <agix> 3. Recommendation: Users on a certain trust level are able to recommend friends to Salmon.
16:57:06 <agix> A censor can follow 2 possible strategies.
16:57:20 <agix> Either block immediately every server address they get a hold of, therefore not being able to harm higher level users.
16:57:28 <agix> Or wait and allow users to circumvent censorship system while the censor-agents try to discover higher level server addresses.
16:57:38 <agix> One of the downsides of Salmon is that it only allows access by recommendation or by proving ownership of a well-established Facebook account.
16:57:51 <agix> </summary>
16:57:57 <arma2> for those who like talk videos, https://petsymposium.org/2016/spw-mirror/pets-2016/program/ has a youtube link of fred presenting it.
16:58:13 <agix> I thought to start todays discussion I will share my idea on how the Salmon concept could be used as a new bridge distribution mechanism (and I think juggy worked on some ideas as well)
16:59:01 <agix> A user requesting a bridge for the first time would, additionally to the bridge address, could receive a pseudonymous token (cohosh already mentioned to me that we actually should aim for a pseudonymous-token-system) that would be assigned to the given bridge address.
16:59:26 <agix> Every token will be unique and the relation between token and the assigned bridge will be saved in BridgeDB’s database. The usage of this token is not mandatory but it allows the user to take part in the Salmon system.
16:59:46 <agix> Users that request bridges without taking part in the trust system will always be treated as level 0 users, meaning their provided bridge will not have the advantages of higher level bridges.
17:00:01 <agix> Users could request a higher level bridge by providing BridgeDB with their token and if eligible will be provided with a higher level bridge and the BridgeDB database will be updated accordingly.
17:00:13 <agix> Users who would like to recommend a friend could provide BridgeDB with their token to generate an invitation code which can only be used once. The friend can use this could to generate their token and take part in the trust system. BridgeDB’s database will be again updated to create the relation between the friends.
17:00:24 <agix> Users need to be advised on, not to use recommendation codes from people they do not know since they might stem from an adversarial source, causing them to be grouped with spies. They should further be advised not to share the bridge addresses among friends. Instead they should be encouraged to take part in the system since they will all benefit from it.
17:00:45 <agix> One aspect that needs to be considered for a salmon-like distribution system, is the reporting of blocked bridges.
17:00:46 <agix> phw already pointed this out in the anti-censorship-team mailing list (in Vol 13, Issue 8) and suggested some software components (Wolpertinger & Bridgestrap) to fix this issue.
17:00:53 <agix> Thats all from me for now :)
17:01:38 <cohosh> nice agix :)
17:01:53 <juggy> So those who request a bridge and choose to receive a token (and subsequently submit it) automatically start off at a higher trust level?
17:02:34 <agix> No they should start at level 0, unless they have been recommended
17:02:55 <phw> thanks for the summary, agix
17:03:57 <phw> to take a step back, i like the notion of "this bridge is full, we no longer hand it out"
17:04:35 <phw> in practice, it won't be as simple, though. users disappear and a bridge will eventually have capacity again
17:04:36 <arma2> agix: hm, in the original salmon paper, i thought only people at the highest trust level could do a recommendation. is your proposal that anybody can? that seems .. tricky to analyze.
17:04:53 <cypherpunks> Wait, so how do you build up trust?
17:05:08 <dcf1> arma2: users can invite people and the invited people inherit the inviter's trust level
17:05:12 <cypherpunks> phw: How should that be verified? Unique IPs?
17:05:20 <agix> arma2: No, like in the paper, it should only be possible at a certain level
17:05:25 <arma2> cypherpunks: you go from trust level x to level x+1 by waiting 2^x days and not having your bridge get blocked
17:05:42 <dcf1> I believe the rationale for that is that you can't stop users from sharing bridge addresses they know, even without interacting with the Salmon system
17:05:57 <cypherpunks> What prevents the adversaty from just setting up 100 users and blocking whatever they get?
17:06:24 <dcf1> cypherpunks: that's the main point of the paper.
17:06:37 <cypherpunks> There's a bit of a risk here: if they have a level X profile, and they get a level X bridge, they can with reasonable confidence observe that whoever connects to that IP is a level X user
17:06:39 <cypherpunks> right?
17:06:45 <juggy> They wont be able to block higher trust servers
17:07:39 <cypherpunks> They don't need to block them
17:07:44 <arma2> agix: ok, sounds good. so users can do the recommendation thing but only if they're at level 6 or whatever. which introduces a bit of a ux question too ("how does the user know") but that seems solvable.
17:07:57 <dcf1> Section 2.3: ""Salmon incorporates a recommendation system: a user at maximum trust level L may recommend friends to Salmon; these friends join at level L−1."
17:08:01 <juggy> cypherpunks: Ya the bridge trust level is the minimum trust level of all its users I think
17:08:13 <dcf1> I don't think you need to be at level 6 to recommend others.
17:08:17 <arma2> for other context, i wrote up a bunch of thoughts on salmon earlier today, and sent them to the list:  https://lists.torproject.org/pipermail/anti-censorship-team/2020-May/000100.html
17:08:18 <agix> cpyherpunks: right, but ideally the censor only sees his own agents, since all the recommended users get grouped together
17:08:34 <cypherpunks> They can just use the bridges as a starting point: Bridge X is known. User X, Y, and Z connect to bridge X, and also to bridges A and B
17:08:37 <cypherpunks> and so on, and so forth
17:08:47 <arma2> dcf1: what is this word 'maximum' doing in that sentence then?
17:08:52 <cypherpunks> for a network-level adversary
17:08:57 <dcf1> cypherpunks: I hate to ask, but did you read the paper?
17:09:05 <arma2> "The levels reach up to
17:09:06 <arma2> a maximum of L, a parameter to be decided upon."
17:09:10 <dcf1> Section 3.10 is about the "zig-zag attack"
17:10:24 <cypherpunks> I know, it just doesn't seem to explain it adequately
17:10:40 <agix> i think the paper recommended a maximum level of 6, which would need over 2 months to reach
17:11:14 <cypherpunks> It can just observe proxy servers by looking at traffic patterns
17:11:16 <arma2> agix: yep. and the special users can bring in people at L6 once a day
17:11:33 <dcf1> arma2: you may be right. I interpreted the "L" in that sentence to be a different binding than the "L" system parameter.
17:11:45 <cypherpunks> "this HTTPS server sees heavy traffic from these people, but hardly anyone else"
17:13:02 <arma2> dcf1: in Sec 5.3 they speak of censors who need to wait 4 months to recommend their first person, or 5 months to recommend two
17:13:45 <cypherpunks> Whatever happened to the Snowflake Chrome extension? There's no option to use such bridges in TBB
17:13:54 <dcf1> arma2: yes but I thought that was a censor that deliberately delays its recommendations.
17:14:02 <arma2> dcf1: but more generally, the fascinating thing about salmon is that it has *all* these knobs, for decisions that could have been made differently, and it's wildly unclear to me how robust it is when the knobs are turned slightly differently.
17:14:52 <arma2> like, you wouldn't think that the recommendation thing is so critical, until you see their graph showing what happens if it's missing
17:15:23 <arma2> s/the recommendation thing/grouping users with their recommendee/ (there that makes more sense)
17:15:29 <dcf1> having lots of knobs doesn't bother me too much; I think other systems like Salmon would have them too; but the Salmon authors discovered and documented them because they fielded a deployment
17:16:20 <dcf1> I mean, yes it's a concern that it appears to be sensitive to parameters, but I suspect similar proposals would be as well.
17:16:38 <arma2> agreed. which makes me inclined to believe that the parameters they picked are somehow more likely to be right than other choices that seem plausible too
17:17:10 <dcf1> btw https://github.com/SalmonProject still has code
17:17:22 <dcf1> Project home page seems offline but there's an archive at https://web.archive.org/web/20170224182543/https://salmon.cs.illinois.edu/en/home.html
17:17:31 <cohosh> speaking of other systems, one think salmon accounts for is allowing users to join without being recommended to the system
17:17:43 <cohosh> wheras rbridge/hyphae both require you to be recommended
17:18:00 <cohosh> i like that salmon users can all join at level 0 and it's robust in this case
17:18:11 <cohosh> arma2's point about the sybil defences is worth thining abou tthough
17:18:14 <arma2> cohosh: but it needs sybil-resistance for its new users. speaking of which, how practical is it, engineering-wise, for us to do the facebook account checking?
17:18:19 <cohosh> obviously the facebook acount is not an option fo rus
17:18:22 <phw> i think that's a critical feature. censored users don't all know each other
17:18:28 <dcf1> It's possible that I greatly misunderstood the interaction of recommendations and trust levels.
17:18:31 <arma2> cohosh: obviously? that's not yet obvious to me :)
17:18:32 <agix> arma2: perhaps their parameters are even a bit to conservative, since they argue that the server addresses can be easily changed once blocked, but i am not sure if that applies to our bridges as well
17:18:37 <juggy> One questions I have is  the part where they talk about letting users use "low-bandwidth covert channels like Skype and email" to access FB to register for Salmon - how does that work?
17:18:52 <cohosh> arma2: requiring people to make facebook accounts to get bridges? :|
17:19:03 <dcf1> I think the facebook account checking is basically equivalent to the bridgedb requirement of a gmail or riseup email address. They don't use any friendship graph information from Facebook, right?
17:19:05 <arma2> cohosh: requiring them to make facebook accounts to get *salmon* bridges
17:19:17 <phw> dcf1: that was my understanding, yes
17:19:17 <cohosh> hmm fair
17:19:25 <cohosh> i also don't love that feature though
17:19:30 <cohosh> a lot of people have trouble with it
17:19:31 <arma2> if they require a 2015 facebook account, i think it's a stronger sybil defense than our "you need to have a gmail address" check
17:19:44 <phw> requiring a facebook account isn't great but neither is requiring a gmail or riseup account
17:19:49 <cohosh> getting a gmail account requires a phone number, riseup is difficult because of the recommendation thing
17:20:22 <dcf1> This is what I was thinking of re trust levels and recommendations: "when assigning a new server to a user u, we first look for one that has already been given to a member of its connected com- ponent ... Because this sharing of servers among friends is so natural, this logic takes precedence over the trust levels: a user may be placed on a higher-level server if it includes a recommendation friend."
17:20:33 <arma2> juggy: i think they were just saying that even if facebook is blocked in your country, you still probably have a facebook account, because it doesn't take a very high-bandwidth circumvention tool for you to reach facebook. so you probably already did, because that's where all your friends are.
17:20:50 <dcf1> But I suppose the invited user is not *actually* at a higher trust level, just effectively at one for the purpose of bridge sharing.
17:21:24 <arma2> dcf1: remember, you lose a trust level if your bridge gets blocked. So if an L6 recommends you, you're L5, but then your bridge gets blocked, now you're L4
17:21:37 <dcf1> arma2: yeah I think you're right.
17:21:40 <arma2> that's how you can get below L or L-1 even if you were recommended
17:21:59 <arma2> (ok, saying "L6" and "L" is super confusing, i'll stop doing that :)
17:22:36 <arma2> cohosh: for salmon allowing new non-recommended users, it is critical to have a strong sybil protection for signups
17:22:57 <arma2> otherwise the adversary just keeps signing up new users, and they get each bridge, and then block them, and new users have a horrible experience and then their account gets canceled.
17:23:04 <cohosh> are there better solutions than "have an account for this service that's terrible for privacy" there?
17:23:35 <arma2> cohosh: sure. all of the rate limiting things. "give us $10", etc. it's the same problem as for, say, nymble. there are no great answers though.
17:23:47 <cohosh> (riseup isn't terrible for privacy but reduces it back to the "you have to be recommended" problem)
17:24:07 <cypherpunks> And also the bit where you need to have a specific political opinion
17:24:21 <arma2> cohosh: this is one case where academia wins. all they need in their paper is to say "we'll use facebook accounts", and now their paper has solved that part.
17:24:26 <dcf1> cypherpunks: fair :)
17:24:30 <cypherpunks> One approach is to segregate them based on domain
17:24:46 <cypherpunks> So, you set some fraction of the bridges apart as gmail bridges, some as riseup bridges, some as cock.li bridges, etc
17:25:20 <cypherpunks> What's the blocker for using flashproxy on a larger scale?
17:25:39 <cohosh> cypherpunks: we're getting off-topic here
17:26:30 <arma2> dcf1: let me know if you have more "wait, how does that work" trust level questions. i spent a while in 2016 arguing with them about it so i think i have a pretty good handle on what they were envisioning. :)
17:26:39 <dcf1> On the topic of bridge liveness detection and false positives,
17:27:00 <dcf1> I can't remember, did the authors suggest having bridges self-report liveness?
17:27:15 <dcf1> As an alternative to users measuring liveness or a central server measuring liveness.
17:27:21 <arma2> i think the user tries to reach the bridge, can't, and goes to the directory server to say "help me bridge is gone"
17:27:48 <dcf1> If all your users report a bridge as unreachable, but the bridge itself is sending heartbeat pings hourly to a central server, then you can avoid immediately demoting all the users of that bridge.
17:27:49 <arma2> and then the directory server either already knows it moved or went down globally, in which case it serves back a replacement,
17:28:13 <dcf1> Or rather,
17:28:17 <arma2> or the directory server is surprised to hear that it's down, and ... they didn't have a section where they confirm from inside the country.
17:28:29 <cohosh> a heartbeat is an interesting idea. but it doesn't defend against malicious bridges
17:28:37 <dcf1> you want to know whether to blame the users for getting their bridge blocked, or whether the bridge just disappeared and it's not a user's fault
17:28:46 <arma2> right
17:29:05 <dcf1> Right, it's not for malicious bridges, but for reducing the probability of a false positive, because false positives are so costly.
17:30:00 <cohosh> if we have geographically distributed users, this might help us
17:30:13 <cohosh> some users can't reach it, but others can might indicate blocking events
17:30:14 <arma2> in the paper, they say "The check is done by the directory
17:30:15 <arma2> server."
17:30:27 <arma2> but i agree there seem like ways to make that part better
17:30:56 <cohosh> also as agix and phw pointed out, the ooni feedback loop
17:31:06 <arma2> they also spoke, in my email thread with them, about having the in-country user "try to reach google, and then the bridge, and then google again", and only report the bridge as down if the google connections both worked
17:31:43 <arma2> (that design also seems like it can be improved. i'm just trying to get across what the authors had in mind.)
17:33:09 <phw> cohosh: you're a bigger fan of rbridge, no? why is that?
17:33:37 <cohosh> setting aside the issue of recommendations vs sybl defences, i like how rbridge doesn't store user data at the server
17:34:42 <cohosh> rbridge and hyphae both have designs where the users store all the information they need (e.g., which bridges they know about, their reputation points) as tokens and hand them to the server when they want to get more bridges or recommend other users
17:34:52 <arma2> the salmon paper argues that you need to group the recommender with the recommendee, or the attacker can attack way better. and that grouping seems hard to do while keeping the unlinkability.
17:35:25 <cohosh> this is nice from a server maintenance standpoint, and also from a legal liability "store as little as possible about your users" standpoint
17:35:33 <arma2> ..or are the recommenders linkable to their recommendees in the rbridge/hyphae design?
17:36:12 <cohosh> arma2: no, and that was a feature that seemed nice in terms of limiting censors. i'd like to think about whether we really need the social graph bit
17:36:33 <juggy> phw: You mentioned in your email that Salmon would be a distributor that exists alongside the rest, how come the underlying Salmon concepts wouldn't work with, say, Moat?
17:36:43 <arma2> right. it seems there is a very clear "effectiveness" vs "privacy" tradeoff here. and it would be cool to find some cool math trick that gets us both.
17:37:05 <cohosh> or if there's a way to hand out bridges to recommendees that are similar to the set known by the recommender in a private crypto-magic way
17:37:17 <arma2> juggy: when you say moat, do you mean "use domain fronting to reach bridgedb", or do you mean "solve a captcha and now you have a moat bridge"?
17:38:15 <phw> juggy: it's certainly possible to merge the two somehow. there are many open questions, especially when it comes to salmon's UX
17:38:22 <juggy> arma2: the latter
17:38:26 <phw> should it all be in tor browser? should it be a (domain-fronted) website?
17:40:00 <arma2> phw: for context, the 2016 authors had in mind to write automated email clients that logged into your gmail and sent and received email. so, moat plus doing it in tor browser could be way simpler (and more robust and more intuitive too)
17:40:54 <cohosh> i like the idea of using moat as the interface with the server, it's our most popular bridge distribution method already right?
17:41:18 <agix> cohosh: according to the metrics it is
17:41:19 <phw> cohosh: yes it is: https://metrics.torproject.org/bridgedb-distributor.html
17:41:21 <arma2> i think "ask for an https bridge via a tor address" is our most popular, if you count the bots ;)
17:42:10 <cohosh> :P
17:42:47 <arma2> oh, and speaking of the idea of having ooni test bridges, if people here haven't looked at the early writings on 'how to test bridge reachability', see https://blog.torproject.org/research-problem-five-ways-test-bridge-reachability
17:43:25 * cohosh needs to eat something before jumping into yet another meeting
17:43:35 <arma2> and here's the part that makes it fun: once we can learn whether bridges are reachable or not, and we can learn how much load they're carrying,
17:43:52 <arma2> we could dynamically adapt to which distribution channel is being most successful: moat, https, gmail, salmon, etc
17:44:37 <arma2> phw: ok. anything more for us on this topic? :)
17:45:31 <agix> do you guys think that Salmon might be a useful bridge distribution mechanism in the future?
17:45:35 <phw> to give you all some context: we have funding to build a social distributor but the details are all still in the air
17:45:52 <arma2> agix: i think salmon is the most compelling design i have seen so far.
17:46:07 <arma2> but there are still some big unspecified parts to it
17:46:33 <arma2> plus there are some parts like the anti-sybil defenses that might make people itch
17:47:32 <agix> arma2: but how is it different from the current  anti-sybil defenses we have to apply?
17:47:51 <arma2> china is beating the heck out of them
17:47:58 <arma2> try getting a bridge from bridgedb and using it in china
17:48:45 <agix> arma2: i see, so its an issue that not only applies to salmon, but our distribution in general
17:48:46 <arma2> so we need to step things up on that front if we want the rest of the design to have a chance of working
17:48:52 <phw> it's been almost an hour. we should wrap up. how about we continue this discussion on the mailing list?
17:49:12 <agix> arma2: cool, got it :)
17:49:44 <phw> #endmeeting