19:01:30 <mikeperry> #startmeeting app-dev
19:01:30 <MeetBot> Meeting started Tue Dec  1 19:01:30 2015 UTC.  The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:30 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:01:51 <mikeperry> who do we have today?
19:01:58 * arthuredelstein is here
19:01:59 * dcf1 /me
19:02:16 <mikeperry> oh wow a dcf1 appears!
19:02:18 * mcs and Kathy are here
19:02:40 * nmalkin is lurking
19:03:47 <mikeperry> nmalkin: what do you work on?
19:04:36 <nmalkin> mikeperry: I've been working with dcf1 and lnl on UX improvements for Tor Launcher
19:05:01 <asn> !!!
19:05:11 <asn> sounds great :)
19:05:12 <mikeperry> ah, great!
19:06:05 <mikeperry> have you guys planned your studies yet?
19:07:02 <mikeperry> I remember thinking back during PETS that we would have domain fronting for bridgedb by now-ish, but OTF delays unfortunately killed that timeline completely
19:07:15 <nmalkin> We've finished the qualitative interviews, are currently iterating on the designs that we want to test, and plan to start quantitatively evaluating them in a few weeks.
19:07:48 <nmalkin> lnl just sent out a nice summary to ux@
19:08:11 <dcf1> The idea is to prototype a new interface based on what we've found so far, and then compare it with the current interface in a larger group of participants.
19:08:22 <nmalkin> https://lists.torproject.org/pipermail/ux/2015-December/000002.html
19:08:49 <mcs> Thanks for sharing the info about what you have done so far. Interesting stuff.
19:09:06 * arthuredelstein finds he has to run but will read the meeting transcript later
19:09:40 <mcs> I think we may be able to make some small improvements while waiting for the bigger test results but we will have to see if that makes sense.
19:09:48 <mikeperry> woah, we got a UX list. I completely missed that :)
19:09:57 <dcf1> mcs: I think so (small improvements).
19:10:28 <mcs> Kathy Brade or myself plan to respond on the UX list later today or tomorrow.
19:11:22 <mcs> BTW, the github site has demographic info available that probably should not be (e.g., participant's email addresses)
19:11:51 <mrphs> mikeperry: https://lists.torproject.org/pipermail/tbb-dev/2015-November/000328.html ;)
19:11:52 <dcf1> mcs, thanks, we didn't know but will take care of it.
19:11:57 <nmalkin> mcs: oh, that's a problem, thanks for flagging it!
19:14:35 <dcf1> The upshot of all this for the applications team is
19:14:58 <dcf1> just to be aware that we're working on this and plan to prototype some changes to the Tor Launcher UI,
19:15:33 <dcf1> and that we'll likely want your help in the coming months for review and implementation help.
19:16:01 * meejah lurks
19:16:35 <thinkxl> I'm lurking too, I just spoke a little with mrphs
19:16:40 <thinkxl> couple days ago
19:17:21 <mrphs> dcf1: are this changes specifically for bridge settings?
19:17:34 <mrphs> or Tor Launcher in general?
19:19:22 * mrphs wonders if isis is around..
19:19:38 <dcf1> mrphs: we are focusing on bridge configuration.
19:19:57 <dcf1> Our E1, E2, E3 are simulated censors of increasing difficulty.
19:20:24 <dcf1> We're telling them that their connection is censored and they have to use Tor Browser to visit a web site.
19:20:25 <mikeperry> nmalkin,dcf1: so is your plan to test flows where obfs3 always works, or will you test the need to find a working bridge that is not obfs3 or not a default bridge at all?
19:20:33 <dcf1> mikeperry:
19:20:40 <nmalkin> the latter
19:21:02 <dcf1> E1: DNS-only censorship, only need to click "Connect" (or use any bridge).
19:21:25 <dcf1> E2: DNS censorship and relays blocked (need to use any default bridge)
19:21:42 <dcf1> E3: DNS and relays and default TB bridges blocked (need to use meek or a custom bridge from BridgeDB).
19:21:58 <nmalkin> right, so I should've said, all of the above. :-)
19:22:11 <dcf1> E3 is quite hard and E1 is basically equivalent to getting TB to work at all.
19:22:39 <dcf1> We're not testing any proxy settings.
19:22:54 <mcs> The solution for E3 is either a meek bridge or a custom one, right?
19:23:16 * isis is around
19:23:19 <dcf1> mcs: correct.
19:23:28 * isis is catching up
19:23:46 <dcf1> One participant even registered an email address in order to access bridgedb during the experiment.
19:24:16 <mcs> While reading your participant summaries, I start to wonder what percentage of our users need proxy settings (as in, is it low enough to bury the proxy settings more?)
19:24:47 <mrphs> yeah i was thinking exactly about that.
19:25:01 <dcf1> Many users do get stuck in the proxy trap.
19:25:05 <isis> (the one who created the email address had some trouble, hence #17626)
19:25:13 <mcs> I guess we cannot spy on our users to obtain data about proxy use ;)
19:25:15 <dcf1> They are suprisingly (to me) adept at looking for the proxy settings in other browsers.
19:25:16 <mikeperry> probably the ones that need them use PAC (proxy autoconfig)
19:25:29 <dcf1> Problem is, in other browsers, when you don't need a proxy, there's nothing that really says that.
19:25:56 <dcf1> Firefox by default has "Use system proxy settings," which still left people confused as to whether they need to enter proxy settings in TB.
19:26:46 <dcf1> Autodetection of proxies (especially autodetection of *not* needing a proxy), with a manual override, would probably help a lot. Or importing from another browser.
19:26:49 <mcs> And Chrome and IE probably *only* support use of system proxy settings? (I am not sure if that is true in Windows)
19:27:20 <dcf1> mcs: I think so. On Windows in Chrome, if you change the proxy settings it opens up the IE Internet Setting dialog.
19:27:58 <mcs> dcf1: OK. On Mac OS, Chrome does something similar: it opens the Network panel with System Preferences
19:28:01 <efra> true
19:28:39 <dcf1> People were confused by the bridge screen (especially the transport names), but the proxy screen was more of a tarpit (my impression).
19:28:40 * mrphs needs to change loc - brb 5mins
19:29:42 <mcs> The other simple take away is that we do not help people with the next step after they try a bridge and it fails. Even something that said "If the bridge you try first does not work, try a different one" would be helpful.
19:30:17 <mcs> (a lot of people went in circles)
19:30:26 <dcf1> That's true.
19:30:48 <dcf1> In the prototype interface we want to use the bootstrapping percentage to give users more helpful error messages.
19:31:09 <dcf1> For example, as an expert user, I know that if bootstrapping reaches 15%, then it's going to succeed eventually, even if slowly.
19:31:24 <mcs> One thing I do not understand about the prototype is the dividing of the progress bar. Can you explain that idea?
19:31:29 <dcf1> But if it stops at 5% or 10% then it's likely that I need a different bridge or I need to check my network connection.
19:32:34 <dcf1> I think the idea there is to give better feedback about what to do.
19:32:46 <nmalkin> mcs: rather than vague percentages, we wanted to emphasize concrete milestones (e.g., you were able to communicate with the directory authority)
19:33:04 <dcf1> One participant hit cancel when it was 50% bootstrapped, because it appeared to be stalling, whereas I was saying to myself, just be patient.
19:33:13 <nmalkin> We discussed having visual representations of each step/hop (and that may end up returning).
19:33:40 <nmalkin> and yeah, the overall goal is to provide better, and more actionable, feedback
19:33:46 <mcs> We should tell people (in the UI) that it may take several minutes to make the connection and that it may appear to stop making progress for a while.
19:33:58 <dcf1> (That same participant then hit cancel, and then clicked "Connect" on the first screen, and then thought that they had connected without using a bridge because of the text on that screen, when in reality it was resuing their bridge configuration from earlier.)
19:34:29 <mcs> Yeah, old settings should not be used without the user knowing it.
19:34:36 <dcf1> mcs: that was common feedback. "Is this supposed to take 10 seconds or 10 minutes?"
19:34:41 <nmalkin> mcs: yes, I think that would be an easy-to-make but powerful improvement. There were many comments about how people had no idea how long to wait.
19:34:59 <mikeperry> sometimes bootstrapping makes it to 25% and hangs, if your system clock is off by more than a few hours. I hit that one a lot, actually
19:35:13 <mikeperry> there are probably a few other corner cases like that
19:35:27 <dcf1> mikeperry: that's true. That happened to P8 because of an error in our setup.
19:35:43 <mcs> Does anyone know how long it is reasonable to wait in the worst case?  Is that hang when clock skew is present a "forever hang?"
19:35:53 <mikeperry> if a dirauth is down(like urras has been) then you can hang at one of those percents for a minute before it tries another one (though that is a tor bug that teor is working on fixing)
19:36:10 <dcf1> I didn't know what was going wrong until I looked at the log file.
19:37:05 <dcf1> If the clock skew is common, that at least is something that appears in the logs and could get a special error message.
19:37:45 <mcs> dcf1: There is an open ticket about special error message in the clock skew case.
19:38:08 <dcf1> mcs: oh, good to know, I'll find it.
19:39:00 <mcs> See #9675
19:40:25 <mikeperry> so for E3, I am still hoping long-term to have a UI that makes the process of finding a new custom bridge all happen inside the browser
19:41:26 <mikeperry> and go over a domain fronting or WebRTC chanel to a BridgeDB JSONP API
19:42:04 <mikeperry> so this would sort of be like E3 when the user chooses meek, except being asked to solve a captcha
19:42:52 <dcf1> mikeperry: yah, I guess there would be a "Get bridges" button or similar that then fills in the text box for you.
19:43:18 <mikeperry> and once they solve the captcha, TBB would send the solution to BridgeDB to get some bridge lines and enteres them in for you behind the scenes, and then tests them in series
19:43:44 <mikeperry> for a few different transport types, until it finds one that works
19:44:34 <mikeperry> isis finally got her OTF proposal approved to do the BridgeDB side of this. so it should happen eventually
19:44:49 <isis> \o/
19:44:51 <mikeperry> but I am not sure how the timelines are going to work out for it now
19:44:54 <dcf1> I'm hoping to work with isis on that.
19:45:12 <isis> dcf1: that would be awesome, please
19:45:45 <mrphs> this meeting is the best thing has happened today so far
19:45:45 <mikeperry> do you think you will be able to test some version of that experience when you make your prototypes for the quantitative testing stage?
19:45:49 <mcs> The part where Tor Browser tests the bridges and determines which one works seems like something that will require tor daemon changes (I don't know for sure).
19:46:23 <isis> if little-t tor changes are required, i have funding allocated to making those changes too
19:47:00 <mcs> isis: Good news! :)
19:47:06 <mikeperry> mcs: I think we'd just use the same bootstrap events as we currently do (though maybe with some help from #9675 to determine if it is actually a local error that will happen regardless of bridge)
19:47:16 <isis> err, i made that funding be pretty vague, it's something like "do little-t tor stuff that helps bridges or their usage"
19:47:23 <mrphs> dcf1: do you remember the idea we talked about at the OTF summit? of doing some sort of probing and see which bridge works best? do you still think that's a feasible idea?
19:47:25 <dcf1> mikeperry: I'm not sure, we don't have a firm timeline for the quantitative tests yet.
19:47:36 <dcf1> I think it partly depends on how long it takes to prototype.
19:48:34 <mikeperry> mcs: so TBB would just ask BridgeDB for some bridges of a certain type, then try them, see if bootstrapping succeeds, and if so, win; if not, ask for some more bridges of a different type
19:48:40 <isis> if there's anything needed from me to make the prototype happen faster, please let me know
19:49:07 <isis> e.g. #15967 or something
19:49:21 <isis> but that could be mocked too, i suppose
19:49:23 <dcf1> mrphs: I think it's a feasible idea, though as mcs says, doing something like that probably requires tor changes.
19:49:25 <mcs> mikeperry: It might work. But I think there will be unexpected problems. Hopefully I am wrong ;)
19:49:37 <dcf1> Mockups are fine for these prototypes.
19:50:00 <dcf1> I.e. if we add a button that should make things work, we can just have it change a secret setting that makes things work.
19:50:20 <mcs> We will definitely want to give feedback to the user along the way since the probing may take a long time.
19:50:47 <mcs> Actually, maybe this should all be built into little-t tor so it can be used by everyone.
19:51:40 <mikeperry> little-t-tor's bridge handling logic is pretty lousy, and about to be torn out I think. I suppose it could be redone
19:52:10 <mikeperry> it basically tries to connect to every bridge or guard you have all at once
19:53:00 <mikeperry> where as the right thing to do (IMO) is to try all the bridges by type, and proceed through the transport types in some order based on country/locale guess, and then stick with only the one that works
19:53:19 <mikeperry> so you are not constantly bleeding like 7 different types of tor-like traffic all the time
19:53:52 <dcf1> One thing that makes the iteration through transports awkward (from the tor side) is that bootstrapping messages are only increasing.
19:54:13 <dcf1> This actually confused a lot of people re the progress bar.
19:54:14 <mikeperry> and then, the controller should try to maintain a reserve of N working bridges
19:54:25 <dcf1> If progress gets to 50%, and then you cancel, and try again,
19:54:40 <mikeperry> if the number drops below N, it does the JSONP thing to BridgeDB again, but only for the type known to work
19:54:48 <dcf1> the progress bar appears to be at 0% until tor emits a message about it being 55% or something.
19:55:27 <dcf1> Whereas with a bridge, it's either 5% or 10% where you connect to a bridge and download directory information, and that's where you expect things to fail if they do.
19:56:00 <dcf1> So it would be cool to have a way to have independent trials for each transport that you're iterating.
19:56:07 <dcf1> But I haven't thought much about that yet.
19:56:54 <mcs> Kathy and I noticed that problem in your participant summaries too. The thing about starting at 0% may be a bug, Or maybe we should convince little-t tor to really start from scratch.
19:57:04 <dcf1> Thanks everybody.
19:57:07 * dcf1 is out but still listening.
19:57:14 <isis> mikeperry: is there a ticket yet for the retry/bootstrap connection logic w.r.t. bridges?
19:57:24 <dcf1> (I appreciate everyone's hard work and how much you all care for users.)
19:57:47 <isis> i guess this is part of #17626 maybe
19:57:57 <isis> err, i meant #17262
19:59:25 <thinkxl> this is amazing, just saying. If there is a need for a UI/UX web guy I can help
20:01:05 <mikeperry> isis: yeah, I guess that would be it, if we decided to keep it in little-t-tor. it still feels like a controller-heavy thing to me though.
20:01:47 <mikeperry> esp since I think it's unlikely that it will be possible to build the domain fronting + JSONP piece into little-t-tor easily, but it would be a piece of cake in a higher-level language
20:04:03 <mikeperry> so the other thing I wanted to cover was a quick brainstorm/braindump of all of the current apps and prototypes that exist in the wider Tor ecosystem that we like
20:04:20 <mikeperry> so we can showcase them on a Tor Labs site
20:04:25 <mikeperry> https://storm.torproject.org/shared/0MzIellWOkgzfhjG5FL6z7e5YRjrowmK79EF3Q66IJe
20:04:28 <mcs> When I mentioned little-t-tor earlier I was thinking the domain fronting + JSON would not necessarily be there but the "try these bridges and find out which one works" part could be.
20:04:43 <mikeperry> that's my current brain-dump
20:05:21 <mikeperry> mcs: yeah, that would make sense, and it probably does make sense to do that as part of #17262, since it is the same code in tor for bridges and guards, effectively
20:07:04 <mikeperry> so that share link allows comments in the chat but not edits, FYI
20:07:59 <mikeperry> the chat can be made visible if you click on the gear in the top right
20:10:39 <mikeperry> (I finally got https://github.com/patcon/mission-impossible-android more or less working again with Cyanogen 12 btw. super excited about that)
20:11:04 <mcs> I don't know how to use Sandstorm but maybe the iOS 9 project is https://github.com/icepa
20:11:08 <mikeperry> still need to make my fixes into a branch
20:12:51 <mikeperry> mtigas: you would know. is https://github.com/icepa the iOS Tor VPN project? is there more than one?
20:18:23 <mikeperry> mcs: well, I added that link
20:18:31 <mikeperry> thanks
20:18:40 <mtigas> that's the only one i know about (w/conradev and me and some others)
20:18:46 <mcs> mikeperry: I see it; thanks!
20:19:22 <mcs> How soon will Tor Labs be visible to the world at large?
20:20:38 <mikeperry> goal is by CCC (Dec 27th)
20:22:31 <mcs> Exciting!
20:25:09 <mikeperry> ok, anything else for this meeting then?
20:26:58 <mcs> Not from me.
20:27:06 <mikeperry> alright, thanks everyone!
20:27:10 <mikeperry> #endmeeting *baf*