ooni-dev December 2014

ooni-dev@lists.torproject.org

6 participants
7 discussions

On the ethics of soliciting measurements and informed consent
by Arturo Filastò 15 Jan '15

15 Jan '15

Hello Oonitarians, During yesterdays we had a very interesting conversation about the ethics of measurements, informed consent and methodologies for achieving it. These are very important discussions to have and we agreed that we should continue it in this thread. For those that were not on IRC at that time I will explain briefly what it was that sparked the debate. If you are interested in reading the full transcript of the meeting private message me and I will send it to you. A problem that we have with OONI and I think is common to most network measurements projects is that of acquiring reliable vantage points in non western countries. By reliable I mean vantage points where the tool in question is not just run once and forgotten, but is periodically run, say once every day. One way of acquiring vantage points is to rent VPS' and setting up the tool on such VPS'. The problem with this approach, though, is that what you are measuring is not the network that a real user in that country would be using. To overcome this issue I have come up with a scheme where by I get in contact with people from countries that interest us and give them some money to buy a raspberry pi and setup ooniprobe on it. As an incentive to keep the probe running and gathering data with a daily resolution I then pay them a small monthly fee to cover bandwidth and power costs. It turns out that not only is this cheaper than renting a VPS in that country, but it also gives us more accurate results, since the measurements are done from the users DSL home connection. The problem with this approach is that we need to make it absolutely clear that there is some risk involved in running the software and the amount of risk varies greatly from country to country. So far I have limited this to a very small set of people (3 in total, 2 paid and 1 not paid) that I have personally vetted and made sure that they have read and understood what is written here: https://github.com/thetorproject/ooni-probe#read-this-before-running-oonipr…. Some people are of the opinion that still this is not enough and that by paying them the risk is increased. It is not yet fully clear to me why that would be the case, nor what can be done to make the situation better. Some have suggested we consult some lawyers that have background in international law to tell us how we can make this situation better. I believe this is probably a good idea. It was also mentioned that Stony Brook university may also have valuable feedback in this area and we should also reach out to them. I invite all the people present during yesterdays meeting to integrate their feedback into this thread and forward this email to people that can further advise. ~ Arturo

9 12

Reminder for weekly OONI dev meeting Monday 2014-12-22 18:00 UTC (19:00 CET)
by Arturo Filastò 22 Dec '14

22 Dec '14

Hello Oonitarians, This is a reminder that today there will be the weekly OONI meeting. It will happen as usual on the #ooni channel on irc.oftc.net at 18:00 UTC (19:00 CET, 13:00 EST, 10:00 PST). Everybody is welcome to join us and bring their questions and feedback. See you later, ~ Arturo

1 0

Feedback on OONI data collection, aggregation, and visualization
by Karsten Loesing 15 Dec '14

15 Dec '14

Hi everyone, I just subscribed to this list, because Arturo asked me to comment on two postings here. As a very quick introduction, and because I don't know how distinct the Tor community and the OONI community are: I'm the developer behind the Tor network data collector CollecTor [-1] and the Tor Metrics website that aggregates and visualizes Tor network data [0]. Here's what Arturo asked on another thread: > With OONI what we are currently focusing on is Bridge Reachability > measurements. We have at this time 1 meter in China, 1 in Iran (a second > one is going to be setup soon), 1 in Russia and 1 in Ukraine. We have > some ideas of the sorts of information we would like to extract from > this data, but it would also be very good to have some more feedback > from you on what would be useful [1]. Long mail is long. Some random thoughts: - For Tor network data it has turned out to be quite useful to strictly separate data collection from data aggregation from data visualization. That is, don't worry too much about visualizing the right thing, but start with something, and if you don't like it, throw it away and do it differently. And if you're aggregating the wrong thing, then aggregate the previously collected data in a different way. Of course, if you figure out you collected the wrong thing, then you won't be able to go back in time and fix that. - I saw some discussion of "The pool from where the bridge has been extracted (private, tbb, BridgeDB https, BridgeDB email)". Note that isis and I are currently talking about removing sanitized bridge pool assignments from CollecTor. We're thinking about adding a new config line to tor that states the preferred bridge pool, which could be used here instead. Just as a heads-up, six months or so in advance. I can probably provide more details if this is relevant to you. > Another area that perhaps overlaps with the needs of the metrics is data > storage. Currently we have around 16 GB of uncompressed raw report data > that needs to be archived (currently it's being stored and published on > staticiforme, but I have a feeling that is not ideal especially when the > data will become much bigger) and indexed in some sort of database. > Once we put the data (or a subset of it) in a database producing > visualizations and exposing the data to end users will be much simpler. > The question is if this is a need also for > Metrics/BwAuth/ExitScanner/DocTor and if we can perhaps work out some > shared infrastructure to fit both of our goals. > Currently we have placed the data inside of MongoDB, but some concerns > with it have been raised [2]. Again, some random thoughts: - For Metrics, the choice of database is entirely an internal decision, and no user would ever see that. It's part of the aggregation part. If we ever decide to pick something else (than PostgreSQL in this case), we'd have to rewrite the aggregation scripts, which would then produce the same or similar output (which is an .csv file in our case). That being said, trying out MongoDB or another NoSQL variant might be worthwhile, but don't rely on it too much. - Would you want to add bridge reachability statistics to Tor Metrics? I'm currently working on opening it up and making it easier for people to contribute metrics. Maybe take a look at the website prototype that I posted to tor-dev@ a week ago [3] (and if you want, comment there). I could very well imagine adding a new section "Reachability" right next to "Diversity" with one or more graphs/tables provided by you. Please see the new "Contributing to Tor Metrics" section on the About page for the various options for contributing data or metrics. - Please ask weasel for a VM to host those 16 GB of report data; having it on staticiforme is probably a bad idea. Also, do you have any plans to synchronize reports between hosts? I'm planning such a thing for CollecTor where two or more instances fetch relay descriptors from directory authorities and automatically exchange missing descriptors. - I could imagine extending CollecTor to also collect and archive OONI reports, as a long-term thing. Right now CollecTor does that for Tor relay and bridge descriptors, TORDNSEL exit lists, BridgeDB pool assignment files, and Torperf performance measurement results. But note that it's written in Java and that I hardly have development time to keep it afloat; so somebody else would have to extend it towards supporting OONI reports. I'd be willing to review and merge things. We should also keep CollecTor pure Java, because I want to make it easier for others to run their own mirror and help us make data more redundant. Anyway, I can also imagine keeping the OONI report collector distinct from CollecTor and only exchange design ideas and experiences if that's easier. Lots of ideas. What do you think? All the best, Karsten [-1] https://collector.torproject.org/ [0] https://metrics.torproject.org/ [1] https://lists.torproject.org/pipermail/ooni-dev/2014-October/000176.html [2] https://lists.torproject.org/pipermail/ooni-dev/2014-October/000178.html [3] https://kloesing.github.io/metrics-2.0/

3 5

Reminder for weekly OONI dev meeting Monday 2014-12-15 18:00 UTC (19:00 CET)
by Arturo Filastò 15 Dec '14

15 Dec '14

Hi, This is a reminder that today there will be the weekly OONI meeting. It will happen as usual on the #ooni channel on irc.oftc.net at 18:00 UTC (19:00 CET, 13:00 EST, 10:00 PST). Everybody is welcome to join us and bring their questions and feedback. See you later, ~ Arturo

1 0

Ubuntu PPA
by Iain R. Learmonth 11 Dec '14

11 Dec '14

Hi, Earlier in the week, an Ubuntu PPA was requested in IRC. I've since learnt how to put these together and now one exists [1]. Next up on this side of things I'll be looking at bug #10734 [2] for the Ubuntu package, and hopefully coming up with a patch that can be included easily in the Debian package too. Please do let me know how you get on if you use the PPA. Thanks, Iain. [1]: https://launchpad.net/~irl/+archive/ubuntu/ooni [2]: https://trac.torproject.org/projects/tor/ticket/10734 -- e: irl(a)fsfe.org w: iain.learmonth.me x: irl(a)jabber.fsfe.org t: +447875886930 c: 2M0STB g: IO87we p: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49

1 0

OONI Team Status Report for November
by Arturo Filastò 09 Dec '14

09 Dec '14

# What we did in November 2014? This month marks an important milestone. oonibackend is now deployed on the production mlab slices! This means that since November 26th probes running the http_header_field_manipulation test have been sending their reports to M-Lab production nodes. * Assist the M-Lab team in deploying oonibackend on the production slices * Set upper bound in comparison with the control in the bridge reachability timeline https://trac.torproject.org/projects/tor/ticket/13640 * Handle mlab-ns errors in update-bouncer.py script https://trac.torproject.org/projects/tor/ticket/13812 * Progress on Brainstorm ideas for possible visualisations: https://trac.torproject.org/projects/tor/ticket/13731 * Hold a small workshop on OONI data visualization in Rome: https://lists.torproject.org/pipermail/ooni-dev/2014-November/000194.html # What we plan to do in December 2014? * Align the dates in the visual timeline https://trac.torproject.org/projects/tor/ticket/13639 * Better tokenising for bridges so that bridges that have the same fingerprint, but different transport are grouped properly https://trac.torproject.org/projects/tor/ticket/13638 * Finish setting up the docker containers for the steps of the data pipeline https://trac.torproject.org/projects/tor/ticket/13568 * Setup disaster recovery procedure and backup: https://trac.torproject.org/projects/tor/ticket/13584 * Setup monitoring of the probes. https://trac.torproject.org/projects/tor/ticket/12549 * Add support for obfs4 https://trac.torproject.org/projects/tor/ticket/13597 * Implement some of the OONI tests inside of libight: https://github.com/bassosimone/libight/milestones/OONI%20tests%20implemente… ~ Arturo

1 0

Reminder for weekly OONI dev meeting Monday 18:00 UTC (19:00 CET)
by Arturo Filastò 01 Dec '14

01 Dec '14

Hi, This is a reminder that today there will be the weekly OONI meeting. As I am writing this I am on a plane heading towards London and will be working on a GlobaLeaks workshop in some office there. The schedule for the workshop is not very well defined so I am not 100% sure I will manage to be online at the above defined time. If I am not there please start without me and I will be sure to read the backlog and write feedback asynchronously. ~ Arturo

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

ooni-dev December 2014