17:00:26 <hellais> #startmeeting OONI gathering 2016-07-18
17:00:26 <MeetBot> Meeting started Mon Jul 18 17:00:26 2016 UTC.  The chair is hellais. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:26 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:00:28 <hellais> here we go
17:00:32 <hellais> who is here?
17:00:45 <willscott> hi
17:01:06 <agrabeli> heya
17:01:07 * hodgepodger waves
17:02:03 * sbs here
17:02:56 <sbs> (btw, it seems the server's time is not sync)
17:03:33 <hellais> sbs: which server?
17:04:58 <sbs> hellais: the one running IRC - shouldn't it be 17:04 UTC now?
17:07:11 <hellais> hum, yeah
17:07:32 <hellais> it's some minutes behind. Will fix that
17:07:38 <hellais> anyways I guess we should start
17:07:47 <hellais> agrabeli suggested some topics to discuss.
17:07:54 <hellais> agrabeli: would you like to say what they are?
17:08:24 <agrabeli> yes, the first topic is #How to notify users when blocked URLs become unblocked
17:09:21 <agrabeli> hellais and I recently joined the global voices community mailing list, and it was suggested to us that it would be useful if OONI Explorer somehow provided a notification when blocked URLs become unblocked
17:09:33 <agrabeli> *became
17:10:01 <willscott> would a notification here be an email, or a status line on the country page, or something else?
17:10:32 <agrabeli> willscott: I guess that would be up to us to decide (the person didn't specify how they would like to see this happen)
17:10:55 <agrabeli> though I am imagining that ideally this would somehow be included in the data illustrated on the Explorer
17:11:51 <agrabeli> I think it's really useful to provide info on when blocked URLs stop being blocked, though I would imagine that this is only really feasible for data collected from stable vantage points
17:12:05 <sbs> for the explorer, one may show the history of a URL and whether it is currently available
17:12:30 <willscott> right. given enough measurements, we can do something like https://metrics.torproject.org/userstats-censorship-events.html
17:12:57 <sbs> otherwise, maybe, one can express interest on some URILs and be notified during orchestration if their status changed?
17:13:02 <agrabeli> sbs: Do you think it would be possible to show this in the Explorer based on how the pipeline currently processes data? Or would we need to make changes to the pipeline to accommodate this?
17:13:17 <agrabeli> willscott: yep, exactly :)
17:13:48 <sbs> agrabeli: I don't know... I know very little about the pipeline, I'll redirect the question to hellais :-P
17:13:58 <hodgepodge> IMO it should be limited to the OONI Explorer view otherwise repeated pipeline runs may cause a flood of spam to be sent to the mailing list when a blocked URL appears to have been unblocked due to a refresh in the data powering ooni-explorer
17:14:37 <agrabeli> hodgepodge: good point
17:14:51 <sbs> hodgepodge: not if the client asks during orchestration the status of URLs the user cares about
17:15:05 <willscott> identification of "what's blocked" and "what's no longer blocked" as lists we maintain is maybe a good first step
17:15:11 <sbs> in such case, the update is triggered by the client sync-ing up with servers
17:15:33 <hodgepodge> True, sbs. It should be possible to isolate things like blocked URLs to a dedicated postgres schema though. What do you think, hellais?
17:15:49 <hodgepodge> That is, the postgres schema containing blocked urls would ideally never be truncated.
17:16:08 <hellais> agrabeli: well yes some changes are of course needed to implement this type of feature. Given how the batch views are currently generated it's not something that is easily integrated into the current system, but based on the reworking of it, it can be done.
17:16:13 <sbs> hodgepodge: imo, what would be useful is a view of the history of the url
17:16:18 <hodgepodge> ^
17:16:23 <landers> (...here...)
17:16:34 * hodgepodge waves at landers
17:16:40 <hellais> the issue is that we currenty only generate views with the URLs that are blocked, but we don't have a view for the history of measurements for a given URL
17:17:37 <hellais> we would have to generate another view that is "the measurements for all the URLs ever seen as being blocked"
17:18:14 <agrabeli> hellais: would we want to prioritise on generating a history of URLs (showing also which ones are not blocked) - as suggested by sbs - in the near future? Or would you view this as low priority in comparison to other pipeline dev?
17:18:16 <sbs> hellais: ack, in that case a first approx of wahta I was talking about is that the client asks during orcestration which URLs in a list are stil blocked
17:18:44 <hodgepodge> Oh, gotcha. So we'd have to run the pipeline against all of the test results that we've ever seen, right?
17:20:14 <sbs> hodgepodge: in the first version of what I said probably yes; but maybe it would be enough to a user to know if a URL in a list is still in the view of blocked URLs (otherwise it's unblocked...)
17:21:11 <hellais> agrabeli: I think this a nice feature to have in future versions of the explorer/data pipeline, but I wouldn't advise implementing it based on the current batch materialised view system, but wait for us to reach feature parity of the pipeline with a scheme that doesn't involve batch materialised view updates.
17:22:15 <willscott> do we have an issue for it? worth keeping a record of the feature request on github
17:22:33 <elation1> If there is an interest in implementing something like the Tor censorship events interface you might take a look at my rewrite of it. It was done to make the code more readable and therefore easier to modify the algorithm being used and is also faster that the original. https://github.com/seamustuohy/tor_anomaly http://www.seamustuohy.com/tor_anomaly/
17:23:16 <agrabeli> hellas: ok
17:23:27 <agrabeli> willscott: I can create an issue for it now
17:23:40 <willscott> elation1: thanks for the pointer!, and that code is already python :)
17:24:53 <elation1> willscott: I try to help when I can. :)
17:27:37 <hellais> elation1: very cool! I bet we can get some interesting results also by applying similar algorithms to user statistics data of other censorship circumvention tools
17:28:11 <agrabeli> (issue created: https://github.com/TheTorProject/ooni-pipeline/issues/34)
17:29:28 <agrabeli> elation1: thanks :)
17:30:00 <agrabeli> so if there are no other thoughts on topic 1, perhaps we can move on to topic 2 of the agenda?
17:31:05 <hellais> yes
17:31:08 <agrabeli> #topic How to improve the acquisition of 'consent' from users
17:31:44 <agrabeli> We've briefly discussed this in previous weekly meetings, and we have written documentation on this question
17:32:34 <agrabeli> However, this question was raised by the Global Voices community, and it's recurring now that we need to implement this in the GUI in the upcoming month(s)
17:33:23 <willscott> we will have this more integrated as part of the web ui that hellais is working on
17:33:44 <willscott> are there additional feature requests or concerns that we aren't doing enough?
17:34:41 <agrabeli> willscott: yes, though the GV community raised concerns in regards to whether having people read long documentation (which they probably won't do) and clicking on a "I agree" button is enough to actually acquire consent
17:35:23 <willscott> i don't know if we've gotten far enough in the web ui to know that consent would be a long page an an "I agree" button?
17:35:25 <agrabeli> on this note, they suggested that we could perhaps implement a sort of quiz in the GUI, which would require users to get questions right as a prerequisite of running each test
17:36:26 <willscott> each test, or once at the beginning?
17:36:35 <willscott> it seems annoying to have to re-answer a quiz every time
17:37:12 <agrabeli> willscott: currently the documentation that we have which would be integrated in the GUI is this: https://github.com/agrabeli/ooni-spec/blob/95b9d2c7971539e897947b8125723fadd88ad6b4/informed-consent/consent-form.md (which is quite long)
17:38:11 <agrabeli> willscott: I guess that's the trade-off here. On the one hand, perhaps having people answer a quiz each time for each test would ensure better that people understand what they're running? But on the other hand, I worry that this would disincentivise users from running the software...
17:38:55 <agrabeli> I'm therefore wondering what the 'best' solution could be in this regard...
17:41:18 <hellais> I think the quiz option (and any other informed consent procedure) is going to be usable only if we make it something that the user does once the first time they install the software and run it
17:41:21 <sbs> agrabeli: very difficult to find a balance... perhaps the first time OONI could start in "initial tour" mode and in the process of guiding the user through all the features it could also educate he/she?
17:41:27 <hodgepodge> There is one approach that we could consider that might weigh the pros, and cons for headless ooni-probe users, and those who have access to a GUI. What if we opted to do something kind of like Minecraft has done for their EULA?
17:41:48 <hodgepodge> Before you can play the game, you need to read eula.txt, and then change a flag in another file to true before you can play.
17:41:49 <sbs> hodgepodge: can you say more on minecraft;s eula?
17:42:07 <hodgepodge> One second, I'll pull some data from my VPS.
17:42:32 <sbs> hodgepodge: ah, sorry... concurrent messaging to each other... you already replied me
17:42:48 <willscott> hmm. i think this problem is less for technical users who are on the command line.
17:42:53 <hodgepodge> But yeah, that way the user has to explicitly consent to running an ooni-probe, and ideally, that will help them understand their risks.
17:42:58 <hodgepodge> Good point, willscott.
17:43:00 <willscott> presumably we can have a "--i-know-the-risks" flag that skips it for them
17:43:33 <hodgepodge> Yeah, but that'd be super cumbersome IMO
17:44:39 <sbs> hodgepodge: maybe -f (or -ff) instead of the long version and maybe -ff could set a flag?
17:44:57 <hodgepodge> sbs: so the minecraft client/server instances require that you set a flag in a file called eula.txt. This is the contents of that file: http://pastebin.com/raw/E167mreb
17:45:12 <sbs> or -fff (which is the sound of a pissed off user that wants to bypass th questions for good)
17:45:32 <hodgepodge> :P
17:46:18 <sbs> hodgepodge: I see... I think having a flag to change the switch may be more convenient for the user, tho
17:47:46 <willscott> the ui presentation might be the realm of a ux designer more than us
17:47:57 <hodgepodge> sbs: maybe. Then again by forcing them to modify something in a file, they're going to have to read whatever information you put in the file. It's definitely a trade-off.
17:48:12 <willscott> maybe we could ask simplysecure if they have thoughts on the balance between usability and understanding?
17:48:41 <agrabeli> willscott: sounds good
17:49:32 <agrabeli> hodgepodge: Yeah, I think that having users modify something in a file probably ensures better 'consent' acquisition than merely checking a box
17:49:43 <hellais> well I think there are two different informed consent procedures here. 1) Is that of a command line user of ooniprobe (here changing a flag or running it with a special --i-understand-the-risks options is ok) 2) Is the user of the ooniprobe webui, in this case we need a procedure that is somehow graphical and also ensures that they have actually read what is in the disclaimer
17:50:37 <hellais> to be honest I am not too worried of the procedure for the case 1), because if you have the skills to run ooniprobe from the command line, you probably are also the type of person that reads documentation and are probably somewhat informed on what ooniprobe does (or you should more or less have an idea of it)
17:51:20 <hodgepodge> Good point, hellais and thanks agrabeli. Honestly, there is no good way of determining whether or not a given user has read and understood a EULA without being a draconian overlord about it.
17:51:45 <hodgepodge> Even in the case of software written by Oracle you can just scroll to the bottom blindly, and accept the EULA.
17:52:08 <landers> another useful warning before running would be like "hey, this is gonna use like hundreds of MBs of data if you're on a mobile data plan"
17:52:19 <landers> seems like we'd eventually need that, too, with the mk stuff
17:52:30 <hodgepodge> However, you could have one long form EULA for the first session, and then pop-ups at the start of the session that say "hey, this is dangerous"
17:52:34 <hellais> so I think the most critical one is the use case 2. Where we probably want to give what design people call the "onboarding experience" where we guide them through some subset of the risks document step by step and during the process we ensure that they have understood what they have read by quizing them
17:52:47 <agrabeli> hellais: Ideally (or at least how I am imagining it), the infomed consent procedure for the GUI would include some sort of animation that would explain, in a visual & easy to understand way, what the risks are for each test. Though creating animations doesn't fall under the scope ofour priorities and I think it would be expensive to outsource.. :/
17:53:15 <agrabeli> hellais: agreed (in terms of what you've said for 1 & 2)
17:53:16 <hellais> we actually did something similar for globaleaks where we didn't want to disable usage of non-anonymous submissions, but wanted to ensure that people that access a globaleaks instance not over tor are aware of the risks
17:53:49 <hellais> so when that happened we made them read some text explaining what that meant and then offerred them a multiple selection question that tested if they had understood that they are not going to be anonymous
17:54:53 <hodgepodge> hellais: in the case of globaleaks how did users respond to the super mandatory EULA agreement?
17:56:00 <agrabeli> hellais: and was answering these questions only required the first time?
17:56:37 <sbs> agrabeli: I like the idea of the animation
17:57:55 <hellais> agrabeli: yes only the first tiemme
17:58:51 <hellais> hodgepodge: well it wasn't actually as full EULA it was only an informational text explaining the risks and it only appeared when you weren't using tor. Overall the reaction was good though.
17:59:11 <hodgepodge> hellais: That's a little surprising, but good to know!
17:59:12 <agrabeli> sbs: perhaps including animated gifs (which are easier to create)? :p
17:59:37 <hellais> We also did some user testing sessions with people going through the GUI and it actually lead some people to going back and re-reading the text to understand it properly and then answer the quiz correctly
17:59:44 <sbs> agrabeli: yes, that could be a way to do it, indeeed!
18:00:03 <hellais> it's actually the case that if you give people a wizard they will istinctively click next even without having read anything in it
18:00:40 <agrabeli> hellais: right
18:01:24 <willscott> any action items / follow up we should take away from this point?
18:01:37 <agrabeli> how about an approach which combines a quiz and animated gifs?
18:02:19 <sbs> agrabeli: +1
18:03:03 <agrabeli> willscott: I guess the options we've discussed in summary include (1) Modifying a file, (2) Quiz based on text, (3) Animated gifs (am I missing something?)
18:04:53 <sbs> agrabeli: I think you summarized all options
18:05:40 <agrabeli> ok I'll look into the animated gif thing, and see whether it's feasible/makes sense to create some for the informed consent procedure
18:06:10 <agrabeli> and I'll coordinate with hellais and anyone else working on the GUI to see what can be implemented best (for the alpha version at least)
18:09:33 <agrabeli> if anyone has any more ideas/suggestions, please feel to free to send them my way! :)
18:10:07 <hellais> very good!
18:10:18 <hellais> thank you all for attending and see you around
18:10:21 <hellais> #endmeeting