17:01:17 <phw> #startmeeting anti-censorship weekly checkin 2019-05-09
17:01:17 <MeetBot> Meeting started Thu May  9 17:01:17 2019 UTC.  The chair is phw. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:17 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:01:20 <haxxpop> cohosh, hi
17:01:21 <phw> hi everyone
17:01:40 <phw> gaba said she'll be a little late today but we can start already
17:01:40 <ahf> hey o/
17:01:59 <phw> here's our pad as a reminder: https://pad.riseup.net/p/tor-censorship-2019-keep
17:02:22 <kat5> Hi.
17:02:27 <phw> we have two announcements.  can i hand the mic to you, cohosh?
17:02:36 <cohosh> oh those were from last week i think
17:02:58 <phw> let's make that 0 announcements then
17:03:05 * phw grabs the mic again
17:03:10 <cohosh> XD
17:03:11 <antonela> haha
17:03:12 <ahf> :-D
17:03:19 <ahf> no mic drops yet, good
17:03:28 <phw> ahf: we're early on in the meeting :P
17:03:45 <ahf> :-D
17:03:48 <phw> we have two discussion points though.  first, i'd like to revise our "obfuscation" component in trac
17:04:03 <phw> i added some suggestions and was curious what you all think
17:04:58 <ahf> hm, is there only obfs4 tickets under the current obfsproxy component?
17:05:17 <ahf> i don't know if we even care about older versions, if not, then i guess it doesn't matter
17:05:18 <phw> that's a good question.  i'm not sure.
17:05:21 * catalyst slightly prefers "circumvention" to "anti-censorship"
17:05:33 * arma1 appears, and reads backlog
17:05:54 <cohosh> this seems reasonable to me
17:06:07 <phw> 'circumvention' sounds good to me too.  i'm just not a fan of 'obfuscation' because that's not all we're doing
17:06:10 <cohosh> we could also put other obfs versions under the new "Other" field
17:06:34 <ahf> one thing that might be worth keeping in mind is how trac tickets in this part of our trac world matches to "projects" in a github/gitlab kind of way since the gitlab service now actually works
17:06:45 <ahf> there will be a mail out soon to ask people to "play a bit around with it"
17:06:48 <ahf> if they want to
17:07:07 * phw note to himself: sign up for gitlab
17:07:25 <ahf> yeah, please give it a try to see if it is something you could see being used
17:07:32 <ahf> we are not going to force it down on anybody :-)
17:07:46 <catalyst> ahf: do we need to sign up for gitlab accounts or is it automatic through LDAP?
17:08:12 <ahf> catalyst: you go to dip.torproject.org, click "I have forgot my password" then use your LDAP email (@torproject.org)
17:08:17 <ahf> guest logins will come, but are not there yet
17:08:23 <catalyst> ahf: thanks!
17:09:28 <phw> now that i think about it, i also like 'circumvention' more than 'anti-censorship'.  any other categories we may want?  i like cohosh's idea of filing tickets for vintage technology under 'other', or even a dedicated 'vintage' category
17:09:49 <dcf1> there is a term for that already, I think...
17:10:37 <ahf> would people know what belongs in a vintage category when they submit bugs?
17:10:56 <cohosh> dcf1: Archived?
17:11:33 <dcf1> yes "Archived" is what I was thinking. "Archvied/Flashproxy" is in there.
17:11:39 <phw> ahf: good point.  'other' may be good enough, then.  we can also change it if it turns out to be a bad idea
17:11:50 <arma1> yep. shove it all into the attic if you're not using it.
17:11:59 <gaba> o/
17:12:14 * phw takes note
17:13:08 <kat5> Which is great, until you have to clean the attic.
17:13:33 <phw> should we move 'obfsproxy' into 'archived' just yet?  or leave it around for a while?
17:14:02 <dcf1> (py)obfsproxy is only still used for FTE, AFAIK.
17:14:19 <phw> ...which is in the process of retiring
17:14:22 <dcf1> there's an older (C)obfsproxy that is even more obsolete.
17:14:55 <catalyst> do we have any FTE default bridges in TB anymore?
17:15:17 <dcf1> Here's the tickets: https://trac.torproject.org/projects/tor/query?status=!closed&component=Obfuscation%2FObfsproxy
17:15:18 <phw> catalyst: no, the three we currently have are all offline.  kpdyer (the original maintainer) no longer has time to manage them
17:15:49 <arma1> i think the heuristic is "would you want anybody to file a ticket in that category", as in, would anybody do anything about those tickets. if no, to the attic.
17:16:26 <ahf> sounds reasonable
17:16:28 <phw> i think the answer according to this heuristic is a "no".  let's move 'obfsproxy' to the archive, and create a new category called 'obfs4', ok?
17:17:05 <cohosh> sounds good to me
17:17:08 <arma1> ok
17:18:18 <phw> and finally, i think an "other" category would be nice because we occasionally have circumvention-related issues that don't fit into existing categories.  it looks like the other components don't have that, though, so i might be wrong
17:18:52 <arma1> you're likely to regret all the tickets that arrive there :)
17:19:25 <cohosh> i've been using PT as an Other category tbh
17:19:38 <cohosh> "Pluggable transport"
17:20:01 <cohosh> so things like new PTs to be integrated into Tor Browser
17:20:08 <cohosh> which probably isn't what it's supposed to be used for
17:20:11 <phw> looks like you can also leave this category field blank, so i guess there's no need for 'other'
17:20:23 <cohosh> ah right I've done that too I think ^^
17:20:56 <phw> alrighty, i think that's all
17:21:16 <phw> who added the dormant mode discussion?
17:21:19 <ahf> me
17:21:23 * phw hands the mic
17:21:45 <ahf> okay, so the network-team is looking into how we integrate the PT's and tor's recent "dormant mode"
17:22:06 <ahf> we had an email thread in december 2018 where dcf1 had some suggestions and the thing nick and i talked about yesterday is very close to that
17:22:38 <ahf> but one part that i'd like to hear about is how we think we should do feature flag announcement/announcement of support of features between PT's and it's ... parent process
17:22:55 <ahf> and we are of course in PT 1.x world still here :-/
17:23:51 <phw> ahf: is there a ticket for it?
17:24:12 <ahf> #28849
17:24:20 <ahf> and the email thread listed in the pad
17:24:31 <cohosh> ahf: the parent process being tor?
17:24:34 <cohosh> (in this case)
17:24:48 <ahf> yes
17:24:57 <dcf1> we have in the past added features by having the PT acknowledge messages sent by tor.
17:25:10 <ahf> the "problem"/"nice thing" about dormant mode is that tor doesn't actually want to kill the PT as it wishes to keep the currently established connections alive
17:25:17 <dcf1> Like I remember there was somethinking that we would have to bump the PT protocol major version from 1 to 2 to add the PROXY feature.
17:25:20 <ahf> it just want the PT to move into a state where it tries to do "as little as possible"
17:25:41 <ahf> dcf1: right
17:25:55 <dcf1> Instead, tor sends PROXY and the PT replies with PROXY-DONE. if tor doesn't see PROXY-DONE, it assumes that the PT process doesn't understand PROXY.
17:25:58 <ahf> the feature flag would be to figure if tor can send some kind of "SIGNAL DORMANT" message
17:26:24 <cohosh> was PROXY sent at startup? or when tor wanted to send the message?
17:26:33 <dcf1> cohosh: PROXY is always at startup.
17:26:40 <cohosh> okay cool
17:27:01 <dcf1> that's where dormancy is different than the protocol has been up to this point, because the DORMANT signal can happen at any point.
17:27:02 <ahf> so we could have some kind of DORMANT-SUPPORT, and the PT could respond with DORMANT-SUPPORT-YES? i know i'm bad when it comes to trying to turn things into being more generic, but sending some kind of boolean feature flags seems smarter?
17:27:13 <ahf> so manybe "FEATURES a,b,c,d" "FEATURES-DONE a,c,d" ?
17:27:45 <dcf1> one question is, how will tor act differently depending on whether the PT supports dormant or not?
17:27:53 <cohosh> would it be best to enumerate features or do some kind of minor version negotiation at startup?
17:28:10 <dcf1> if the PT doesn't support dormant, will tor just refuse to run it, on the grounds that it won't become dormant when asked?
17:28:11 <ahf> the only difference i think is whether tor will write the message to the PT or not
17:28:16 <ahf> no
17:28:21 <ahf> that would be a bad idea i think
17:28:24 <phw> atagar may have some good ideas given his experience with stem
17:28:47 <ahf> if the PT doesn't support dormant mode then the PT will just use more battery and continue to work like it does today
17:28:52 <dcf1> because if tor is going to run the PT anyway, than does it even really need to know whether the PT supports dormancy?
17:28:55 <ahf> it's purely a way for us to announce when this is being enabled
17:29:14 <dcf1> or, tor could kill the PT process unless it has become dormant.
17:29:18 <ahf> yeah? the PT should ideally not trigger too many timers, establish new connections, and so on while it's dormant
17:29:31 <ahf> we cannot kill it because tor doesn't terminate its currently established TCP streams in dormant mode
17:29:32 <arma1> it's true that in this particular case, if tor is going to do the same thing whether the PT understands it or not, tor doesn't technically need to know whether the PT understands it. :)
17:29:35 <ahf> so your SSH connection will continue
17:29:47 <dcf1> yeah I'm doing some devil's advocate questions here.
17:30:08 <ahf> no, we could just write "SIGNAL DORMANT" to the PT and the PT can ignore it or do whatever it feels like :-)
17:30:20 <arma1> so long as it doesn't ruin the rest of the protocol
17:30:25 <ahf> right
17:30:40 <ahf> we wont do anything special with PT's that does not support dormant right now
17:30:50 <ahf> but we might want to terminate those later in the future
17:30:59 <dcf1> one option is to do like PROXY-DONE, and have the PT reply either "I have gone dormant" or "I have not gone dormant" or not reply meaning "I didn't understand this 'dormant' thing"
17:31:00 <arma1> it does seem like designing some sort of "capabilities and versions" sync'ing protocol is a good idea
17:31:09 <ahf> arma1: agreed
17:31:28 <arma1> dcf1: what does the PT protocol do, now, when you send it a thing it doesn't understand? silently drop?
17:31:33 <phw> aren't we gonna end up with confused users who expect everything to be dormant once they configure it that way?
17:31:56 <arma1> dcf1: that seems bad, because then i send the PT GO_DORMANT and it replies with nothing and i send it GO_SHOPPING and it replies OK and then i don't know what it acked.
17:31:59 <dcf1> arma1: currently everything after the initial negotation is ignored, because PTs aren't written to pay attention to stdin after startup, because the protocol doesn't require that.
17:32:00 <ahf> i worry about not having the feature check first, so when we do "SIGNAL DORMANT" first time, then the poor PT process writes "Unknown command on stdin: SIGNAL DORMANT"
17:32:08 <ahf> and the user will see those in their tor logs and go fill a ticket :-)
17:32:18 <dcf1> arma1: obviously it would be marter than that, "OK DORMANT" or "OK SHOPPING", geez.
17:32:33 <ahf> yeah, this new feature will require the PT's listen on their stdin for other things than it being close()'d
17:34:00 <arma1> ..do all expected platforms have a notion of stdin? that is, are we sufficiently general with that idea?
17:34:18 <arma1> assuming yes, i will note that we want a solution that is about the size and shape of a bike shed.
17:34:19 <ahf> what's the problem with: "FEATURES a,b,c" then "FEATURES-ACK a,c" after PROXY/PROXY-DONE ?
17:34:22 <dcf1> well I think either approach can work, either negotiate all possible capabilities at startup, or do acknowledgements of support at the point of need.
17:34:24 <cohosh> if we do some kind of initial feature negotiation, can we do it in a way that's backwards compatable?
17:34:36 <ahf> current PT's will ignore it (as long as we don't get to the point where writing to the PT blocks :-S)
17:34:41 <ahf> so max 1400 bytes or so :-S
17:34:41 <cohosh> ah ok
17:35:34 <ahf> man i just realized if the PT doesn't read for stdin, then at some point we reach the size of the pipe buffer with these messages and writing to the PT will block
17:35:48 <ahf> so w eshould really only write if we get the FEATURES-ACK
17:35:48 <dcf1> one thing in the back of my mind is if, generally speaking, you can't assume that just because a PT supporrts a feature, that it will be able to always use it when requested.
17:35:56 <ahf> we should never send SIGNAL DORMANT unless we can
17:36:03 <arma1> this is also the kind of design where some other PT designer is going to be shocked that we didn't use json, or didn't use whatever their platform always uses by default
17:36:04 <dcf1> ahf: yes I think that's a concern with current PTs.
17:36:27 <ahf> dcf1: i agree, but this signal is also only for the PT to try to do its best in its current situation
17:36:36 <ahf> i think there are PT's where they cannot disable all timers for example
17:36:39 <arma1> dcf1: i think "supports" means "knows what the syntax of requests is, and how to respond"
17:37:25 <ahf> right
17:37:30 <ahf> "able to understand this request" in this case
17:37:39 <ahf> able to understand can also mean that it's gonna ignore it
17:38:00 <dcf1> right, dormant mode isn't the best example of that, and I shouldn't complicate the discussion by thinking of hypothetical features.
17:38:32 <dcf1> "able to understand can also mean that it's gonna ignore it" I don't know if that's the best model
17:38:50 <ahf> i cannot even from top of my head think of how obfs4 should implement this. it should continue its timers for its established connections, but for example snowflake should terminate its connectivity with a broker and stop sending data that isn't needed for keeping the current connections alive
17:38:53 <dcf1> because one way to handle all this would be for goptlib to take command of stdin, and interpret the commands, and deliver them to the process on a channel.
17:39:07 <ahf> that was how i was thinking it should be implemented
17:39:17 <dcf1> So goptlib would get GO_DORMANT and it would send a DormantRequest on the channel for the process to act on as necessary.
17:39:23 <ahf> that the user of the library gets a go channel that gets a signal when we want to go dormant
17:39:32 <ahf> yeah
17:39:34 <dcf1> In this case, *every* PT using goptlib would say "I support dormant mode", even if they don't.
17:39:51 <dcf1> because it would be goptlib handling the initial feature negotiation.
17:39:55 <ahf> can the feature be enabled when you call the function that requests the go channel?
17:40:09 <arma1> wouldn't they instead by saying "i know what you mean by dormant mode"?
17:40:13 <arma1> s/by/be/
17:40:20 <dcf1> So even with up-front feature negotiation, you still might want something that allows the PT to say, I have understood the request you just sent me.
17:40:42 <ahf> so the SIGNAL DORMANT, should also have a SIGNAL-ACK DORMANT ?
17:40:48 <dcf1> arma1: yes, but if the whole point is to know whether it's going to be using a lot of battery, then "I know what you mean" isn't really what you want to know.
17:41:32 <dcf1> I.e., if Tor want to be able to print messages "In low-power mode" or "I want to be in low-power mode, but a PT is preventing me", then just syntactical support isn't the knowledge you want.
17:41:58 <arma1> yeah. i guess in your goptlib case, you want to be able to hear from the pt what it did, and tell that back to tor
17:42:03 <ahf> i mean, we cannot possibly technically enforce that the PT doesn't misbehave though?
17:42:16 <arma1> not just "message received" but "ok i acted on it in this way"
17:42:27 <dcf1> ahf: yes, what you propose cuold work, there's an API that the PT uses to request notification of dormancy, and if that API is used, goptlib advertises support for the feature.
17:42:44 <ahf> we cannot know what the PT did to act on it? the PT can implement all kinds of crazy things tor shouldn't have to know about?
17:43:02 <ahf> it should just know that it did what the developers thinks is the best to ensure that the PT doesn't use too many resources
17:43:07 <dcf1> ahf: yes, of course.
17:43:14 <ahf> dcf1: yeah
17:43:39 <ahf> okay, i think i have noted down now to try to come up with a spec change for a feature announcement/ackknowledge part during startup, then a signal'ing mechanism and a signal-ack'ing mechanism?
17:44:00 <dcf1> What I'm getting from this discussion is that the important knowledge that tor wants is whether the PT actually is making a best effort to go dormant.
17:44:48 <ahf> it's a binary state for tor itself i think, so i think we will see what the PT does as a binary thing as well
17:44:55 <ahf> (if that makes sense :-S)
17:45:54 <phw> should we wrap up this discussion and continue it on the mailing list?  we got 14 minutes left.
17:46:01 <ahf> yep, let's do that
17:46:09 <ahf> i'm gonna try with the things we have talked about it and continue on the ML!
17:46:12 <ahf> thanks a lot
17:46:28 <ahf> then nick can also join in if i miss something
17:47:41 <phw> gaba sneakily added a discussion point, reminding us that we should make sure that our roadmap is in sync with sponsor work: https://storm.torproject.org/shared/knaG2lEzepdsCC21DYk4dD4hRtwcUGnXQvalH1sKEAM
17:47:50 <arma1> cohosh: is there a trac ticket for "mitigate the misery if the snowflake you get is blocked in your country"?
17:48:05 <gaba> :)
17:48:28 <cohosh> arma1: yes it's a couple tickets
17:48:28 <gaba> not need for discussion, only a reminder
17:48:47 <cohosh> i'm working on #25429 right now
17:48:50 <cohosh> which i think is a big one
17:49:07 <cohosh> and will lead into #25723 which should also help
17:49:43 <cohosh> in fact my needs help with this week is for someone to do a quick check to see if my plan is heading in the right direction
17:50:43 * arma1 hands back control of mtg to phw and cohosh
17:50:46 <cohosh> oh wait dcf1 are you working on the multiplexing?
17:50:53 <cohosh> i just realized it is assigned to you
17:51:20 <dcf1> cohosh: not in this specific context yet, but the multiplexing in general is my next big project (not only in Snowflake).
17:51:30 <dcf1> that's why it's assigned to me, but you can take it over for Snowflake.
17:51:33 <cohosh> ah ok
17:51:50 <cohosh> if you have thoughts on a reliability layer i'm happy to hear them
17:51:59 <cohosh> i think it will help with #25429
17:52:16 <dcf1> yes, many, I even have some written down, we can talk about it another time.
17:52:21 <cohosh> ack, thanks
17:53:18 <gaba> oh, we didn't have #25723 in the roadmap. We are ok adding it too as s19 sponsored
17:53:37 <phw> arlolra also has a 'need help' section regarding his work on the webextension
17:53:45 <phw> https://trac.torproject.org/projects/tor/ticket/23888#comment:21
17:54:45 <arlolra> just needs someone to sign off on some of the refactoring
17:55:00 <cohosh> gaba: yeah i think it was not on the roadmap because dcf1 was working on it. i'm not really tackling it yet though, i'm going to work on #25429 for now
17:55:07 <gaba> ok
17:55:46 <dcf1> (actually it was the other way: it was not on the roadmap so I felt free to take it without interfering.)
17:55:57 <gaba> sounds good, thanks
17:56:45 <arma1> (quick, clear everything from the roadmap, and maybe dcf1 will take it all ;)
17:56:49 <cohosh> i can take a look a look at the webextension
17:57:19 <cohosh> i think dcf1 was already taking alook at that but i'm happy to check as well
17:57:47 <dcf1> cohosh: re #29734, I would be okay with doing a provisional deployment of 1 week or so, if that help the metrics team with evaluating the safety of what's being collected.
17:58:07 <dcf1> just to see what a typical metrics.log might look like.
17:58:21 <cohosh> okay if we do that I might remove it from /debug and just log it locally
17:58:32 <dcf1> good idea
17:58:42 <dcf1> (others feel free to disagree with provisional deployment)
17:58:55 <dcf1> also I'll say so on the ticket so there's a record.
17:58:57 <arma1> making forward progress, while things are low risk, seems good to me
17:59:04 <cohosh> cool
17:59:19 <phw> does anyone else need help or review?  are all your items covered cohosh?
17:59:28 <cohosh> yep i'm good :)
17:59:51 <phw> looks like we're done, just in time
17:59:53 <phw> #endmeeting