[ooni-dev] On the ethics of soliciting measurements and informed consent

Dan O'Huiginn daniel at ohuiginn.net
Fri Jan 2 17:30:44 UTC 2015


Hi folks,

Firstly, hello! Having met Arturo and Vasilis at the 31C3, I'm keen to
get involved more.

On consent: at an absolute minimum, I agree we need better warnings for
users.

Below is some proposed text to inform users about the risks of OONI. I'm
willing to take on the job of refining this based on feedback.

IMO we need two versions. One short and simple, that users should have
to read (and agree to?) before first running ooniprobe. The second
comprehensive, to be put on the website and in the docs.


A) THE SHORT VERSION

WARNING: Running OONI may be illegal in your country, or forbidden by
your ISP. By running OONI you will connect to web services which may be
banned, and use web censorship circumvention methods such as Tor. The
OONI project will publish data submitted by probes, possibly including
your IP address or other identifying information. In addition, your use
of OONI will be clear to anybody who has access to your computer, and to
anybody who can monitor your internet connection (such as your employer,
ISP or government).

[link to long version]



B) THE LONG VERSION

LEGALITY

OONI does several things which may be illegal in your country, and/or
banned by your ISP.

OONI's http test will download data from controversial websites,
specifically targeting those which may be censored in your country.
These may include, for example, sites containing pornography or hate
speech. You can find a list of sites checked at
https://github.com/citizenlab/test-lists

Even where these sites are not blocked, it may be illegal to access
them. It may also be illegal to bypass censorship, as OONI attempts by
using Tor.

In the most extreme case, any form of network monitoring could be
illegal or banned, or even considered a form of espionage.

[Include link to some resource on relevant laws globally. Someone like
the EFF must have one of these; does anybody have a link?]

PRIVACY

OONI IS NOT DESIGNED TO PROTECT YOUR PRIVACY. It will reveal information
about your internet connection to the whole world. Particular groups,
such as your ISP and web services used by the ooni tests, will be able
to discover even more detailed information about you.

THE PUBLIC will be able to see the information collected by OONIprobe.
This will definitely include your approximate location, the network
(ASN) you are connecting from, and when you ran ooniprobe. Other
identifying information, such as your IP address, is not deliberately
collected, but may be included in HTTP headers or other metadata. The
full page content downloaded by OONI could potentially include further
information, for example if a website includes tracking codes or custom
content based on your network location.

You can see what information OONI releases to the public at
https://ooni.torproject.org/reports/. You should expect this information
to remain online PERMANENTLY. [include details of retention policy, once
we have one]

THE OONI PROJECT will also be able to see your IP address [What other
info do we get?]

ORGANIZATIONS MONITORING YOUR INTERNET CONNECTION will be able to see
all web traffic generated by OONI, including your IP address, and will
likely be able to link it to you personally. These organizations might
include your government, your ISP, and your employer.

ANYBODY WITH ACCESS TO YOUR COMPUTER, now or in the future, may be able
to detect that you have installed or run ooni

SERVICES CONNECTED TO BY OONI will be able to see your IP address, and
may be able to detect that you are using OONI




On 28/12/14 06:50, royaen wrote:
> Hi Arturo and all,
> 
> 
> When it comes to ethics of soliciting measurements and informed consent,
> I have a different take which has been my research topic over the past
> years.  There are many reasons why I think that directly measuring
> censorship is scary.  First of all, you need to acquire reliable vantage
> points to run your measurements. Volunteering one’s machine to foreign
> researchers, or operating a device on their behalf, might be viewed by
> the government as espionage.  Besides, many regions, especially places
> where we don’t have good infrastructure, have a limited number of
> companies/volunteers (if any) that allow foreigners to rent computers
> inside the country.  All the current direct approaches, such as RIPE
> Atlas [1] or other distributed platforms or volunteers running Raspberry
> Pis are often easy to spot and data collected from them may not be
> reliable.  For example, regarding China, we showed [2] that censorship
> is different in CERNET (China Education and Research Network) compared
> to other ISPs.
> 
> 
> When it comes to measuring connectivity, I believe that it is better to
> involve the whole country in doing the measurements rather than
> volunteers whose safety is at stake.  Therefore, I have developed
> effective methods for remotely measuring Internet censorship around the
> world, without requiring access to any of the machines whose
> connectivity is tested to or from. These techniques are based on novel
> network inference channels, a.k.a idle scans. That is, given two
> arbitrary IP addresses on the Internet that meet some simple
> requirements such as global IPID behaviour, our proposed technique can
> discover packet drops (e.g., due to censorship) between the two remote
> machines, as well as infer in which direction the packet drops are
> occurring.  Here are more references to read [3,4]. Basically, for one
> of the idle scans (hybrid idle scan), we only create unsolicited packets
> (a bunch of SYNACK and RST segments) between two remote IPs, and look at
> the changes in the global IPID variable to infer whether censorship is
> happening and if so, in which direction packets are dropped.           
>            
> 
> Back to my main point, why I am trying so hard to convince you that we
> also need to use side channels and how this relates to ethics, well,
> here is the story: The discussion you brought up has been discussed
> heavily in academia in the past six months after two papers got rejected
> from the IMC conference because of ethics. One of them was my paper [2]
> after having received good reviews on the technical contribution. Here
> is the link to the reviews:
> 
> 
> https://imc2014.cs.wisc.edu/hotcrp/paper/243?cap=0243a2kWYrwVqbv0
> 
> 
> I personally just got an email with above link from IMC, and because of
> having had a single-entry visa, I couldn’t attend IMC or the Citizen Lab
> workshop where a lot of the discussions about ethics were taking place.
> The ethical issues that usually come up are two: First, using idle
> scans, no consent from users is collected. Second, censors could
> mistakenly assume that two machines measured by us are deliberately
> communicating with each other.  This could have negative consequences if
> a censor believes that a user is communicating with a sensitive or
> forbidden IP address.
> 
> 
> In response to the latter argument, it is unlikely that a censor would
> come to such a conclusion as only RST segments are created from a client
> inside a country to a server and only SYN/ACK segments are sent from a
> server to a client inside the censoring country.  An adversary would not
> witness a full TCP handshake, let alone any actual data transfer. 
> 
> 
> One mitigation technique that I have been focusing on is to use routers
> instead of end points for the side channel measurements.
> 
> If you or anyone else is interested in using these techniques, I am more
> than happy to help.
> 
> 
> Roya
> 
> 
> [1] http://cartography.io/
> 
> [2] http://arxiv.org/abs/1410.0735
> 
> [3]http://arxiv.org/pdf/1312.5739v1.pdf
> 
> [4]http://www.usenix.org/event/sec10/tech/full_papers/Ensafi.pdf
> 
> 
> 
> 
> _______________________________________________
> ooni-dev mailing list
> ooni-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/ooni-dev
> 


-- 
Dan O'Huiginn

daniel at ohuiginn.net
http://ohuiginn.net @danohu
http://investigativedashboard.org
http://reportingproject.net
skype: danohuiginn


More information about the ooni-dev mailing list