[tor-dev] Let's come up with the roadmap for the future of OONI
Hello Oonitarians and Divisionists, I would love to have your feedback on what you believe to be the most important topics for the future of OONI. I have made a list of what I believe are all possible and interesting tasks to perform, but we can't do them all and for sure we can't do them all at once. For this reason it would be very useful if you could express a vote from 1-5: 1: Nah, this is boring and pointless 2: Not really super important, I would give priority to other stuff 3: Useful, I would do it 4: This would be awesome 5: Epic! Feel free to also expand these topics with questions and feedback (or new ones). At the end of the list I will give you a table to cast your vote. # Get daily OONI measurements from 50 countries This means focusing on getting a large and diverse reliable OONI userbase. It does not simply mean to get at least 1 measurement in 50 countries, but it means either establishing relationships with trusted parties in 50 countries, or expanding our userbase to a point where we have at least 1 measurement per day for every test per country (from the same network). Ways of achieving this are: * Rent a VPS in X number of countries * Running the adopt an ooniprobe program (see below for more details) * Establish an agreement with operators in 50 countries to host the probing infrastructure (as previously stated) # Develop OONI tests for censorship circumvention tools This involves devising a methodology for testing the reliability of censorship circumvention tools in various countries. It means testing censorship circumvention tool both open source and propertairy. A cursory list of the protocols/tools we could be interested includes, but is not limited to: * Tor * VPN * Web proxies (hidemyass, etc.) * SSH tunnel * Freegate * Psiphon * Ultrasurf * alkasir If you think we should be testing some other tools too, please add to this list. Useful resources: http://cyber.law.harvard.edu/publications/2011/2011_Circumvention_Tool_Evaluation http://cyber.law.harvard.edu/publications/2010/Circumvention_Tool_Usage # Develop scheme for orchestrating ooni-probes This means coming up with a protocol that allows an OONI test developer to schedule a measurement to be run with a certain input they decide on a set of probes in country X. Obviously security considerations need to be taken into account and access will be in the initial stage only limited to a very restricted set of OONI developers that will be made public. # Implement data analytics and visualization for OONI tests We have a bunch of data and we would like to give meaning to it. This would involve writing tools for querying the data in the database and extract useful analytical information from it. Based on this data we can then start looking at historical OONI data and provide some sample visually supported reports. This is a list of tests we should develop analytics for: * HTTP requests * DNS Consistency * DNS Injection * TCP Connect * HTTP Invalid Request Line * HTTP Header Field Manipulation * Multi protocol port traceroute # Implement pub-sub system for ooni collectors Currently OONI collectors (the things you send your ooniprobe measurement results to) keep in sync thanks to a bunch of shell scripts and cronjobs. To have more real time data it would be useful to have a pub-sub mechanism that allows the pipeline to subscribe to all the collectors and the collectors will then publish the collected reports to it, as soon as they are submitted. This will allow the OONI data to go through the data pipeline much faster (instead of ~2 hours, perhaps just some minutes or even less potentially). # Reach production quality ooni rasperry-pi (beagle-board) images This involves implementing what is specified in the lepidopter specification: https://github.com/anadahz/lepidopter/blob/master/specification.md We should then provide scripts for building the image yourself or how to download and burn it to an SD card on Windows, OSX, Linux (with screenshots). As a bonus we could also offer shipping of pre-made raspberry pi images already burn to an SD card, similar to what is done with rasbpian images. # Promote and further develop OONI on mobile (Android, iOS) This involves improving the GUI of OONI on mobile and getting it into the Google Play store and the Apple App store. We should also work on making it easier for developers of existing iOS and Android apps to add internet measurement capabilities to their app by linking to libight. # Do research based on OONI This would involve doing some research on internet censorship based on OONI probe or on internet measurement in general and publishing them in peer reviewed venues. # Publish monthly reports about the status of internet censorship in a country This would be sort of like a monthly e-zine, where every month we analyse the status of internet censorship in a given country. It should be backed by OONI data, but the core of it
Re: [tor-dev] A proposal to change hidden service terminology
On Tue, Feb 10, 2015 at 01:13:26PM -0500, A. Johnson wrote: | Hello all, | | Several of us [0] working on hidden services have been talking about adopting better terminology. Some of the problem | 1. '''onion service''' should be preferred to refer to what is now called a hidden service. If other flavors of onion services develop in the future, this term could refer to all of them, with more specific terms being used when it is necessary to make the distinction. | 2. '''onionsite''' should be preferred to refer to a website (i.e. an HTTP service serving up HTML) available as an onion service. This can be extended to other specific types of services, such as '''onion chatroom''', '''onion storage''', '''onion cloud service''', etc. | 3. '''onion address''' should be preferred to refer specifically to the xyz.onion address itself. | 4. '''onionspace''' should be used to refer to the set of available onion services. For example, you can say “my site is in onionspace” instead of “my site is in the Dark Web”. | 5. '''onion namespace''' should be used to refer to the set of onion addresses currently available or used recently (context-dependent). | Have you done usability testing to see how people react to the onion terms, how explainable they are to non-technical journalists, or what connotations it might have across cultures? My experience has been changing terminology is expensive and slow, and it's worth exploring lots of alternatives. Adam ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] A proposal to change hidden service terminology
On Tue, Feb 10, 2015, at 01:13 PM, A. Johnson wrote: Hello all, Several of us [0] working on hidden services have been talking about adopting better terminology. I agree 100% with the term list and am eager to start using it. Some of the problems with current terms areh 1. '''Hidden''' and '''Dark''' have a negative connotations. 2. '''Hidden-service website''' is too long; '''hidden site''' is too vague. 3. '''.onion''' (read dot onion) is hard to say and not very descriptive. 4. There is no general term for the set of available hidden services. 5. The term '''encrypted service''' is too general. This term refers to a setup (still needing development) in which Tor is required to connect to a service, but the service location is not hidden. Even without server anonymity, this setup can provide enforced client anonymity, secure name resolution, censorship circumvention, and end-to-end-encryption. Making the server location known can allow for improved performance (by shorter circuits) and security (by enabling location-aware path selection by the client). We’ve come up with the following suggestions for better terms, which we’d like to offer up for discussion: 1. '''onion service''' should be preferred to refer to what is now called a hidden service. If other flavors of onion services develop in the future, this term could refer to all of them, with more specific terms being used when it is necessary to make the distinction. 2. '''onionsite''' should be preferred to refer to a website (i.e. an HTTP service serving up HTML) available as an onion service. This can be extended to other specific types of services, such as '''onion chatroom''', '''onion storage''', '''onion cloud service''', etc. 3. '''onion address''' should be preferred to refer specifically to the xyz.onion address itself. 4. '''onionspace''' should be used to refer to the set of available onion services. For example, you can say “my site is in onionspace” instead of “my site is in the Dark Web”. 5. '''onion namespace''' should be used to refer to the set of onion addresses currently available or used recently (context-dependent). We couldn’t decide on the best names for alternative onion service setups, because they don’t exist yet! But, we have some ideas about how these things might be named: 1. Some names for a setup in which the onion service location is known but still must be connected to via the Tor protocol: * '''Tor-required service''', '''TRS''' for short * '''Direct onion service''', '''direct service''' for short 2. Some names to specify that the onion service is hidden, if that becomes necessary: * '''Protected onion service''', '''protected service''' for short * '''Tor-protected service''', '''TPS''' for short 3. Some names to specify that a client connects to an onion service non-anonymously: * '''Client-direct access''' * '''tor2web mode''' We’re maintaining an evolving wikipage with the above suggestions [1]. Some of us are already beginning to use the suggested terminology, to see how it works out. One nice goal might be for Tor to choose the new terms that it likes (if any) and use them in the rollout of next-gen onion services [2]. So we’re bringing up this subject now to a larger segment of the Tor community. Thoughts? Best, Aaron [0] Including David Goulet, Rob Jansen, George Kadianakis, Karsten Loesing, and Paul Syverson [1] https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR/Terminology [2] https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] A proposal to change hidden service terminology
Hello all, Several of us [0] working on hidden services have been talking about adopting better terminology. Some of the problems with current terms are 1. '''Hidden''' and '''Dark''' have a negative connotations. 2. '''Hidden-service website''' is too long; '''hidden site''' is too vague. 3. '''.onion''' (read dot onion) is hard to say and not very descriptive. 4. There is no general term for the set of available hidden services. 5. The term '''encrypted service''' is too general. This term refers to a setup (still needing development) in which Tor is required to connect to a service, but the service location is not hidden. Even without server anonymity, this setup can provide enforced client anonymity, secure name resolution, censorship circumvention, and end-to-end-encryption. Making the server location known can allow for improved performance (by shorter circuits) and security (by enabling location-aware path selection by the client). We’ve come up with the following suggestions for better terms, which we’d like to offer up for discussion: 1. '''onion service''' should be preferred to refer to what is now called a hidden service. If other flavors of onion services develop in the future, this term could refer to all of them, with more specific terms being used when it is necessary to make the distinction. 2. '''onionsite''' should be preferred to refer to a website (i.e. an HTTP service serving up HTML) available as an onion service. This can be extended to other specific types of services, such as '''onion chatroom''', '''onion storage''', '''onion cloud service''', etc. 3. '''onion address''' should be preferred to refer specifically to the xyz.onion address itself. 4. '''onionspace''' should be used to refer to the set of available onion services. For example, you can say “my site is in onionspace” instead of “my site is in the Dark Web”. 5. '''onion namespace''' should be used to refer to the set of onion addresses currently available or used recently (context-dependent). We couldn’t decide on the best names for alternative onion service setups, because they don’t exist yet! But, we have some ideas about how these things might be named: 1. Some names for a setup in which the onion service location is known but still must be connected to via the Tor protocol: * '''Tor-required service''', '''TRS''' for short * '''Direct onion service''', '''direct service''' for short 2. Some names to specify that the onion service is hidden, if that becomes necessary: * '''Protected onion service''', '''protected service''' for short * '''Tor-protected service''', '''TPS''' for short 3. Some names to specify that a client connects to an onion service non-anonymously: * '''Client-direct access''' * '''tor2web mode''' We’re maintaining an evolving wikipage with the above suggestions [1]. Some of us are already beginning to use the suggested terminology, to see how it works out. One nice goal might be for Tor to choose the new terms that it likes (if any) and use them in the rollout of next-gen onion services [2]. So we’re bringing up this subject now to a larger segment of the Tor community. Thoughts? Best, Aaron [0] Including David Goulet, Rob Jansen, George Kadianakis, Karsten Loesing, and Paul Syverson [1] https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR/Terminology [2] https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] A proposal to change hidden service terminology
Roger, your suggestion to prefer “onion service” regardless of any client or server short-circuiting is in line with our suggestions. When server-short-circuiting becomes an actual thing, then Paul may argue that a different name is appropriate (depending on if it uses an onion address, as I understand him), but that depends on the specifics of the design. As far as the “short-circuit” term itself, I personally think its cute and logical but a bit long (“server short-circuited onion service”?). Maybe you can think of a way to shorten it. In any case, I added it to the wiki [0]. My opinion is that no good recommendation can be made until there is a design, and the person that writes the design will probably get a big say in the name. I believe that Steven Murdoch has a student working on it… Best, Aaron [0] https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR/Terminology On Feb 10, 2015, at 2:11 PM, Paul Syverson paul.syver...@nrl.navy.mil wrote: On Tue, Feb 10, 2015 at 01:41:35PM -0500, Roger Dingledine wrote: On Tue, Feb 10, 2015 at 01:13:26PM -0500, A. Johnson wrote: 1. '''onion service''' should be preferred to refer to what is now called a hidden service. If other flavors of onion services develop in the future, this term could refer to all of them, with more specific terms being used when it is necessary to make the distinction. I'm a fan. 1. Some names for a setup in which the onion service location is known but still must be connected to via the Tor protocol: * '''Tor-required service''', '''TRS''' for short * '''Direct onion service''', '''direct service''' for short 2. Some names to specify that the onion service is hidden, if that becomes necessary: * '''Protected onion service''', '''protected service''' for short * '''Tor-protected service''', '''TPS''' for short You know how we call a person who makes an anonymous Facebook account over Tor and uses it without ever identifying herself to Facebook a Tor user? And how we also call a person who logs into her 'real' Facebook account over Tor a Tor user? Yes and? I think for more onion service scenarios than we think, we should just call them onion services and not specify which components of the rendezvous process are short-circuited and which aren't. The idea of a TRS/direct-onion-service/etc as we have been discussing it is a service where there is in all likelihood no rendezous (nor introduction point) at all. It is just necessary to connect to it via Tor. A naive way to implement this would be to have a server that only accepts connections from Tor relays (OK we could even require only Tor relays and only TLS). Presumably we want a somewhat smarter design than that. I don't want to set out anything smarter here. My goal is just to give the basic notion simply if not entirely accurately. The point is that it is an open question (that would be foolish to answer until the design and its use are more fully set out) whether we would want to give these .onion addresses (or force them to have .onion addresses to work with the protocol). And if they don't have (or only optionally have) .onion addresses, then calling them onionsites seems like a bad idea that can only foster confusion with the things that do have .onion addresses. And to give them .onion addresses just so we can apply the currently proposed terminology would be to do things bass ackwards. The current terminological proposal works well for heretofor Hidden Services and associated protocols and systems, even (and perhaps especially) when used for other purposes than hiding IP address of the service. What best to call these other future kinds of services at this point is quite bikeshed IMO. And for those situations where we're specifically talking about whether the rendezvous process is short-circuited on the client side and/or the service side... I wonder what people think of this 'short-circuited' term. (It is both an English idiom and also actually true.) Perhaps that will be good. Again I'd like to know what the design is doing before I try to name it. aloha, Paul ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] A proposal to change hidden service terminology
Good point. We (the Sponsor R group) have done no usability testing nor are we planning to. I don’t think we really have the time or skills for that, unfortunately. Maybe Tor more broadly has resources to put into a sophisticated re-branding effort. In any case, we do use these words every day and can make an intentional choice now. And for some things, words just didn’t even exist. Best, Aaron On Feb 10, 2015, at 2:22 PM, Adam Shostack a...@shostack.org wrote: On Tue, Feb 10, 2015 at 01:13:26PM -0500, A. Johnson wrote: | Hello all, | | Several of us [0] working on hidden services have been talking about adopting better terminology. Some of the problem | 1. '''onion service''' should be preferred to refer to what is now called a hidden service. If other flavors of onion services develop in the future, this term could refer to all of them, with more specific terms being used when it is necessary to make the distinction. | 2. '''onionsite''' should be preferred to refer to a website (i.e. an HTTP service serving up HTML) available as an onion service. This can be extended to other specific types of services, such as '''onion chatroom''', '''onion storage''', '''onion cloud service''', etc. | 3. '''onion address''' should be preferred to refer specifically to the xyz.onion address itself. | 4. '''onionspace''' should be used to refer to the set of available onion services. For example, you can say “my site is in onionspace” instead of “my site is in the Dark Web”. | 5. '''onion namespace''' should be used to refer to the set of onion addresses currently available or used recently (context-dependent). | Have you done usability testing to see how people react to the onion terms, how explainable they are to non-technical journalists, or what connotations it might have across cultures? My experience has been changing terminology is expensive and slow, and it's worth exploring lots of alternatives. Adam ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] A proposal to change hidden service terminology
A. Johnson wrote: Several of us [0] working on hidden services have been talking about adopting better terminology. In general, I am in agreement with this, but I wonder if now might be a good time to unify Tor terminology with other similar technologies like I2P and Cjdns/Hyperboria. I have heard someone (forget who) propose that 'Dark Web' be dropped in favour of CipherSpace which could include all of these privacy perserving protocols, leaving terms like OnionSpace for Tor, I2PSpace/EEPSpace for I2P etc. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [ooni-dev] Let's come up with the roadmap for the future of OONI
Dear Arturo and the other OONI-devs, I have a couple ideas I wanted to share about possible new projects or directions for OONI. 1. a traceroute idea I recently wrote a novel TCP traceroute implementation in golang called ParasiticTraceroute. It uses Linux NFQueue to mangle local TCP flows... altering the TTL and thus effecting a traceroute. Thus it does forward and reverse TCP traceroute... and if you traceroute your own server with this tool you might be able to learn interesting things about it clients... like for instance penetrate their NAT devices and learn the RFC1918 addresses of those NAT device interfaces. Perhaps. I haven't tried to do this yet. Leif Ryge, Aaron Gibson and I came up with this traceroute idea last year... and Leif recently suggested I write a traceroute server: it traceroutes the clients that connect to it... and then sends the traceroute results to the client... while concurrently the client performs a traceroute to the server. This results in the client procuring a traceroute for both directions; which is useful because asymmetrical routing. These traceroute-helper servers could be distributed around the world... and we could have an ooniprobe test query them to compare the current traceroutes with previous traceroutes to detect BGP route changes which under some circumstances but useful information about a censorship event... and perhaps help us identify which BGP ASNs are involved. Ethan Katz-Bassett and other researchers at University of Washington have done some really excellent research into designing an even more sophisticated reverse traceroute system. Their system does not require cooperative servers or clients... I highly recommend watching Ethan's video presentation or reading their paper: http://research.cs.washington.edu/networking/astronomy/reverse-traceroute.html 2. cooperate with ISPs/transit providers and Tor exit relay operators to collection statistics about interesting TCP events These events in my mind fall into 3 categories of interesting: - DOS attacks: SYN flood etc - censorship events: injected RST or FIN packets - injection attacks: segment veto, handshake hijack etc. The most interesting to me of course is the TCP injection attacks... It should be possible to gather very interesting statistics with help from the people running the network infrastructure even if there are strict telecommunications laws that prohibit the capturing of the content. I have started to work on a tool called HoneyBadger: it detects TCP injection attacks and performs full-take logging of all the data... however an anonymized or metadata only statistics gathering mode for HoneyBadger could be used by ISPs for instance. https://honeybadger.readthedocs.org/en/latest/ By the way... I'd really rather collaborate and receive peer review on these types of low-level network programming projects because it would be more fun and more effective to develop things like this with help and critical feedback. =-) Would OONI be interested in receiving statistics from network infrastructure providers about how often their transit users get TCP injected? Might it also be interesting to know how often users receive an injected RST or FIN from an automatic censorship device? btw I am very inspired by the work journalistic reporting work of Jake Appelbaum, Leif Ryge, Aaron Gibson, Morgan Mayhem who are writing articles to explain to the general public that plaintext protocols are especially vulnerable to these TCP injection attacks... AND that these attacks are often used for targeted surveillance by various groups around the world... and they are even selling ready made devices that automate these attacks. Would Tor Project/OONI be interested in helping to raise awareness of these issues? Sincerely, David Stainton On Tue, Feb 10, 2015 at 2:50 PM, Arturo Filastò a...@torproject.org wrote: Hello Oonitarians and Divisionists, I would love to have your feedback on what you believe to be the most important topics for the future of OONI. I have made a list of what I believe are all possible and interesting tasks to perform, but we can't do them all and for sure we can't do them all at once. For this reason it would be very useful if you could express a vote from 1-5: 1: Nah, this is boring and pointless 2: Not really super important, I would give priority to other stuff 3: Useful, I would do it 4: This would be awesome 5: Epic! Feel free to also expand these topics with questions and feedback (or new ones). At the end of the list I will give you a table to cast your vote. # Get daily OONI measurements from 50 countries This means focusing on getting a large and diverse reliable OONI userbase. It does not simply mean to get at least 1 measurement in 50 countries, but it means either establishing relationships with trusted parties in 50 countries, or expanding our userbase to a point where we have at least 1 measurement per day for every test per
