18:04:38 <isabela> #startmeeting tor launcher automation
18:04:38 <MeetBot> Meeting started Fri Jun  2 18:04:38 2017 UTC.  The chair is isabela. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:04:38 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:04:41 <isabela> nickm: thanks!
18:04:48 <isabela> great!
18:05:00 <isabela> first, thanks everyone for adding stuff to the doc
18:05:15 <isabela> here is the feature brief i am trying to keep updated as our discussion evolves
18:05:21 <isabela> https://docs.google.com/document/d/119plBq2oIeNS3okHCBNaBSqm_a1jJObYxKB_n6jodoQ/edit#
18:05:22 <mcs> I added some stuff at the very last minute – sorry!
18:05:26 <isabela> and this is the doc i am talking about :)
18:05:51 <isabela> i was thinking that for this meeting we should elect 1 (or 2 problems) to discuss and solve - and use a pad to take notes etc
18:06:12 <isabela> i have a suggestion of problem to discuss but i am open if folks prefer another one
18:06:24 <isabela> i also created this pad: https://pad.riseup.net/p/launcher-auto-prob
18:06:49 <linda> isabela:  tell us your preferred problem!
18:06:50 <isabela> the problem i would like to suggest is 7.C at the google doc, which i noted on the pad as well
18:07:25 <isabela> if moat happens before trying hardcoded bridges what happens if meeks is blocked and how we will go about the user experience on that
18:07:57 <isabela> i am raising thisproblem because i am more and more convinced that moat before hardcoded bridges might be the right path here
18:08:15 <isabela> ok i will be silent and let others say what they think :)
18:08:37 <isabela> (and if we have an agreement on which proble to talk about we move on to talk about that)
18:09:05 <linda> for reference:
18:09:09 <catalyst> i think quite a few people might be assuming that meek is the most likely proxy technology to work (it just happens to be the most expensive to operate), does that seem right?
18:09:12 <linda> "Moat - this is how we are calling the idea to present a captcha for the user to solve in order to get a bridge. Our idea is to embed what bridges site has: https://bridges.torproject.org/bridges on Tor Launcher window."
18:09:20 <sajolida> off-topic: Since it's my first To Launcher Automation meeting, I also have a few questions outside of problem-solving... Tell me when it's best to ask them. And I'm very happy to have been invited!
18:09:23 <isis> +1 on moat before hardcoded bridges, it's less blockable/fingerprintable, and also later (when there's hyphae) it all looks mostly the same (i.e. "someone is connecting to google/amazon/etc")
18:09:29 <linda> catalyst: I think so!
18:09:51 <linda> sajolida: it's the first one for all of us! and probably after the agenda. :)
18:10:05 * Samdney lurks
18:10:22 <GeKo> the problem with moat before hardcoding bridges is that it seriously diminshes the automation benefits
18:10:27 <linda> I am not a fan of it from the UX perspective. :(
18:10:30 <linda> GeKo: +1
18:10:39 <isabela> linda: actually is the 2nd meeting :)
18:10:42 <arma2> catalyst: meek is most likely to work, but also if everybody does it, it creates a pretty clear fingerprint and also a pretty clear bottleneck.
18:10:45 <linda> isabela: oh riiiiight
18:11:01 <mikeperry> mcs: wrt meek-client, how much have you worked on the current profile launching code in TBB? I am wondering if that is a better choice than the go meek-client, both for error reporting and for not being blocked
18:11:01 <isis> GeKo: which automation benefits?
18:11:04 <GeKo> it does not just work for the users anymore out of the box instead they have to solve a captcha first
18:11:05 <arma2> catalyst: privacy bottleneck i mean. whoever runs the huge website gets to see *all* the bootstrapping.
18:11:17 <isabela> sajolida: give us a min on deciding about this part and we can address other stuff after - how does that sound?
18:11:35 <GeKo> isis: that the users clicks on the auto connect button and behind the scenes everything is configured and the browser window pops up
18:11:37 <catalyst> arma2: we have multiple CDNs we use for meek right?
18:11:39 <isis> arma2: in this case, it's only using meek as a sort of C&C channel to talk to bridgedb
18:11:51 <GeKo> with a working bridge or not if a direct connection is enough
18:12:08 <sajolida> I was thinking that maybe we could do moat after trying a few hard-coded bridges only, like three. That would help with stop point #1: time to connection.
18:12:18 <GeKo> i bet that would work for 90% of our users right now
18:12:24 <GeKo> which wold be a huge win
18:12:25 <arma2> isis: yes, right, but still, remember the case where haystack tried to see if it had network connectivity by going to a state owned website.
18:12:37 <mcs> mikeperry: I am not sure what you mean by “how much have you worked on the current profile launching code in TBB?” But we can discuss the best choice later ;)
18:12:40 <linda> GeKo: +1
18:13:31 <GeKo> the problem with moat behind the hardcoded bridges step is: how do we ever reach the moat step?
18:13:32 <nickm> so, I'm really not comfortable with doing things that will get automatically blocked, and I think trying hard-coded bridges will get blocked by _existing_ censorship tech.
18:13:44 <isabela> sajolida: i like the idea of trying a limit set of hard coded bridges and then leave moat to happen after that
18:14:01 <isabela> nickm: good point
18:14:16 <catalyst> nickm: i agree. that's highly location-dependent though right?
18:14:22 <linda> nickm: good point.
18:14:40 <arma2> to be clear, if the user clicks auto, we try normal tor bootstrap, and all of this discussion is only for the case where that normal bootstrap fails, yes?
18:14:49 <GeKo> yes
18:14:53 <arma2> great
18:15:03 <nickm> ok, so if we're doing that, we don't actually care about china, right?
18:15:09 <nickm> or competent censorship?
18:15:12 <linda> arma2: oh I needed that clarification
18:15:15 <nickm> and this is just for dumb censorship?
18:15:27 <linda> nickm: I also need that clarification
18:15:39 <isabela> arma2: yes
18:15:50 <isabela> arma2: hopefully the graphs at the docs shows that
18:15:53 <isis> if we do the "try three bridges first" thing, china is just going to block people's connections for a few minutes, and then moat is not gonna work
18:15:55 <arma2> nickm: can you expand a bit on the not caring about china part?
18:16:05 <nickm> what isis just said above
18:16:21 <nickm> "Try the detectable thing first" will make us get blocked by...
18:16:25 <arma2> ok. so the worry is a censor that knows to look for the "cute little christmas tree tor behavior", and when it sees it, it knows to shut down that user for a while.
18:16:42 <nickm> ...anybody who takes a "when you detect anitcensorship, throttle or shut down the user for a bit" approach.
18:16:48 <isabela> https://drive.google.com/file/d/0B0Ke2fBu7_ALVHBaVXh6Wl9kX0U/view
18:16:51 <nickm> China's been known to do that at times and places
18:17:03 <arma2> so has iran
18:17:03 <sajolida> If we believe that hard-coded bridges will fail 90% of the time. Then what's the benefit of trying them to solve stop point #1? Or maybe only try them if, based on the location, we *know* that they have a change to success.
18:17:08 <mikeperry> so this is where making it possible to disable the various stages and ideally also reorder them is useful. I think we should at least have a pref that lets us say "skip direct connect, go directly to moat" in TBB that we can flip just for zh-CN builds
18:17:21 <isabela> arma2 linda - https://drive.google.com/file/d/0B0Ke2fBu7_ALVHBaVXh6Wl9kX0U/view
18:17:26 <nickm> if we take this "loud than quiet" approach, and we expect it will work in china or iran, then we are fooling ourselves.
18:17:29 <isabela> hopefully this will help understand the steps
18:17:34 <nickm> I'm okay with saying "let's do a dumb thing first"
18:17:40 <mikeperry> and then later, in V2, we expand that to country detection and Doing the Right Thing, based on OONI data
18:17:43 <isis> so this sort of implies two (or more?) user flows: 1) if you're in a non-censored place, try N hardcoded bridges before falling back to moat 2) if you're in a censored place, do moat and fallback to hardcoded
18:17:47 <nickm> i'm okay with saying "let's do a stupid thing to fight stupid censors"...
18:18:17 <GeKo> isis: we could think about that, yes
18:18:28 <nickm> but if we actually want to make this easy for people facing a competent adversary, we can't take the "loud first, quiet second" approach for them.
18:18:41 <catalyst> i guess this means we need a better idea of "what is V1 _not_ trying to do"?
18:18:59 <arma2> nickm: does "when you click auto, tor starts by trying to bootstrap normally" already count in your "loud" category?
18:19:00 <isis> mikeperry's idea for prefs is good
18:19:10 <isabela> nickm: what do you think about the solution mikeperry is talking about
18:19:15 <nickm> arma2: yes
18:19:20 <arma2> great
18:19:45 <GeKo> i like the preference idea
18:19:46 <catalyst> mikeperry: what kind of pref? user-editable?
18:19:49 <nickm> isabela: if I understand, mike's idea is to have a "loud first" mode and a "quiet first" mode, and to choose between them based on increasingly smart heuristics?
18:19:52 <GeKo> we could at least experiment with it
18:19:53 <nickm> that seems ok
18:20:03 * linda nods
18:20:23 <arma2> mikeperry: btw, many people in china don't use the zh-cn builds, because the translations are bad enough that they use english instead. not a deal breaker, but something to keep in mind.
18:20:42 <GeKo> or the fonts in tor browser suck
18:20:46 <isis> if we say "moat == 1" and "try hardcoded bridges == 2" and "other thing == 3" then TB can ship configs like "zh_CN: 1,3,2; en_US: 2,3,1; etc"
18:20:48 <mikeperry> catalyst: TBB about:config pref.
18:20:51 <isabela> arma2: good point
18:20:52 <arma2> geko: oh hey, or that too.
18:21:11 <mikeperry> arma2:  yeah, stopgap until we get country detection working for V2
18:21:23 <isabela> isis: +1
18:21:39 <linda> isis: +1
18:21:39 <arma2> isis: i would expand your list to say "0 == normal tor boottrap", and then put 0 in the ordered list somewhere
18:21:46 <linda> arma2: +1
18:21:48 <sajolida> Like saying "for zh-CN builds we do this and that".
18:21:58 <sajolida> arma2: I was going to say this. Beware not to assume to much regarding
18:21:58 <sajolida> language-country mapping. Like saying "for zh-CN builds we do this and
18:21:58 <sajolida> that".
18:21:58 <sajolida> I bet lots of people use Tor while travelling, use Tor in English if
18:21:58 <sajolida> they know English because translations are partial or bad, etc. Some
18:22:01 <sajolida> languages are spoken in many countries (French in Africa, Spanish in
18:22:03 <sajolida> America, etc.).
18:22:27 <nickm> +1
18:22:28 <mikeperry> yeah, this is discussed in the V2 part of the doc (a pref that defines ordering of panes based on country detection, not locale)
18:22:29 <catalyst> to help future readers, maybe we could add a high-level overview of what things each implementation phase is and is not trying to do?
18:22:46 <linda> catalyst: that is a good idea
18:23:20 <arma2> so, we are heading towards "part one, teach tor browser how to do attempts in a variety of orders, and make it easy to specify what order", and "part two, we'll work on good interfaces for users to get the right order"?
18:23:36 <isabela> sajolida: +1
18:24:00 <sajolida> Also, how do we convey to users that different builds lead to different anti-censorship properties *before* they download and try them?
18:24:04 <catalyst> arma2: i think that matches my understanding so far
18:24:19 <linda> arma2: that is my understanding as well
18:24:28 <linda> sajolida: I am not sure we need to specify this
18:24:35 <isabela> catalyst: that doc is trying to do that - things will change after this meeting probably - but it has some info of other phases
18:24:41 <arma2> ok. i think having tor browser know how to do various bootstrap attempts is a great building block.
18:24:53 <linda> sajolida: we can specify that things will work better, but not go into the details.
18:25:02 <linda> arma2:  yes, that is really brilliant.
18:25:48 <arma2> i would be tempted to, if we're doing the dumb thing first, try to do a dumb thing where it's more obvious to the user that a decision is being made
18:25:49 <isis> sajolida: there will always be a "manual configuration" mode for all users of any place/language
18:26:03 <arma2> the one where the language bundle they pick dictates the decision is sure going to be surprising to them
18:27:07 <linda> we can label things by censorship environment rather thatn languages, which could help
18:27:14 <arma2> where are we on the "just have auto do the thing that works for most people, but not for china and iran, and have an "advanced" button or something for now, and later we try to have something that works for china and iran"?
18:27:43 <arma2> that is, auto chooses 0,1,2,3 or 0,2,1,3 or whatever we decide to do as our first try.
18:27:55 <isabela> arma2: we will always keep the flow that has manual configs
18:28:03 <linda> hmm
18:28:09 <arma2> then the manual config option would let you choose the ordering
18:28:36 <isabela> arma2: for now i was thinking of just using the flow that linda suggests on her paper
18:28:38 <GeKo> i don't think so
18:28:43 <linda> I am now thinking that maybe we should ask the user to choose betwen 0,1,2,3 or 0,2,1,3. In general, and not have different versions do different things, which is confusing.
18:28:49 <isabela> arma2: not pick an ordering but just the normal path we hav enow
18:28:54 <linda> We can just ask the user "where are you?" and let that map to a strategy
18:28:56 <mcs> Presumably, our users in Iran and China have to use manual today (so we will ask them to keep using it for a while longer).
18:28:57 <GeKo> yes
18:28:59 <isabela> arma2: https://drive.google.com/file/d/0B0Ke2fBu7_ALVHBaVXh6Wl9kX0U/view
18:29:18 <linda> I am also a fan of my own flow. but I am biased and I have been wrong before
18:29:26 <GeKo> (my "yes" was to what isa said)
18:29:33 <isabela> mcs: yes, manual == what ppl have to do today, but with the improvments linda suggests on her paper
18:29:39 <GeKo> yes
18:29:42 <mcs> isabela: right
18:30:09 <arma2> i think auto *needs* to try 0 first, right? so if we are worried about the christmas tree light effect, where people notice you clicked auto.. that is just something we have to accept, right?
18:30:10 <isabela> so first choide for the user will be 'auto' or 'manua' or whatever we want to call them
18:30:16 <mikeperry> I don't think we should ask he user where they are if we can avoid it. and I think on most platforms, we can (without looking at locale)
18:30:23 <isabela> *manual
18:30:32 <isabela> arma2: 0 == dir connect?
18:30:33 <mikeperry> fewer questions => better
18:30:41 <isabela> arma2: if so, then yes, auto is doing that
18:30:43 <arma2> 0 == direct connect, yes. linda's first box after auto.
18:30:43 <sajolida> linda: +1, Asking for the country might look awkward but my be a better first step thanhaving different config on different builds. Version 2 will solve this awkwardness.
18:30:58 <sajolida> s/my/might/
18:31:03 <GeKo> mikeperry: there are mozilla apis we probably can use for getting a good understand of where folks are
18:31:04 <catalyst> mikeperry: are you thinking probing OS settings to infer geographic location?
18:31:16 <GeKo> iirc mozilla used that for search engine selection
18:31:36 <sajolida> Probing OS seetings won't work in Tails :)
18:32:05 <sajolida> but maybe that's an appropriate threadoff for a first guess
18:32:55 <mikeperry> does Tails ask people their timezone, or is everything UTC?
18:33:25 <arma2> let me try my point again. auto needs to start with step 0, direct connect, right? and if so, the game is over if the chinese user would be more subtle doing step 3 rather than step 2, because they've already done step 0, direct connect.
18:33:30 <GeKo> arma2: well, we could think about skipping 0 for folks in china
18:33:44 <arma2> hm!
18:34:10 <isabela> yep
18:34:12 <sajolida> mikeperry: not *yet* but we want to do that at some point, so that would work indeed
18:34:19 <isabela> that is the reason we are thinking how we find out folks are in china
18:35:09 <isabela> sajolida: cool
18:35:17 <arma2> so the alternative would be to try to figure out where they are, e.g. in a country selector where we could try to be smart and auto select the right country if possible, and then the choice of country dictates what auto actually does.
18:35:21 <catalyst> so do we agree that phase 1 isn't going to (automatically) help people in China?
18:36:02 <isis> catalyst: correct, phase 1 won't help anyone in china
18:36:08 <isabela> catalyst: as it is now , yep. but we could change it to address that
18:36:15 <GeKo> exactly
18:36:32 <isabela> that is why we are thinking of asking for the country first
18:36:40 <isabela> or trying to figure out the country if we dont want to ask
18:36:56 <isabela> if we can do that we could address the users in china issue
18:37:05 <arma2> i would kind of hope we do both. that is, even if we try to figure it out so we don't have to ask, we just use what we figured out as the default, when we ask.
18:37:14 <isis> (my main interest in phase 1 is making sure it doesn't introduce something that messes up phase 2 for chinese/iranian/etc users)
18:37:41 <linda> I am a fan of asking for something, because it kind of is a form of consent. Havign users pick a country and click "connect me" seems like a good use of a window, rahter than jargon and clicking a button "I understand the risks of connecting"
18:37:43 <isis> i liked the idea to try to auto-select the correct country from a dropdown/autocomplete list
18:38:04 <arma2> linda: how are you feeling about a drop down box or whatever where the user selects her country? and we can make it give them our first guess at their country automatically, e.g. by language choice or whatever
18:38:48 <sajolida> isi: Right, guessing and asking are not exclusive. We can guess and propose to refine or correct.
18:38:55 <arma2> right.
18:39:02 <isabela> one thing to think about re:asking user for their country -> if user gives an answer that is not true, e.g. i am in china and i say i am in honduras because your question creeps me out
18:39:05 <isis> yep
18:39:11 <isabela> than we will be trying the wrong thing for the user for a while :)
18:39:17 <arma2> that's fine, i think.
18:39:18 <linda> arma2: that sounds good to me, initally. I'd need to think about how it's done and test it to be sure
18:39:22 <arma2> you get to pretend you're in honduras if you like.
18:39:28 <nickm> also let's remember that censorship is not uniform per country.  universities have different rules than areas with mistrusted minorities have different rules from the capital during an election
18:39:45 <nickm> this won't be an easy UI to figure out
18:39:49 <linda> hmm
18:40:03 <catalyst> so it's starting to sound to me like we're expanding the scope of phase 1 to cover some of phase 2, which is fine, but i'd rather we did so intentionally (or someone can tell me how i'm misinterpreting)
18:40:04 <linda> The coolest thing to do is just to do one thing that works all the time. :(
18:40:16 <linda> catalyst: hmm good point
18:40:18 <nickm> yeah
18:40:21 <arma2> this is true. if we don't have that many possible orderings, i wonder if we might just give them a choice between three bootstrap options, slider style.
18:40:26 <GeKo> catalyst: i think you are right
18:40:39 <isis> nickm: +1
18:40:40 <arma2> or the slider style is done in the manual section, and auto uses the setting of the slider that works for lots of people.
18:41:21 <isabela> nickm: i agree, but we will always have fall back (like if I pick US as my country and I am in detroit univ, which blocks tor, tor will try direct connect because i am in the US and then it wont work and it will try step 2 (moat or something))
18:41:42 <arma2> taking a step back. one of the cool things about the current "phase 1 auto" is that tor browser gets to learn how to do each of the attempts. and we want that for all future designs i think?
18:41:53 <isis> the slider would get more complicated as we add things to try, since you can't really linearly order (1,2,3,0) (0.1.2,3) (2,3,1,0) etc
18:42:17 <Samdney> +1
18:42:20 <nickm> arma2: I think that's true.  "Try different things in different orders" is a feature we know we'll want
18:42:31 <isabela> yep
18:42:39 <arma2> isis: right, but we wouldn't need all permutations, we would only need whatever countries we were going to handle. (i think the slider idea is not best.)
18:42:52 <catalyst> the set of orderings that makes sense is still going to be smaller than the full permutation set, i hope
18:43:04 <arma2> isis: i.e., if there is no country for which we would say "3,2,1,0", then there's no setting for that.
18:43:29 <linda> I think we should abstract the details of the ordering from the user
18:43:45 <nickm> yeah.  "please drag the options on this list into the order you would prefer Tor to try them" is a little to close to "please enter into this text box your best idea for defeating censorship; we're out of ideas!" for my taste ;)
18:43:49 <linda> they don't need ot know that much--they just want to know what to choose that'll work, and if it changes their risk
18:44:13 <nickm> "press this button to open the source code and reprogram tor"
18:44:15 <nickm> ;)
18:44:15 <isabela> i hope we do abstract that from the user
18:44:40 <isabela> ok
18:44:45 <isis> catalyst: yeah, hopefully there's way less options than permutations, but still linear ordering for "how censored" is a slightly awkward concept (imho)
18:44:55 <arma2> agreed.
18:45:09 <isabela> i got a lot of good stuff so far - discussion has moved towards good direct in relationship to how to solve this problem. i want to make a time check
18:45:15 <isabela> is 15min till the hour :)
18:45:27 <isabela> how ppl are feeling?
18:45:38 <arma2> finally starting to understand the plans a bit :)
18:45:42 <isabela> heheh
18:45:47 <GeKo> yay
18:45:47 <isabela> that is good :)
18:45:50 <linda> I feel productive!
18:45:59 <linda> But also need to go in 15 so wanna do things :P
18:46:23 <arma2> to be clear, is 'version 2' a thing we plan to build on top of 'version 1'? or is it an alternative?
18:46:32 <sajolida> List of countries could be displayed in the abstraction: "$FANCY_NAME (3,2,1,0) Works best in Tanzania and Thailand". And we're not asking for the country so explicitly.
18:46:32 <isabela> on the top of it
18:46:43 <sajolida> I'm fine to continue.
18:46:59 <isabela> arma2: but probably will change now after this discussion
18:47:03 <isabela> ok
18:47:08 <arma2> ok. so it sounds to me like trying to ask for, or guess, the country is part of version 2?
18:47:10 <isabela> maybe now is a good time sajolida for you to present your question?
18:47:17 <arma2> unless we are unwilling to build a version 1 that doesn't have that?
18:47:19 <sajolida> isabela: Ok :)
18:47:22 <GeKo> sajolida: that sounds like an interesting idea
18:47:25 <isabela> arma2: it was before this meeting, might change now
18:47:50 <sajolida> #1: What kind of network connections will Tor Launcher initiate *itself* (as opposed to asking little-t-tor to)? None?
18:47:54 <isis> i am kind of imagining the user would click "auto" and then it tries to guess country, asks what country, and then (maybe) has a "do you want to 1) try to be super sneaky (this might not connect) or 2) do anything and everything to try to get online (this might cause you to get noticed/blocked)"
18:48:50 <isis> and then #1 is something like (3,2,1,0) and #2 is something like (0,2,1,3) or whatever
18:48:58 <arma2> isis: i agree that there are two wildly different use cases for tor ("reachability vs safety"), and trying to auto do the right thing for both user categories is super hard.
18:49:18 <isabela> sajolida: can you explain a little more, i dont understand sorry
18:49:28 <catalyst> isis: i think that's great for user agency. i don't know that there's a good way to ask that in a way that gets useful answers from most users
18:50:08 <arma2> as an example of sajolida's question. let's say tor launcher wants to use moat to get a captcha for a bridge. it uses meek to get the captcha. what launches meek?
18:50:11 <sajolida> Is the plan to adapt core tor enough so that all the trial and error are done by core-tor itself? Or is Tor Launcher doing to initiate *some* network activity on its own will doing the trial and error?
18:50:16 <isabela> sajolida: are you asking if this will change on the network side or just the tbb side
18:50:18 <linda> arma2:  this reachability vs safety thing is the real problem
18:50:27 <isabela> sajolida: tor launcher side
18:50:30 <linda> catalyst: +1
18:50:47 <isis> catalyst: yeah, that's true
18:51:30 <arma2> that divide was the original motivation for connect vs configure in tor launcher, btw. connect was for the reachability people, and configure was for the safety people.
18:51:40 <arma2> but then we didn't provide any good things for the safety people to do.
18:51:43 <isabela> one more thing before we all go away ( sajolida if you have more questions please ask )
18:52:00 <isabela> next step here will be: 1. update the brief reflecting this discussion
18:52:23 <isabela> i hope to work with linda on some possible paths like the one isis suggested
18:52:31 <isabela> and add graphs showing them there for the next meeting
18:52:34 <linda> :)
18:52:38 <linda> o/
18:52:39 <isabela> and share this with the email thread
18:52:43 <linda> sounds good
18:53:04 <isis> sajolida: i think we are not sure where some parts of the work fall, but Tor Launcher will definitely need to be able to use meek-client to talk to bridgedb
18:53:05 <isabela> i think once notes are down in the brief we will see if we capture the understanding that everyone has of v1
18:53:09 <GeKo> sajolida: i think that's not clear yet
18:53:20 <isabela> and be able to start writing the tasks for implemeting it
18:53:23 <GeKo> what isis said
18:53:34 <sajolida> isis, GeKo: fully understandable!
18:53:35 <isabela> and then we will be able to start breaking down these tasks in a timeline
18:53:43 <sajolida> #2: for linda, regarding the implementation steps: What does "Perform QA once TBB team is ready" mean?
18:53:46 <sajolida> It seems like you're going to do a software prototype? Why not play with a paper prototype first, based on Linda's wireframe?
18:56:07 <isabela> sajolida: is this based on the task at the doc?
18:56:17 <sajolida> isabela: yeap
18:56:35 <isabela> we probably have to refine those but we have played with some user testing with alpha releases
18:56:47 <isabela> we did a small one for orfox security slider
18:56:59 <isabela> i put that there thinking of something similar
18:57:28 <isabela> hopefully we will be able to coordinate with the community team on that so we can have a good diversity of demographic etc
18:57:33 <isabela> testing it for us
18:57:46 <isabela> linda provided a nice script/methodology when we did it for orfox
18:57:46 <sajolida> in "If possible organize user testing in multiple countries or simulating different scenarios", what kind of prototype are users going to test?
18:58:19 <isabela> i dont have an answer yet, that depends also on tbb team bandwidth
18:58:21 <arma2> big picture question re tor launcher vs the "meta" process that future sandboxes might want: should we just ignore that idea here? or is there a way to make more of our work here reusable for that future situation?
18:58:28 <isabela> could be the alpha version of tbb which this feature
18:58:37 <sajolida> but anyway, count me in for testing in the languages I speak :)
18:58:45 <isabela> sajolida: yay!
18:58:56 <sajolida> and my last question, #3: Any news on the possible language and coding dependencies for this new Tor Launcher? How easy is it going to be to reuse it in Tails? :)
18:58:58 <isabela> s/which/with
18:59:02 <GeKo> arma2: i think ignore, alas
18:59:09 <catalyst> arma2: by "meta" process do you mean sandboxing the controller interface so a single tor process can be shared by mutually untrusted apps?
18:59:34 <isabela> sajolida: that is a question for GeKo and mcs  i guess :)
18:59:44 <isabela> but maybe too soon to answer
18:59:51 <arma2> catalyst: no, i mean being able to run tor browser on windows while properly sandboxing the browser, which involves not giving it permission to overwrite itself, which implies having some *other* process that really runs things.
19:00:13 <linda> I got a skype call, but I'll read these logs after~
19:00:22 <isabela> thanks linda o/
19:00:22 <linda> and will still lurk here
19:00:30 <arma2> geko: ok. ignore is not terrible, i think, since a lot of the design work is reusable.
19:00:40 <mcs> Given the timeframe for version 1, I assume we do not have time to create a completely new launcher thing.
19:00:41 <GeKo> sajolida: there is no new tor launcher yet :)
19:00:55 * nickm is fading, but will still lurk
19:01:02 <mcs> But yes, we have not done any coding for this yet :)
19:01:16 <isabela> alright folks
19:01:25 <isabela> we are achieving the hour
19:01:37 <isabela> ppl need to eat, for some folks if friday night and the party is starting :P
19:01:41 <isabela> so maybe we call it for now?
19:01:44 <sajolida> GeKo, mcs: ok, thanks!
19:02:01 <sajolida> yeap, i'm done
19:02:19 <isabela> alright! thanks again everyone for coming up and help out with the discussion
19:02:23 <isabela> it was very productive
19:02:29 <isabela> will stop  the bot now
19:02:35 <linda> ^_^
19:02:41 <linda> yes, very helpful meeting.
19:02:46 <isabela> #endmeeting