- tor-dev - lists.torproject.org

Re: [tor-dev] Fwd: Orbot roadmap feedback
by Nathan Freitas 15 Jan '16

15 Jan '16

On Tue, Jan 12, 2016, at 10:48 AM, Georg Koppen wrote: > Nathan Freitas: > > - Overall improved configuration / settings UI to make tuning Orbot a > > better, simpler experience... this is an expansion of the new exit > > country selector in Orbot v15.1, but also includes managing things like > > network usage and so on. > > Could you explain that point a bit more, what you currently have and > what you plan to do? Especially the exit country selector seems kind of > scary to me but maybe I am just missing some bits. I looked at the > changelog you sent to tor-talk (in the alpha 1 release mail) but did not > find anything related. The broader idea is to determine which Tor torrc settings are relevant to the mobile environment, and that could use a more intuitive user interface than the empty text input we currently offer in our Settings panel. This may also mean implement a slider type interface mechanism similar to Tor Browser. In addition, users are interested in being able to control which network types (wifi vs 3g) Orbot runs on, in order to conserve spending on bandwidth. The Exit country selector option (basically a list of countries that starts with "World" as the option) is definitely controversial, but it is also something that comes up over and over again as a feature request. It is expected especially of a VPN-style app, which Orbot now is. It may be we only enable it when the VPN feature is enabled, and disable it when Tor is used directly via SOCKS from the Orfox browser. We may also need to just sufficiently warn and inform the user so they can decide for themselves what to do. +n

4 3

txtorcon: ipaddress instead of ipaddr?
by meejah 14 Jan '16

14 Jan '16

Regarding https://github.com/meejah/txtorcon/pull/155 does anyone have a good reason not to move txtorcon to using "ipaddress" -- this is a built-in library on Python3, with backports to Python2. Thanks, meejah

1 0

Re: [tor-dev] Fwd: Orbot roadmap feedback
by Nathan Freitas 14 Jan '16

14 Jan '16

On Tue, Jan 12, 2016, at 11:52 AM, Michael Rogers wrote: > On 12/01/16 16:16, Nathan Freitas wrote: > > The broader idea is to determine which Tor torrc settings are relevant > > to the mobile environment, and that could use a more intuitive user > > interface than the empty text input we currently offer in our Settings > > panel. This may also mean implement a slider type interface mechanism > > similar to Tor Browser. In addition, users are interested in being able > > to control which network types (wifi vs 3g) Orbot runs on, in order to > > conserve spending on bandwidth. > > Briar's TorPlugin has an option to disable Tor when using mobile data, > feel free to backport it to Orbot. Likewise for the plugin as a whole, > if it would be a suitable basis for LibOrbot. We've benefitted a lot > from your work and I'd love to send some contributions back upstream! Is TorPlugin already a distinct library / module? +n

2 1

Needs Code Review: Shared Randomness Generation for Tor
by George Kadianakis 13 Jan '16

13 Jan '16

Hello there, we are happy to tell you that we finished coding proposal 250 and our first attempt at implementation is ready for review. You can find the final specification here: https://gitweb.torproject.org/user/dgoulet/torspec.git/log/?h=prop250_final… and the corresponding code here: https://gitweb.torproject.org/user/dgoulet/tor.git/log/?h=prop250_final_v1 Trac ticket #16943 (https://trac.torproject.org/projects/tor/ticket/16943) will be used for code review. Please use this mailing list to discuss any issues with the spec. Some notes: We've separated this in 7 commits prefixed with prop250: except first one that adds a needed tor_htonll/ntohll function to tor utils. This code is mostly contained in two *new* files (with their headers) that are shared-random.{c|h} and shared-random-state.{c|h}. For what it's worth, we expect this code to run for a long time before the shared random values generated by the authorities are used for anything (e.g. HSDir scrambling). Cheers!

3 3

Questions about censorship detection paper
by John 13 Jan '16

13 Jan '16

Hi, I ran into the technical report from George Danezis about an anomaly-based censorship-detection system for Tor. I have a few questions that I hope you can help me with. Is there an implementation available of the approach described in the paper? The paper talks about finding anomalies in the time series of the number of requests to directory servers from certain jurisdictions. Where can I find this data about the requests to directory servers? --john [1] https://research.torproject.org/techreports/detector-2011-09-09.pdf

2 3

Fwd: Orbot roadmap feedback
by Nathan Freitas 13 Jan '16

13 Jan '16

I've got big plans for Orbot in 2016... any thoughts on the roadmap below, particularly how it aligns with Tor core roadmap, would be appreciated. ----- Original message ----- From: Nathan of Guardian <nathan(a)guardianproject.info> To: guardian-dev(a)lists.mayfirst.org Subject: Orbot roadmap feedback Date: Mon, 11 Jan 2016 22:58:05 -0500 Here is my current set of brainstormed ideas for Orbot that I am currently working through... please add, edit, improve and prioritize as you are willing and able. - Continued inclusion of the latest and greatest pluggable transports (Obfs*, Meek, ???) - Improved support for requesting and configuring Obfs4 bridges - directly integrate with BridgeDB to provide streamlined way for people to get bridges where Tor is blocked - More Orbot VPN features including better UI for enabling/disabling Tor routing, blocking specific apps, ports and/or hosts, and general "firewall" or little snitch type features within the Orbot VPN - OrbotShare: an OnionShare inspired file sharing and download manager service to enable easy hidden service .onion setup and sharing (including support for new ephemeral onions) - OrbotRelay/Bridge: improved UI for running a bridge or relay from within Orbot, including support for scheduled times (night only) or states (only when plugged in, on wifi, and screen is off, etc) - Removal of Polipo, in favor of new streamlined in process HTTP proxy (less memory use, and more stable) - Creation of LibOrbot module/library for use by any app to embed Tor into their app - Overall improved configuration / settings UI to make tuning Orbot a better, simpler experience... this is an expansion of the new exit country selector in Orbot v15.1, but also includes managing things like network usage and so on. - OrbotWear / OrbotTV: Should we expand Orbot support to other Android platforms like watches and Smart TVs? Perhaps Orbot relay/bridge mode could run on a TV or set top box? - Some sort of "Pro" or Donation-ware version to allow a pay-what-you-can concept within the app Good, bad, ugly? Let me know! -- Nathan of Guardian nathan(a)guardianproject.info

3 2

Propsal 263 Quantum-safe Hybrid handshake for Tor, updated feature request
by Zhenfei Zhang 13 Jan '16

13 Jan '16

Hi list, Thanks for all your valuable comments. We have updated the feature request following your comments. Please see the attachment for the updated feature request, and see https://github.com/zhenfeizhang/ntru-tor/commit/0354fe1d61b2b79615301ff387e… for the modification over last version. Thanks for your time, and please let us know if you have any further comments/suggestions. Cheers, Zhenfei

2 1

Summary of meek's costs, December 2015
by David Fifield 12 Jan '16

12 Jan '16

Here's the summary of meek's CDN fees for December 2015. App Engine + Amazon + Azure = total by month February 2014 $0.09 + -- + -- = $0.09 March 2014 $0.00 + -- + -- = $0.00 April 2014 $0.73 + -- + -- = $0.73 May 2014 $0.69 + -- + -- = $0.69 June 2014 $0.65 + -- + -- = $0.65 July 2014 $0.56 + $0.00 + -- = $0.56 August 2014 $1.56 + $3.10 + -- = $4.66 September 2014 $4.02 + $4.59 + $0.00 = $8.61 October 2014 $40.85 + $130.29 + $0.00 = $171.14 November 2014 $224.67 + $362.60 + $0.00 = $587.27 December 2014 $326.81 + $417.31 + $0.00 = $744.12 January 2015 $464.37 + $669.02 + $0.00 = $1133.39 February 2015 $650.53 + $604.83 + $0.00 = $1255.36 March 2015 $690.29 + $815.68 + $0.00 = $1505.97 April 2015 $886.43 + $785.37 + $0.00 = $1671.80 May 2015 $871.64 + $896.39 + $0.00 = $1768.03 June 2015 $601.83 + $820.00 + $0.00 = $1421.83 July 2015 $732.01 + $837.08 + $0.00 = $1569.09 August 2015 $656.76 + $819.59 + $154.89 = $1631.24 September 2015 $617.08 + $710.75 + $490.58 = $1818.41 October 2015 $672.01 + $110.72 + $300.64 = $1083.37 November 2015 $602.35 + $474.13 + $174.18 = $1250.66 December 2015 $561.29 + $603.27 + $172.60 = $1337.16 -- total by CDN $8607.22 + $9064.72 + $1292.89 = $18964.83 grand total https://metrics.torproject.org/userstats-bridge-transport.html?graph=userst… The number of users increased by about 1,000 in December 2015. meek-google had an outage as a result of a server migration between 23 November and 4 December. I set up a bridge that is not rate-limited. If you use it, your meek will go a lot faster. https://bugs.torproject.org/17890 The catch is that you have to set up a CDN or upload a PHP file yourself. Here are some docs to look at: https://trac.torproject.org/projects/tor/wiki/doc/meek#Howtorunameek-server… https://trac.torproject.org/projects/tor/wiki/doc/meek#GoogleAppEngine https://trac.torproject.org/projects/tor/wiki/doc/meek#AmazonCloudFront https://trac.torproject.org/projects/tor/wiki/doc/meek#MicrosoftAzure == App Engine a.k.a. meek-google == Here is how the Google costs broke down: 2528 GB $303.39 5158 instance hours $257.90 Compared to the previous month: 2162 GB $259.52 6856 instance hours $342.83 https://globe.torproject.org/#/bridge/88F745840F47CE0C6A4FE61D827950B06F9E4… == Amazon a.k.a. meek-amazon == Asia Pacific (Singapore) 56M requests $67.98 425 GB $58.83 Asia Pacific (Sydney) 2M requests $3.37 10 GB $1.41 Asia Pacific (Tokyo) 30M requests $37.14 242 GB $31.64 EU (Ireland) 142M requests $171.48 968 GB $76.50 South America (Sao Paulo) 5M requests $11.03 31 GB $7.46 US East (Northern Virginia) 86M requests $86.54 635 GB $49.88 -- total 324M requests $377.54 2314 GB $225.72 https://globe.torproject.org/#/bridge/F4AD82B2032EDEF6C02C5A529C42CFAFE5165… == Azure a.k.a. meek-azure == Zone 1 1560 GB $135.71 Zone 2 267 GB $ 36.89 -- total 1827 GB $172.60 https://globe.torproject.org/#/bridge/AA033EEB61601B2B7312D89B62AAA23DC3ED8… Earlier reports in this series: https://trac.torproject.org/projects/tor/wiki/doc/meek#Costs

2 5

Transparent proxying: automagically add firewall rules
by Rene Bartsch 12 Jan '16

12 Jan '16

Hi, transparent proxying to TOR Hidden Services is a great feature of the TOR daemon when it comes to other applications/protocols than HTTP and surfing. It would also be great with privacy appliances (e.g. Mailpile using TOR as secure SMTP transport channel). John Does have problems with such a setup because of the NAT firewall rules. So I suggest the TOR daemon should automagically set the necessary NAT-rules on Windows, Linux and BSD when "TransPort" and "VirtualAddrNetworkIPv[4|6]" are configured in torrc. -- Best regards, Renne

2 1

Tor Control Protocol: multiple commands in a single line possible?
by Patrick Schleizer 11 Jan '16

11 Jan '16

TLDR: Does Tor's control protocol actually support something like ; ? I.e. something like signal newnym ; getinfo address ? How many of there separators are there? Can you provide examples please? Background: At the moment we are implementing support for whitelisting wildcards for control-port-filter-proxy-python [0] to support Onionshare and Ricochet. [1] [2] [3] [4] Does Tor's control protocol actually support something like ; ? If it does, then this would complicate the wildcard feature. If we whitelisted the wildcard add_onion *, we don't want it to match some hypothetical feature add_onion * ; .... I.e. not add_onion * ; GETINFO address. (If it was the case, then we would have to limit the wildcard (*) from example SETCONF HiddenServicePort * to exactly one [numeric] argument etc. Or better, correctly parse multi lined commands. Or as stopgap, reject these separators since no applications using Tor's control protocol are currently using those.) Cheers, Patrick [0] https://github.com/Whonix/control-port-filter-python https://www.whonix.org/wiki/Dev/Control_Port_Filter_Proxy [1] https://phabricator.whonix.org/T446 [2] https://phabricator.whonix.org/T445 [3] https://www.whonix.org/wiki/Next#onionshare [4] https://phabricator.whonix.org/T448 (Asked Roger by mail, said it's okay to post this on tor-dev.)

4 3