- tor-dev - lists.torproject.org

Circuit times
by grarpamp 04 Apr '17

04 Apr '17

Anything going to blow up if set anywhere from 1k to 1M? CBT_NCIRCUITS_TO_OBSERVE

1 0

[prop269] [prop270] Ideas from Tor Meeting Discussion on Post-Quantum Crypto
by isis agora lovecruft 03 Apr '17

03 Apr '17

Hey hey, In summary of the breakaway group we had last Saturday on post-quantum cryptography in Tor, there were a few potentially good ideas I wrote down, just in case they didn't make it into the meeting notes: * A client should be able to configure "I require my entire circuit to have PQ handshakes" and "I require at least one handshake in my circuits to be PQ". (Previously, we had only considered having consensus parameters, in order to turn the feature on e.g. once 20% of relays supported the new handshake method.) * Using stateful hash-based signatures to sign descriptors and/or consensus documents, and (later) if state has been lost or compromised, then request the last such document submitted to regain state (probably skipping over all the leaves of the last used node in the tree, or the equivalent, to be safe). (This requires more concrete design analysis, including the effects of the large size of hash-based signatures on the directory bandwidth usage, probably in a proposal or longer write up, should someone awesome decides to research this idea further. :) Thanks to everyone involved in the breakaway group, and I apologise, but I don't actually remember all the attendants off the top of my head. If either of these were your idea, please message me off-list and I'll ensure you're credited in the eventual proposal(s)/documentation. Best regards, -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://fyb.patternsinthevoid.net/isis.txt

2 2

Re: [tor-dev] GSoC 2017 - unMessage: a privacy enhanced instant messenger
by Felipe Dau 03 Apr '17

03 Apr '17

Here is an update with the final proposal I submitted to GSoC. Thanks, -Felipe # unMessage: an anonymity enhanced instant messenger In an age where spying, surveillance and censorship evidently became regular practices by various kinds of attackers, it is sensible to be concerned about instant messaging applications, which are very popular communication tools that handle private and identifying information. Such a scenario demands solutions to prevent users from harm these attacks might cause. There are currently good solutions such as [Signal], [Wire] and [OMEMO] apps that make end-to-end encrypted conversations possible. Although such apps successfully provide privacy, they have a great dependency on servers and metadata in order to work and they are not able to provide anonymity. An app that solves this problem is [Ricochet], by not having such dependencies. However, it heavily relies on the transport it uses and does not offer its own encryption layer. [unMessage] is also one of those solutions: a peer-to-peer anonymity enhanced instant messenger written in Python that I have been working on for a while with [David Andersen] - my advisor. unMessage uses its own end-to-end encrypted [protocol] to maintain conversations, focusing in not depending on servers, metadata and transport. We have recently released an alpha version which should be easy for developers to install and test its current features such as message exchanges, authentication, and voice chat, but there is still a lot of work to do in order to achieve a mature state where users can trust it due to its properties and usability. As we believe unMessage has potential to become a great anonymity enhancing app with a code that is simple, readable and therefore easy to maintain, I propose to work on it during this year's Google Summer of Code with the support of the Tor Community to to make it closer to maturity. We expect to implement fixes, improvements and features from our discussions (on its [tracker] and [tor-dev]) in order to turn it into a maintainable, feature-rich and useful app which everyone can benefit from. ## Technologies unMessage's features were possible with the use of the following technologies: - Transport makes use of [Twisted], [Tor Onion Services] and [txtorcon] - Encryption is performed using the [Double Ratchet Algorithm] implemented in [pyaxo] - which uses [PyNaCl] - Authentication makes use of the [Socialist Millionaire Protocol] implemented in [Cryptully] - Transport metadata is minimized by Tor and application metadata by the unMessage [protocol] - User interfaces are created with [Tkinter] for the [GUI] and [curses] for the [CLI] - Voice chat uses the [Opus codec] for constant bitrate encoding ## Contributions Since its current (alpha) release, we have been discussing it with [Patrick Schleizer] and [HulaHoop] from [Whonix], who are making great contributions to help us test it, as well as suggesting new features and improvements. We are also working to run it on Whonix (which will allow it to be run on Tails as well) with help from [meejah] by adding a new feature to txtorcon to make unMessage (and all the apps that use txtorcon) "Control Port Filter friendly". Since the introduction of this project for GSoC, [dawuud] and [meejah] became interested in contributing and mentoring it and also assisted me on making this proposal. ## Tasks The project is split into tasks, each assigned an ID (in parenthesis) that is used to compose the timeline. I have been generous with how much time each task will demand and I am also leaving the whole week of each evaluation to review and make sure the deliverables meet expectations. Therefore, it is possible that I am able to work on additional tasks in case they consume less time than planned. ### Improve setup script (T1) This task will improve unMessage's `setup.py` by removing redundant package metadata, use files for the requirements and offer development requirements. This task will be tracked in [issue 35]. ### Use attrs (T2) [attrs] is used to simplify the code by removing boilerplate, make it more concise, and consequently improve its quality. Classes definitions will be modified to use attrs' declarations so that attributes have default types and values, as well as validation. This task will be tracked in [issue 34]. ### Support file transfer (T3) unMessage is able to support various elements of a conversation such as requests, messages and authentication. New elements to transmit file requests and the actual files will be added and handle by the elements parser. This task will be tracked in [issue 12]. ### Add a logger (T4) There is currently no logging being done and in order to debug, the only possible approach is using the UIs. A module will be added to send logs to the terminal and a file. This task will be tracked in [issue 30]. ### Make functions/methods asynchronous (T5) unMessage's initial implementation did not use Twisted and it had pre-defined callbacks in order to continue the path of the action it was performing. It later migrated to Twisted but the pre-defined callbacks are still used. Such callbacks will be removed and the functions that are part of these asynchronous actions will return `Deferred`s to make an actual callback chain. This task will be tracked in [issue 21]. *This task will be split into two (T5A and T5B) as it poses a higher level of complexity. I intend to deliver its first version, receive feedback from mentors and make another iteration so that it meets our expectations.* ### Add a test suite (T6) There is not a single test written for unMessage and that is crucial to continue its development. The test suite will be made with [pytest] and will also use [hypothesis] for fuzzing/property tests. Not only tests will be written, but some parts of the code will be refactored. I do not expect to achieve 100% converage, but test the most important parts of unMessage (mainly the `peer` module). Also, as I am not familiar with User Interface tests, these will not be part of the task (we are also planning to use a different framework for the GUI, so its tests will only be created after there is a decision). This task will be tracked in [issue 33]. *This task will be split into two (T6A and T6B) as it poses a higher level of complexity. I intend to deliver its first version, receive feedback from mentors and make another iteration so that it meets our expectations.* ### Deliverables - Mid-term 1: Tasks 1, 2, 3 and 4 - Mid-term 2: Tasks 5A and 6A - Final: Tasks 5B and 6B ### Timeline Tasks/Weeks | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 ------------+---+---+---+---+---+---+---+---+---+----+----+----+---- T1 | X | | | | | | | | | | | | ------------+---+---+---+---+---+---+---+---+---+----+----+----+---- T2 | X | | | | | | | | | | | | ------------+---+---+---+---+---+---+---+---+---+----+----+----+---- T3 | X | X | | | | | | | | | | | ------------+---+---+---+---+---+---+---+---+---+----+----+----+---- T4 | | X | X | | | | | | | | | | ------------+---+---+---+---+---+---+---+---+---+----+----+----+---- T5A | | | | X | | X | | | | | | | ------------+---+---+---+---+---+---+---+---+---+----+----+----+---- Mid-term 1 | | | | | X | | | | | | | | ------------+---+---+---+---+---+---+---+---+---+----+----+----+---- T6A | | | | | | | X | X | | | | | ------------+---+---+---+---+---+---+---+---+---+----+----+----+---- Mid-term 2 | | | | | | | | | X | | | | ------------+---+---+---+---+---+---+---+---+---+----+----+----+---- T5B | | | | | | | | | | X | | | ------------+---+---+---+---+---+---+---+---+---+----+----+----+---- T6B | | | | | | | | | | | X | X | ------------+---+---+---+---+---+---+---+---+---+----+----+----+---- Final | | | | | | | | | | | | | X ### Stretch goals As mentioned in the previous section, depending on how the development of each task it is possible that there will be more time avaialable to work on other ones. We would like to prioritize The following tasks in case that happens. #### Use automat There are certain objects in unMessage that are state machines. Their implementation are very simple and limited as initially they were not designed as state machines. In order to turn them into real state machines, [automat] will be used. This task will be tracked in [issue 26]. #### Offline messages As part of unMessage's design, no servers are used to establish and maintain conversations. As a consequence, peer-to-peer communication requires users to only be able to chat while both are online. Although unMessage's protocol supports asynchronous communication, this limitation forces conversations to be synchronous. In order to solve this problem, a [Tahoe-LAFS] grid will be used to temporarily store unMessage's packets for peers that were not available when they were sent and can be retrieved later once the peers are online. This task will be tracked in [issue 32]. # Background I am a Senior studying Computer Engineering at the Federal Technological University of Parana in Brazil. In January of 2014 I went to the U.S. for an exchange program, which lasted until December. During the Summer of that same year, I joined a research project lead by David Andersen where I learned about Anonymous Communication and became so attracted to the field that I continued to be part of the project since then. We have mostly worked on [nymphemeral], [pyaxo], [nymserv] and recently, unMessage. # Code sample I have a few repositories on my [GitHub profile] and I recommend taking a look at the ones referenced above, but specially [unMessage] and [nymphemeral], which are the ones I have mostly worked on. # Why The Tor Project? As I mentioned, I have been studying Anonymous Communication for almost three years now and I intend to keep doing it not only because I enjoy it, but because it is an important field capable of helping millions of people around the world. In my opinion, The Tor Project is the biggest organization of its kind and working with people responsible for software I run everyday is a dream of every developer. The Tor community continues to grow every day and I believe that participating in the Google Summer of Code will also contribute to that. # Experiences with free software development environments Since I joined the research project, I have been mostly working with David Andersen on the projects I mentioned previously and git/GitHub make our work a lot easier to work in parallel on the same code, manage tickets to help us keep track of the development and interact with contributors interested in what we do. Whenever I see a project which I can contribute to, even if a it is a small change, I open a ticket or make a pull request if I am able to. My [GitHub profile] lists all my contributions. PyNaCl is one of the recent projects I contributed to. While working on pyaxo I noticed some of the encryption calls could be improved to simplify their usage by making an argument optional. The developer who reviewed the pull request was very positive about it and assisted me while updating the docs to cover this new change. While working on unMessage I asked Patrick Schleizer and HulaHoop for help as it would be great to have it running on Whonix. We have had great discussions and contributed to both projects in order to provide this feature. Along with the development, some changes to txtorcon were appreciated and we have also been working with meejah on that. # Commitment I have concluded all classes for my degree and I am currently an industrial IT intern at an Engineering and Software company, which is the only commitment I will have besides GSoC throught the duration of the program. I intend to work on unMessage 5~6 hours on weekdays and the remainder of the workload on weekends. # Post GSoC The tasks we picked to work on GSoC are a subset of all the ones we have been discussing during unMessage's development, which means that there will be more work to be done after GSoC. Also, unMessage is quite a big project. There are lots of possibilities to explore in the instant messaging field as well as many challenges to overcome when offering an application with usability and features as good as the popular ones, while protecting users' privacy and anonymity. I intend to keep working on unMessage until we have an application that accomplishes our goals as well as maintain it to fix bugs and add features demanded by the community. Also, as I have been working with anonymous communication for a while, I do not see myself going somewhere else soon, so the chances of keeping contributing the Tor community are high. # Communication I intend to use IRC to discuss with my mentor and other tor devs (who wish to contribute to the project) about ideas and actions to be taken. To formalize what is discussed on IRC, I will use unMessage's tracker on GitHub to manage features/enhancements/issues to keep records and maintain an organized environment for the development of the project, as well as interact with contributors. I am suggesting this tracker as we have already been using it for a while, but I can migrate to Tor's Trac if needed. To summarize everything, I will do what seems to have worked well for previous students: regular reports on the mailing list to keep people updated with what is happening on the project from a higher level. ## Contact info OFTC: dau Email: dau(a)riseup.net PGP: 0xC5A49047572A0D47 # Other GSoC projects in mind? I am only applying to this one. # Anything else? I encourage you to take a look at the git logs and issue trackers from [unMessage], [nymphemeral] and [pyaxo]. I think I am a very organized developer and I have been trying my best to follow the gitflow model and take advantage of the features offered by GitHub. [attrs]: https://attrs.readthedocs.io [automat]: https://github.com/glyph/automat [cli]: https://unmessage.readthedocs.io/en/latest/cli/cli.html [cryptully]: https://github.com/shanet/Cryptully [curses]: https://docs.python.org/2/library/curses.html [david andersen]: https://github.com/rxcomm [dawuud]: https://github.com/david415 [documentation]: https://unmessage.readthedocs.io [double ratchet algorithm]: https://whispersystems.org/docs/specifications/doubleratchet [github profile]: https://github.com/felipedau [gui]: https://unmessage.readthedocs.io/en/latest/gui/gui.html [hulahoop]: https://github.com/HulaHoopWhonix [hypothesis]: https://hypothesis.readthedocs.io [issue 12]: https://github.com/AnemoneLabs/unmessage/issues/12 [issue 21]: https://github.com/AnemoneLabs/unmessage/issues/21 [issue 26]: https://github.com/AnemoneLabs/unmessage/issues/26 [issue 30]: https://github.com/AnemoneLabs/unmessage/issues/30 [issue 32]: https://github.com/AnemoneLabs/unmessage/issues/32 [issue 33]: https://github.com/AnemoneLabs/unmessage/issues/33 [issue 34]: https://github.com/AnemoneLabs/unmessage/issues/34 [issue 35]: https://github.com/AnemoneLabs/unmessage/issues/35 [meejah]: https://github.com/meejah [nymphemeral]: https://github.com/felipedau/nymphemeral [nymserv]: https://github.com/rxcomm/nymserv [omemo]: https://conversations.im/omemo [opus codec]: https://opus-codec.org [patrick schleizer]: https://github.com/adrelanos [protocol]: https://unmessage.readthedocs.io/en/latest/protocol.html [pyaxo]: https://github.com/rxcomm/pyaxo [pynacl]: https://github.com/pyca/pynacl [pytest]: http://docs.pytest.org [ricochet]: https://ricochet.im [signal]: https://whispersystems.org [socialist millionaire protocol]: https://en.wikipedia.org/wiki/Socialist_millionaire [tahoe-lafs]: https://github.com/tahoe-lafs/tahoe-lafs [tkinter]: https://docs.python.org/2/library/tkinter.html [tor onion services]: https://www.torproject.org/docs/hidden-services.html [tor-dev]: https://lists.torproject.org/pipermail/tor-dev [tracker]: https://github.com/AnemoneLabs/unmessage/issues [twisted]: https://twistedmatrix.com [txtorcon]: https://github.com/meejah/txtorcon [unmessage]: https://github.com/AnemoneLabs/unmessage [whonix]: https://whonix.org [wire]: https://wire.com

1 0

GSoC 2017 - Project "Onionoo"
by Nur-Magomed 03 Apr '17

03 Apr '17

Hi! I’m Nur-Magomed Dzhamiev, 4th year student from institute of information technology (speciality: computer security) of North-Caucasus Federal University. I have experience with Java, SQL, Web (HTML, CSS, JavaScript, PHP) and also I designed protocol based on JSON for Android app. I would love to contribute to the project "Onionoo". Please provide me some guide lines and additional materials for study and get a clear understanding about the mentioned project. Thank you! Regards Nur-Magomed

6 17

GSoC: Questions on allowing for more DNS request types
by Lucille Newman 03 Apr '17

03 Apr '17

Hello, I was interested in the project for allowing any kind of DNS support in Tor for GSoC, or, since it is late for that deadline, then also otherwise. After reading proposal 219, I have some questions. 1. A comment by NM suggests that we should specify exact behavior when generating DNS packets (line 56). Should the DNS packets not be generated as according to RFC 1035? Are there other things that need to be taken into consideration here? 2. Another comment (line 63) asks whether 496 bytes is enough for the DNS packet of a DNS_BEGIN cell. Since QNAME can be arbitrarily long, I suppose it is possible that 496 is not enough? If this seems like a reasonable concern, then maybe we could do a similar thing to the DNS_RESPONSE cells with allowing multiple cells for a single question and having a flag to indicate the last cell? 3. What would cause a DNS_BEGIN request or response to be aborted (line 105)? 4. How do we differentiate special names like .onion, .exit, .noconnect (line 145)? 5. The comments at (lines 135-143) indicate that it might not be necessary or practical to refuse requests that resolve to local addresses. This means that such queries will not be sent, but an error will be returned before sending to a DNS server? Thanks so much. Best, Lucy

2 1

Tor in a safer language: Network team update from Amsterdam
by Sebastian Hahn 03 Apr '17

03 Apr '17

Hi there tor-dev, as an update to those who didn't have the chance to meet with us in Amsterdam or those who haven't followed the efforts to rely on C less, here's what happened at the "let's not fight about Go versus Rust, but talk about how to migrate Tor to a safer language" session and what happened after. Notes from session: We didn't fight about Rust or Go or modern C++. Instead, we focused on identifying goals for migrating Tor to a memory-safe language, and how to get there. With that frame of reference, Rust emerged as a extremely strong candidate for the incremental improvement style that we considered necessary. We were strongly advised to not use cgo, by people who have used it extensively. As there are clearly a lot of unknowns with this endeavor, and a lot that we will learn/come up against along the way, we feel that Rust is a compelling option to start with, with the caveat that we will first experiment, learn from the experience, and then build on what we learn. You can also check out the session notes on the wiki (submitted, but not posted yet).[1] The real fun part started after the session. We got together to actually make a plan for an experiment and to give Rust a serious chance. We quickly got a few trivial things working like statically linking Rust into Tor, integrating with the build system to call out to cargo for the Rust build, and using Tor's allocator from Rust. We're planning to write up a blog post summarizing our experiences so far while hopefully poking the Rust developers to prioritize the missing features so we can stop using nightly Rust soon (~months, instead of years). We want to have a patch merged into tor soon so you can all play with your dev setup to help identify any challenges. We want to stress that this is an optional experiment for now, we would love feedback but nobody is paid to work on this and nobody is expected to spend more time than they have sitting around. We have committed to reviewing any patch that includes any Rust code to provide feedback, get experience to develop a style, and actually make use of this experiment. This means we're not ready to take on big patches that add lots of tricky stuff quite now, we want to take it slow and learn from this. We would like to do a session at the next dev meeting to give updates on this effort, but in the meantime, if team members would like to start learning Rust and helping us identify/implement small and well-isolated areas to begin migration, or new pieces of functionality that we can build immediately in Rust, that would be really great. So, for a TLDR: What has already been done: - Rust in Tor build - Putting together environment setup instructions and a (very small) initial draft for coding standards - Initial work to identify good candidates for migration (not tightly interdependent) What we think are next steps: - Define conventions for the API boundary between Rust and C - Add a non-trivial Rust API and deploy with a flag to optionally use (to test support with a safe fallback) - Learn from similar projects - Add automated tooling for Rust, such as linting and testing Cheers Alex, Chelsea, Sebastian [1]: Will be visible here https://trac.torproject.org/projects/tor/wiki/org/meetings/2017Amsterdam/No…

4 3

Re: [tor-dev] GSoC 2017 - Feedback Extension for Tor Browser
by Jayati Dev 03 Apr '17

03 Apr '17

Dear Mentor, Please find my draft application here: https://docs.google.com/document/d/1AItxT3k-K1tSHa0OJDl3AC4BL_xYoCUWv6IHDnb…. I have also uploaded it through the GSoC 2017 Official Website. Thank you for your time and effort, Sincerely, Jayati Dev

2 1

Mailing List Etiquette Reminder
by grarpamp 02 Apr '17

02 Apr '17

New members are very welcome and valued whether through gradual accretion or project influx such as GSOC's. In order to ensure messaging efficiency and clarity... - Reply *below* what others have written. Do not "top post". - Trim out and *delete* irrelavant portions of what others have written, so to clearly include only that part of which you are replying to. Do not "bulk quote" chains of replies. - *Interleave* your replies within the physical lines others have written so that what specific part you are replying to is clear. "Reply in context." - Use "text/plain UTF-8" encoding, disable all "HTML" when sending. - Wrap message lines at roughly 68-72 characters long. - Be aware of how changing subject line, and reply-to and references headers can break threading, and use it carefully. For more info you can search "mailing list etiquette" on any search engine. Thanks.

1 0

GSoC 2017 - unMessage: a privacy enhanced instant messenger
by Felipe Dau 02 Apr '17

02 Apr '17

Hello, I am a Computer Engineering student at the Federal Technological University of Parana in Brazil and I would like to present you a peer-to-peer privacy enhanced instant messenger called unMessage [0]. I have been working on it for a while with David Andersen [1] (my advisor) and we have recently released an alpha version which should be easy for developers to install and test. It uses the Double Ratchet Algorithm [2] for encryption, Onion Services for transport metadata minimization, its own protocol for application metadata minimization, and as a result, provides private and anonymous conversations. It currently has basic features such as message exchange, user authentication and we very recently enabled voice chat using the Opus codec [3] for constant bitrate encoding. unMessage is a Python application that mainly uses pyaxo's [4] implementation of Double Ratchet Algorithm and txtorcon's [5] implementation of the Tor Control Protocol. Since its current (alpha) release, we have been discussing it with Patrick Schleizer [6] and HulaHoop [7] from Whonix [8], who are making great contributions to help us test it, as well as suggesting new features and improvements. We are also working to run it on Whonix (which will also allow it to be run on Tails) with help from meejah [9] by adding a new feature to txtorcon to make unMessage (and all the apps that use txtorcon) "Control Port Filter friendly". As we believe unMessage has potential to become a great privacy enhancing app with a code that is simple, readable and therefore easy to maintain, Patrick suggested that I submitted a proposal to have unMessage as one of the GSoC projects. We expect to implement fixes, improvements and features from our discussions in order to turn it into a maintainable, feature-rich and useful app which the community can benefit from. There are currently some "developer centered" tasks I can work on such as: - Create a test suite (with pytest) - Make unMessage's own functions/methods behave like a Twisted API should - Use automat for its finite-state machines - Make use of a logging tool - Improve comments/document the code As well as some "user centered" tasks: - Whonix/Tails support - Improve the GUI and CLI - File transfer - Use a friendlier approach for users to handle keys instead of the current base32/64 encodings - Connect/launch Tor automatically depending on what is available - Offline messages (All the other ones can be found in the issue tracker [10]) My intention with this post is not only to present unMessage to tor-dev but also see if someone is interested in mentoring me as it is not one of the official ideas but hopefully sounds like a good project. If someone gets interested, please let me know so that we can discuss which tasks would be interesting for this project and I am able to write a proposal. Thanks! -Felipe [0]: https://github.com/AnemoneLabs/unmessage [1]: https://github.com/rxcomm [2]: https://whispersystems.org/docs/specifications/doubleratchet [3]: https://opus-codec.org [4]: https://github.com/anemonelabs/pyaxo [5]: https://github.com/meejah/txtorcon [6]: https://github.com/adrelanos [7]: https://github.com/HulaHoopWhonix [8]: https://whonix.org [9]: https://github.com/meejah [10]: https://github.com/AnemoneLabs/unmessage/issues

4 13

Re: [tor-dev] Anonymous Local Count Statistics Using PCSA - GSoC
by Jaskaran Singh 02 Apr '17

02 Apr '17

Oops, clicked the SEND button accidentally. Sorry! You can ignore it. > Ah! That reminds me that OP(of this thread) should also aim to fix #8786 > along with that could enable such a counting technique for Pluggable > transports. > > Now coming to the main point, > >> In addition, each user doesn’t necessarily correspond to >> a different IP because of NAT, and so counting connections may actually be >> more accurate. > I agree, -- Jaskaran Veer Singh (jvsg) jvsg1303 at gmail dot com PGP 2814 3FB7 A32D 429B 092E 27F0 8AA3 C532 9E1A 6AD8

1 0

Anonymous Local Count Statistics Using PCSA - GSoC
by samir menon 02 Apr '17

02 Apr '17

Hi there! I'm Samir, a Computer Science student at Stanford University, with a focus in applied cryptography and computer security. This summer, I want to work (through GSoC) on computing usage statistics without keeping IP addresses in memory (see tickets #7532 and #15469) [1] [2]. Currently, we keep sets of IP's (or hashed IP's) in memory so that we can compute the number of unique client connections. This has been pointed out as a pretty serious concern, because the IP's themselves are sensitive info that we don't want an attacker to acquire, but the statistics are relatively valuable. As Nick first pointed out in #15469, we can use proven techniques to compute these statistics without actually explicitly storing any IP's (or IP hashes) in memory. The technique I want to use, "Probabilistic Counting with Stochastic Averaging", or PCSA, is relatively well-studied, and can provide good estimates (<5% error) of the number of unique elements in a time series. The basic idea is to count the number of 0's before the least significant 1 in every (Jenkins hashed) IP, and then recognize that the more unique IP's we encounter, the more likely it is that we see a hashed IP with a large number of 0's before the least significant 1. (Shoutout to Jaskaran and [3] for helping me understand this). A more detailed explanation and more resources for understanding PCSA are in the proposal. Here is my draft proposal (also attached, but links don't work): http://stanford.edu/~samir2/TorGSoCApplication.html I'd love to hear feedback on it - what's feasible, what's most useful, and what I should focus on, etc. You can also chat with me about it on IRC at `samir2`! Thanks, ~Samir Menon menon.samir(a)gmail.com Stanford University, B.S. Computer Science, 2019 [1] https://trac.torproject.org/projects/tor/ticket/7532 [2] https://trac.torproject.org/projects/tor/ticket/15469 [3] https://www.cs.princeton.edu/~rs/talks/AC11-Cardinality.pdf

6 9

GSoC 2017 - Feedback Extension for Tor Browser
by Jayati Dev 02 Apr '17

02 Apr '17

Dear Mentors, I am a final year student in Electronics and Communication Engineering, and I wanted to work on the 'Feedback Extension for Tor Browser' project as a part of GSoC 2017. I have been working on the design and implementation of the extension here https://github.com/devjayati/TestExtension (which also serves as a qualifcation task). I have also made a draft proposal and submitted it for review. If there isn't anyone already assigned to the project, it would be wonderful if you could please consider my proposal and also comment on the draft. Sincerely, Jayati Dev

2 1

Proposal xyz : Count Unique IP addresses in an anonymous way
by Jaskaran Singh 02 Apr '17

02 Apr '17

Hi, Please have a look at this proposal. Will replace xyz with more meaningful numbers once this is finalized. Comments, suggestions and criticism are welcome. ------------- Filename: xxx-Count-unique-IPs-in-anonymous-way.txt Title: Count Unique IP addresses in an anonymous way Author: Jaskaran Veer Singh Created: 14 March 2017 Status: Draft §0. Introduction Currently, guard relays and bridges maintains a list of IP addresses of the devices that connect to it for various reasons such as for use by the bridge to check which country has them blocked. This is dangerous because if any of these tor instances get compromised, clients will be de-anonymized. To solve this issue, a new data structure that keeps a track of unique IP addresses seen but does not directly keep a list of them is proposed in this document. §1. Specification §1.1. Notation Let `a^b` denote the exponentiation of a to the bth power. Let `a == b` denote the equality of a with b, and vice versa. Let `a := b` be the assignment of the value of b to the variable a. Let `a / b` denote the division of a by b. Let `a <= b` denote that a is less than equal to b. Let `a >= b` denote that a is greater than equal to b. §2. Research There are three ways to solve this problem. All the three ways are actually Big Data Algorithms. A few problems arises for each of these algorithms since they are made for big data but the data we would provide is not necessarily big. §2.1. Bloom Filter[1] A bloom filter maps the input to positions on the bitmap after passing through 2 or more hash functions. Later any new input are mapped onto this bitmap in the same way to check whether this value is already present in the set. The feature of this bitmap is that collisions could happen. And this collision creates deniability. When collisions happen, On the one hand, one of the input doesn’t count to be unique (although in reality, it is), and on the other hand, this is beneficial since this creates deniability. The person who gets hand on this data structure could never be 100% sure about the original inputs. So we get the job done successfully at some error rate. §3.1.1. Obstacle Suppose if the number of inputs is small. Let’s say we receive just 1 connection in a day from some small, less busy country like Estonia. In that case, there might not be any chance for collision and the adversary could determine the IP address with some brute force. Hence this algorithm isn’t suited for us. §3.2. Rappor[2] Randomized Aggregatable Privacy Preserving Ordinal Responses is an algorithm where the system adds some deterministic and nondeterministic noise to the data that has to be stored. This creates deniability. In our case, we don’t need to have deterministic noise added at first stage. So we’ll just stick to adding non deterministic noise and storing it in a bloom filter. One thing to note here is that, we should not accept output of the non deterministic randomizer which can be traced back to any IP address of Group D or Group E since those IP addresses are not in use and the adversary could easily know that those have been produced after adding random noise. §3.2.1. Obstacle Using brute force technique, the adversary could check to see whether the IP address stored is the correct one or produced using random noise. In this technique, the adversary could compare those IP address (obtained via brute force) to the directory of what IP addresses are allotted to what country. The one that does not match, is the one that has been faked by using random noise. §3.3. Probabilistic Counting with Stochastic Averaging[3] (PCSA) It is based on FM sketches. The algorithm goes as follows: | m = 2^b # with b in [4...16] | bitmaps = [[0]*32]*m # initialize m 32bit wide bitmaps to 0s | | # Construct the PCSA bitmaps | for h in hashed(data): | bitmap_index = 1 + get_bitmap_index( h,b ) # binary address of rightmost b bits | run_length = run_of_zeros( h,b ) # length of the run of zeros starting at bit b+1 | bitmaps[bitmap_index][run_length] = 1 # set the bitmap bit based on the run length observed | | # Determine the cardinality | phi = 0.77351 | DV = m / phi * 2 ^ (sum( least_sig_bit( bitmap ) ) / m) # the DV estimate So, Error is bounded by 0.78/sqrt(m) §3.3.1. Obstacle This algorithms stated above is made for use on large databases. Infact, these were invented to save time and space while doing basic set operations on data with high cardinality. But the data we would provide as an input is not necessarily of high cardinality. Since we would be counting numbers for each country separately, so the expected value of the input cardinality would be : 0 <= C <= 2500 where C is the actual cardinality of the input data. §3.3.2. Workaround As a workaround, we could introduce a correction term for small values of cardinality. So our final formula could look something like: DV(S1,...,Sm) := m· (2^(Z/m) −2^(−κ·Z/m))/ ρ Where Κ is chosen to be around 1.75 §4. Implementation The data structure present in the geoip.c needs to be removed as it stores the IP address of the client. The data structure is shown below. struct clientmap_entry_t { HT_ENTRY(clientmap_entry_t) node; tor_addr_t addr; char *transport_name; unsigned int last_seen_in_minutes:30; unsigned int action:2; }; It then later needs to be replaced by a datastruture that contains the list of countries with the number of unique IP addrs seen for that country. The whole system can be represented by this diagram. ------------------ | Input IP Addr | ------------------ | | --------------------- | Determine Country | --------------------- | | ---------------------- | Determine Transport| ---------------------- | | ------------------------------ | Get salted hash of IP addr | ------------------------------ | | -------------------------- | Apply the formula | | on the hash obtained | -------------------------- | | --------------------------------------- | Increment that country's counter | | if the cardinality estimation | | is greater than the estimation | | done previously | --------------------------------------- §5. Security Considerations We might as well go ahead and implement this, but the thing to keep in mind is that implementing this would not protect a client's identity from a adversary completely. First thing to understand is that, an adversary that has gained access to a guard node or a bridge could still get the random value generated and deanonymize the client using brute force. Or even better, why would the adversary need that random value when she simply log all network connections coming into the compromised system? So, A thing to note is that this functionality would keep those clients anonymous who had connected to the compromised system in the past, but not those who will connect to it in the future. §6. References [1] https://en.wikipedia.org/wiki/Bloom_filter [2] https://www.chromium.org/developers/design-documents/rappor [3] https://research.neustar.biz/2013/04/02/sketch-of-the- day-probabilistic-counting-with-stochastic-averaging-pcsa/ ------------- Regards, Jaskaran Veer Singh

6 8

GSoC 17 | Name System API for Tor Onion Services
by Ivan Tham 02 Apr '17

02 Apr '17

I have created a proposal at http://dl.pickfire.tk/tor/proposal.md Feel free to review it and give comments, python script still WIP.

1 0

[GSoC] Proposal for Ahmia - Hidden Service Search
by Pushkar Pathak 01 Apr '17

01 Apr '17

Hello everyone I am a third year undergrad at International Institute of Information Technology, Hyderabad. I have been working on Ahmia for some time now. There are several fixes and upgrades required in the codebase. Below is the list of tasks I plan to complete under GSoC17: - Automate Blacklisting of child abuse websites - Add Hidden Services page - Data visualization under statistics page. Examples include i) Linking structure between sites and keyword based labeling for onions in the graph. ii) Popularity of domains according to backlinks and search clicks - Replace Polipo with TorSocks5 for ahmia-crawler - Upgrade support from Elastic 2.4.0 to 5.X.X - Add advanced search options like operators for multiple search terms in a single query - Complete Documentation on ahmia.fi and Github page Details of the above tasks along with timeline and other relevant details are included in the proposal attached. You are welcome to comment on it and give your suggestions. Cheers, Pushkar Pathak Proposal for Tor Project: Ahmia - Hidden Servic... <https://docs.google.com/document/d/1h6ZbUMzKCkvyXQ9UTOy8nKVjV4fgps9UxTkBQCU…>

1 0

[GSoC] Intro & Questions
by Mark Cohen 30 Mar '17

30 Mar '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello everyone! My name is Mark, and I'm a 2nd year undergraduate at UChicago, majoring in CS and math. I greatly admire the Tor community, and as a longtime user I've always wanted to give back. As far as relevant experience goes, I've taken courses in systems, networks, and languages, and I'm currently in a wonderful usable security course taught by Blase Ur. Last summer I worked for Keybase, which was both a lot of fun and highly educational. For GSoC, I'm most interested in helping improve the state of IPv6. I would love to pick someone's brain before creating an application to get a conceptual feel for the project and to learn about the kinds of things I'd be implementing. If you're that person, I'd really appreciate it if you could reach out either on here or via any other contact method (check my website linked below). Thanks for reading, and I'm looking forward to talking to you! ~Mark (https://mpcsh.xyz) -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEmyuHiWNRDa+IFK5Pss2qrTdc5gQFAljdV10ACgkQss2qrTdc 5gTWrw/+NpcZ/LahaxKXc3rdejLqblg8iiQVBxO8I7FkJkST5kz8gOFoheImrmSF gh2Jz/gY3TK/U8OXd8yDBPVd8KwWadCF161BURQtN8U35Rxao+Xmrrwhp5P2lj2L DfGkBwDzkIAOeCKOITh64guuzpPrhCWJOean7gJs6zHBIB+cIRZF1/3LhbtqRLJI nKcBy1mWjwHJ2CKkIhIFFHkY2WfqQ3JvlngjwDFUuYvBTrHKAKK1tl7Wnuo7npFs OZSaSxuXK4bQPGRINpQoPNyYI4sjKYQChco1ZLZ3v7Kc1Uyy0xlR5ittEl5GnaKl 4tXVRJpjDkkrWwHYxpVl5YrzUAC0OlJ9yh7qDZK2OQ5V6UEv+cpZJU5fGNrRKYxG JLMvs3Jf42xHIyMI0H7ya0Fh12PrOAD7en0mqM4Ie55/uvCb9FSbDhGOXvjuIIvp 2E6pJYsEXXvCZMyO8C36zEWn4JsEvAAAUeig9vyqL7kEDIL0vql5CwXO27MI3nqz IIk+ogVpITIooHB+owR01QENZ7DIoj1uRvX4skF+hXtA2W66J10Uw1b2gy2qPPbG HoAZW+nXRpKUYmWsvy8wwqZNtxdhZ8DgY78hXqrFOr65v9Odi6aNnAVSB9m9Dg4b Iu6LW7jbOOYbT6ZUWB7XwG7qi+jtHAzZZ7ZOAVzU37cyzGf2tnY= =eUZ0 -----END PGP SIGNATURE-----

2 2

GSoC 2017 - Questions
by Krishna Shukla 30 Mar '17

30 Mar '17

Hey, I'm Krishna Shukla, I'm studying a bachelors of computer science at the University of Queensland. I guess the relevant subjects I've studied so far covers C and Unix programming, Computer Networks, Algorithms and Data Structures, and Programming in the large. (got a high distinction in all the above) My most important question is if I could work on a project but not actually be apart of GSoC? - I am unfortunately ineligible as my brother works as a Security Engineer at Google Sydney. And if the above is okay would it also be okay to not have to strictly abide by their timeline as I don't actually have holidays during this time in Australia but I'd like to contribute in my free time nonetheless! As for projects themselves I'm really interested in the relay crypto parallelism and the hidden service crypto parallelism. And I have a couple of questions regarding them. For the relay crypto parallelism I wanted to know what is there left to be done? When I looked at the tickey #1749 someone called towelenee made a few patches that already made it multi threaded, were these changes just not accepted? Also wanted to know if specific knowledge about circuit cryptography was required? As I know of it, but I certainly cannot make my own fully homomorphic cryptosystem, is it more in the steps of the system has already been made, it just needs to be parallelised correctly? It also states the code is written to expect immediate responses, I'm not sure what you mean by that, after all there is always a slight delay, and if it becomes multi threaded we can never know what is running what when, so is it more someone is waiting at the other end of a socket and needs it ASAP, or is it internally things want the answer quickly (in which case I don't know how to solve it other than uses mutexes which is probably not so okay)? I am interested in the hidden service crypto parallelism in its own right, but I was also thinking weather it would be a feasible idea to combine the two projects and create a multi-threaded decryption library that could be linked to both the tor relay and the hidden services (could release it as a cryptosystem library, all the fully homorphic cryptosystem libraries I found used GPL licenses and thus not compatible with tors), or are their requirements too far apart? Also I was wondering how the Ahmia automated blacklisting was planned to work? As in how would a list of child abuse sites be fetched? Honestly I don't actually know python, I've worked with it and Django before in a hackathon once, but I cannot claim any real knowledge in it, but at the same time I am passionate about the topic of child abuse, and I think if I can help reduce its demand in anyway by making it harder to find, I'd say it's some good added to the world. Apologies about the long mail guys, Krishna Shukla

3 3

GSOC 2017: Proposal for anon-connection-wizard
by irykoon 29 Mar '17

29 Mar '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello everyone! The following is my first draft of the proposal for the anon-connection-wizard. Could anyone offer me some feedback about it please? Any recommendation, suggestion and criticism are very welcome and appreciated! > # Introduction > > Every software project should solve a problem. Before offering the > solution (your Google Summer of Code project), you should first > define the problem. What’s the current state of things? What’s the > issue you wish to solve and why? Then you should conclude with a > sentence or two about your solution. Include links to discussions, > features, or bugs that describe the problem further if necessary. The anon-connection-wizard is a Python-clone of the Tor Launcher which aims at providing Tor users with a graphical instruction on configuring the Tor. This applicatipn has been developed as a part of the Whonix Project: https://github.com/Whonix/anon-connection-wizard Some of the screenshots of the old version anon-connection-wizard can be found here: https://www.whonix.org/blog/connection-bridge-wizard This application is especially helpful for users who live in Tor-censored area. This is because those users can only connect to the Tor network with the help of other censorship circumvention tools which include but are not limited to Tor bridges, pluggable transports and other third party Internet censorship circumvention tools like Lantern and VPN. Currently, the Tor Launcher is shipped with the Tor Browser Bundle and heavily relies on the Tor Browser for its implementation. These facts cause using Tor Launcher without having the Tor Browser impossible. I agree with the whonix core developer Patrick Schleizer that "the Tor Browser Bundle has its kind of users. system Tor (refers to Tor from packages.debian.org or deb.torproject.org) users, where Tor runs as daemon, is used in different ways for different purposes. These users cannot use Tor Launcher, because it only works with Tor Browser". Therefore, although anon-connection-wizard is a Python-clone of the Tor luancher, since all its dependencies are already in Debian and alrea dy packaged, it can still be really useful for the system Tor users. In addition, the current instructions provided by the anon-connection-wizard and Tor launcher is not be clear enough for user to configure Tor correctly. Therefore I would like to implement and redesign the anon-connection-wizard. I hope that my work will help more people to connect to the Tor network efficiently and successfully. > # Project goals > > Be short and to the point, and perhaps format it as a list. > Propose a clear list of deliverables, explaining exactly what you > promise to do and what you do not plan to do. “Future developments” > can be mentioned, but your promise for the Google Summer of Code > term is what counts. As mentioned above, the projects goals include two main parts: 1. The clone implementation of Tor Launcher; 2. The redesign of the anon-connection-wizard. > # Implementation > > Be detailed. Describe what you plan to do as a solution for the > problem you defined above. Include technical details, showing that > you understand the technology. Illustrate key technical elements > of your proposed solution in reasonable detail. > The clone implementation of Tor Launcher: Currently, I have helped to implement the basic functions of anon-connection-wizard. However, there are still several bugs need fixing and a large number of exciting features need implementing, which include: 1. The current implementation of configuring torrc file is very rudimentary. The anon-connection-wizard should read the previous bridge/proxy configuration from the file and adjust the default UI accordingly. Just like what Tor Launcher has been doing. The "edit marker approach" is preferred way to implement this: https://forums.whonix.org/t/graphical-gui-whonix-setup-wizard-anon-conne ction-wizard-technical-discussion/650/226 2. The password for proxy setting should be covered by character * The redesign of the anon-connection-wizard: I have made a specific proposal for this topic, which can be found here: https://forums.whonix.org/t/a-proposal-for-redesigning-anon-connection-w izard-for-better-usability/3681 The redesign should at least includes: 1. Rearranging the instruction page orders for better usability; 2. Rewriting the literal instruction so that it fits the actual situation of people in censored areas; 3. Adding more features to the custom Tor bridges configuration input box for more clear instruction. For example, syntax highlight, tool-tips, etc; 4. Doing user behavior experiment to find out what can be helpful for better usability; 5. Modifying the anon-connection-wizard based on the result of the experiment. > # Timeline > > Show that you understand the problem, have a solution, have also > broken it down into manageable parts, and that you have a > realistic plan on how to accomplish your goal. Here you set expectations, so don’t make promises you can’t keep. A modest, realistic and detailed timeline is better than promising the impossible. Since the specific dates may be changed with the undecided working schedule. I arrange my timeline in a week unit. Week 1: The password for proxy setting should be covered by character *. Week 2: Implement the "edit marker approach". Week 3: Rewriting the literal instruction so that it fits the actual situation of people in censored areas. Week 4: Generate ideas on redesigning the anon-continence-wizard users interface, basing on the recommendations from outside sources, problems discussed above and suggestions from other people. Present the planning redesign to public to receive feedback. Week 5: Rearranging the instruction page orders for better usability; Rewriting the literal instruction so that it fits the actual situation of people in censored areas. Week 6: Adding more features to the custom Tor bridges configuration input box for more clear instruction. For example, syntax highlight, tool-tips, et c; Week 7: Prepare for the user behavior experiment, including recruitment and setting up environment. Week 8: Conduct the experiment. Week 9: Process and analysis the experiment data. Week 10: Write the research report. Week 11: Modifying the anon-connection-wizard based on the result of the experiment. Week 12: Modifying the anon-connection-wizard based on the result of the experiment. > > If you have other commitments during GSoC, such as a job, > vacation, exams, internship, seminars, or papers to write, disclose > them here. I am going to be enrolled for the Summer 2017 semester that begins May 22nd and ends June 23th at XXX University. I am going to take two classes from Monday to Friday for each week during the Summer semester. One will be from 3:20PM to 5:00PM (UTC) and another one will be from 7:00PM to 8:40PM (UTC). > GSoC should be treated like a full-time job, and we will expect > approximately 40 hours of work per week. If you have conflicts, > explain how you will work around them. If you are found to have > conflicts which you did not disclose, you may be failed. The sum of the time I will be in class for each weekday will be 3 hours and 20 minute which is totally fine to me. My current overall GPA is 4.0/4.0 which may help to prove I can handle my school study well. According to Google Summer of Code timeline, the “[c]oding officially begins” at May 30th which means there will be approximate three weeks that I have both school study and Google Summer of Code. To work around it, I have came up with three plans which either of them is fine to my potential mentor: 1. Since I have been familiar with the contributing workflow for Whonix, I do not have to spend a lot of time to get used to it. Therefore I can use the “Community Bonding Period” which is from May 4th to May 30th to do the real coding for the project; 2. I can also keep committing to the project during each weekend from now on before May 4th . This is also a way to work around the time conflicts. 3. If I am expected to code only during the official timeline, I can spend 5 hours each day during the weekdays and spend 8 hours each day during the weekends. > Open and clear communication is of utmost importance. Include your > plans for communication in your proposal; daily if possible. I agree that “[o]pen and clear communication is of utmost importance”. This is because of two main reasons from my point of view. First, a successful free and open source software development heavily relies on the collaboration between different people. A good communication skill will create a positive and supportive atmosphere which not only make everyone works for it more efficient but also attracts more people to join the development. Second, feedback from others, especially mentor, can be extremely beneficial to a student’s progress. Without the feedback, it may take a student years until one day after a frustrating debugging process to realize a mistake he/she made; while he/she may realize several mistakes he/she made almost immediately from his/her mentor’s feedback. I have already been working on the project with my potential mentor Patrick Schleizer. A small part of our open communication can be found [here](https://forums.whonix.org/t/graphical-gui-whonix-setup-wizard-ano n-connection-wizard-technical-discussion/650/222), which may be helpful to prove we have been having an open and clear communication. My plan is to take the [Whonix Forum](https://forums.whonix.org/) as the daily communication platform with my potential mentor Patrick. And just like what I have been doing, I will also post a detailed progress report for each working period which is no more than a week. I can definitely send the posts to the tor-dev mailing list if it is considered as a good idea. > # About me > > Provide your contact information Currently, people can contact me through the following ways: 1. Email: irykoon at gmail dot com GPG: https://pgp.mit.edu/pks/lookup?op=vindex&search=0xA14B4DBC6DCDD53C 2. Github: @irykoon 3. Whonix Forum: @iry I will inform the public if there is any change to my contact informatio n. > and write a few sentences about you and why you think you are the > best for this job. As one who was living in oppressive area, I deeply understand the importance of Internet freedom to a society. At first, I merely considered Internet freedom as fighting against Internet censorship. However, after a large amount of observation, reading and reflection, I realized that the self-censorship conducted by every scared citizens was much more powerful and terrible than the censorship conducted by the outside world. It was at that moment I realized the online anonymity was a vital component to Internet freedom because it frees people from fear. I value Tor/Whonix. Without it, I couldn't have been freed from the fear and explored the world freely and finally became who I am today. Therefore, contributing to Tor/Whonix as a career is not only a dream that I have been fighting for, but also an essential approach to my self-actualization. > Prior contributions are helpful; list your commits. The followings are my pull requests on GitHub to the Whonix: 1. [Basic features implementation](https://github.com/Whonix/anon-connection-wizard/pull/1) 2. [Pluggable transport renew](https://github.com/Whonix/anon-connection-wizard/pull/2) 3. [A proposal for redesigning anon-connection-wizard for better usability](https://github.com/Whonix/anon-connection-wizard/pull/3) 4. [Port from Python2 to Python3.4 & from PyQt4 to PyQt5](https://github.com/Whonix/anon-connection-wizard/pull/4) The following is my proposal for the redesign of anon-connection-wizard: 1. https://forums.whonix.org/t/a-proposal-for-redesigning-anon-connection-w izard-for-better-usability/3681 > Name people (other developers, students, professors) who can act > as a reference for you. Mention your field of study if necessary. My potential mentor, Patrick Schleizer, can be a reference for me. He is a core developer of the Whonix Project, > Other things to think about: * Are you comfortable working > independently under a supervisor or mentor who is several thousand > miles away, and perhaps 12 time zones away? How will you work with > your mentor to track your work? Have you worked in this style > before? Yes! I have been interacting, working and learning in this style with my potential mentor and I am really comfortable with that. > * If your native language is not English, are you comfortable > working closely with a supervisor whose native language is > English? What is your native language, as that may help us find a > mentor who has the same native language? Both my potential mentor Patrick and I can communicate in English. So there is no problem with that. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY1r/pAAoJEKFLTbxtzdU8wFsP/A2FwFd5Yg+9m6nKlgcywA9x HNGuAc9RRyRg6MiOqg25NJdcDpa6d7y6wy5dBqXKjn5yWvcogQrFrONWXl9/U3D2 DwTCITF2EyDrLH/t9oUCFsE169oZSZ02WdqgCdl4yVF1Bdxk8lMW0/raZ325rTxH QMv4ueG2YacVQ88vDxaY9wY9CAoghAvR+zjp9M3Lu0iebH4ZDfBaH19RZjWUa/+Y eyvjY5DyFp74rct4UYX+Rqnqlgf8meTSoKAAJ4cbWPncQyIvWjVrzY3RTmznSg95 Dh97RJ3Ufso2h73dlUnojuLADOFEyyrL1hgNpqf7RAUhR5Dc+xTvwSmuqss9D8dQ hjANF9ZpADcdDAQGSbcxlUcdd7u1twvVPnstlTLHsdLxbMS8F16SZhUAjJMlwOua bdxssBGsdoht0fJmSB4LHz4G6r6cOlo2nRFD5Noo3rk63buS/+h8/zPBlOXsS8Ox PNAKnUHkTQYucjmERlz7XwKFccoJNhO2Iha8hA3WkMwsTKzkbkJtRUX+NjE1XLrA 3ITVrzT08Bd5IpLrIKa352sknoqzv+/L0tVxdHc1xkjx0XgacHXLD3UcX1Zff/0p QVKuE/PmavJinRbYh/g1mMZoZVryLRTsn/wOMKRoCmL+/xbIJIyM/IBEqxMyBFuU SHq1QajHPvncx/dttM3W =FRpt -----END PGP SIGNATURE-----

5 5

GSoC 17 | Name System API for Tor Onion Services
by Pickfire 29 Mar '17

29 Mar '17

Hi, I am Ivan Tham. Currently studying in Computer Science in APIIT Malaysia. I am interested particapate in Google Summer of Code 2017 under tor organization. I am interested to see Proposal 224 coming along but I would really like to see [Proposal 272][0] and hope that tor hidden services can be more user-friendly. What do you think of the projects? Is the proposal too immature? I had looked into [OnioNS][1] as well and like the idea of having different types of DNS records for tor hidden services, how does it integrate with [Proposal 272][0]? [0]: https://lists.torproject.org/pipermail/tor-dev/2016-October/011524.html [1]: https://lists.torproject.org/pipermail/tor-dev/2015-May/008826.html

4 5

Issues With Ticket #7532 - "Count unique IPs in an anonymous way"
by samir menon 28 Mar '17

28 Mar '17

This ticket [1] was suggested as a GSoC project, but I think there might be an issue with the security model/perceived threat. To summarize the ticket and its child [1], basically, we currently store all the IP's seen by a node so that we can count unique IP's. The idea is that this is dangerous; if a node is compromised, then all of those IP addresses can be retrieved from memory. Therefore, a variety of mitigation methods have been proposed (most prominently, the 'Probabilistic Counting Algorithm' from [2]) Here's my issue: what about brute force? No matter what method we use, we will arrive at a data structure that should be able to, given an IP address, tell us whether it is new (and we should increment the unique counter) or old (and we should leave the unique counter the same), with some reasonably small false positive rate. Basically, we're supposed to use some kind of Bloom filter like structure. Then can't that structure then be brute-forced, offline, by an attacker? IPv4 addresses are 32-bits (~4.3 billion of them), so an attacker could just run whatever method we use to check membership over and over, and then recover the set of IP's. The same happens if we hash the IP's beforehand. So, is this attack acceptable? The only mitigation I've seen is the one referenced by 'Aaron' in the ticket, which is the system that git uses, cryptolog; there, they have a random salt that changes daily. Then, an attacker can only learn the IP's for one day. This sounds like a reasonable compromise to me, but then the implementation becomes rather simple; just hash the IP's with a random salt that changes daily before putting them in the set. IPv6 also solves this (128 bits), but there again, the solution is just to hash the IP's before storing them - the Bloom filter/'Probabilistic Counting Algorithm' is unnecessary. I think I must be missing something about how the 'Probabilistic Counting Algorithm' works - somehow, it needs to keep track of the # of unique IP's without knowing (with a high probability) whether any 1 individual IP has been seen. Any help/pointing out of errors in my reasoning would be useful. Thanks, Samir Menon menon.samir(a)gmail.com samir2(a)stanford.edu [1] https://trac.torproject.org/projects/tor/ticket/7532 [2] http://www.mathcs.emory.edu/~cheung/papers/StreamDB/Probab/1985-Flajolet-Pr…

3 3

[RFC] Proposal for the encoding of prop224 onion addresses
by George Kadianakis 28 Mar '17

28 Mar '17

Hello list, we've had discussions over the past years about how to encode prop224 onion addresses. Here is the latest thread: https://lists.torproject.org/pipermail/tor-dev/2016-December/011734.html Bikeshedding is over; it's time to finally pick a scheme! My suggested scheme basically follows from the discussion on that thread, and is heavily based on the Bitcoin address format: https://en.bitcoin.it/wiki/Base58Check_encoding https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addres… Here is the suggested scheme: onion_address = base32(version + pubkey + checksum) checksum = SHA3(".onion checksum" + version + pubkey) where: pubkey is 32 bytes (ed25519) version is one byte checksum is _truncated_ to two bytes With the above construction onion_address ends up being 56 bytes long (excluding the ".onion"): tbi5tdxbosiotphawjyu7f5pw5tlnvbvfjrj7meskbsnwr2bqbu2t4gg.onion tcrdnadkefvbdm3u56kz6lfh6v5lr24fpog5vzsy4n3djr2ymueu34ws.onion tcdw7lwmtp5pbwj2w7wf6amxdhmc62qitj2teu376r5s2fqke4r3uiq6.onion If people like the above suggestion, I will take the effort to engrave it in prop224. Here is the discussion section. Please provide feedback! [D1] How to use version field: The version field is one byte long. If we use it as an integer we can encode 256 values in it; if we use it as a bitmap we could encode properties and such. My suggestion is to simply use it as an integer like Bitcoin does. So we can assign value \x01 to normal onion services, and in the future we can assign more version tags if we need to. For example, we can give a different version field to onion services in the testnet. We can also reserve a range of values for application-specific purposes. [D1.1] Default version value: The next question is what version value to assign to normal onion services. In the above scheme where: onion_address = base32(version + pubkey + checksum) the value of 'version' basically determines the first two characters of the onion address. In Bitcoin, they've made it such that the default version value basically prefixes addresses with "1"; so all normal Bitcoin addresses start with 1 as in 14tDWDT9zqDufWZmiLqoaT9qJyHi7RRZPE What should we do in Tor? My suggestion is to use '\x98' as the default version value which prefixes all addresses with 't' (as in Tor). Check the examples I cited above. An alternative is to turn the scheme to: onion_address = base32(pubkey + checksum + version) where the version byte is at the end with no effect at usability. A heavier alternative would be to have two bytes of version so that we can just prefix them all with 'tor'... [D2] Checksum strength: In the suggested scheme we use a hash-based checksum of two bytes (16 bits). This means that in case of an address typo, we have 1/65536 probability to not detect the error (false negative). It also means that after 256 typos we will have 50% probability to miss an error (happy birthday!). I feel like the above numbers are pretty good given the small checksum size. The alternative would be to make the checksum four bytes (like in Bitcoin). This would _greatly_ increase the strength of our checksum but it would also increase our address length by 4 base32 characters (and also force us to remove leading padding from base32 output). This is how these 60-character addresses look like: tc2dty3zowj6oyhbyb5n3a2h3luztlx22hy2cwdvn37omsv7quy7rxiysn3a.onion tbdczrndtadzdhb6iyemnxf7f4i6x7yojnunarlrvt2virtmrecmwgx5golq.onion tc6pcgyorusw3jj5tosxakmcwfmcend2q4g2qnbjtkhuuh4dcgvs4rl4rdaa.onion You probably don't notice the size difference compared to the 56-character addresses, which perhaps is an argument for adopting a four byte checksum. Let me know what you think about this. [D3] Do we like base32??? In this proposal I suggest we keep the base32 encoding since we've been using it for a while; but this is the perfect time to switch if we feel the need to. For example, Bitcoin is using base58 which is much more compact than base32, and also has much better UX properties than base64: https://en.bitcoin.it/wiki/Base58Check_encoding#Background If we wanted to get a more compact encoding, we could adopt base58 or make our own adaptation of it. In this proposal I'm using base32 for everything, but I could be persuaded that now is the time to use a better encoding. Let me know what you think! Thanks :)

16 40

Pluggable Transports 2.0, draft 1 Specification
by Brandon Wiley 28 Mar '17

28 Mar '17

As was discussed in the Pluggable Transports session at TorDev Amsterdam, the Pluggable Transports 2.0, draft 1 specification [https://www. pluggabletransports.info/spec/pt2draft1] was created by a committee of censorship circumvention tool developers: Tor, Lantern, Psiphon, and uProxy. It specifies a version of Pluggable Transports that meets the needs of multiple circumvention tools. There is one major change that has implications for tor, which is that the Pluggable Transports 2.0, draft 1 IPC protocol uses a different type of SOCKS authentication mechanism, which allows for larger parameters to be send to transports. We are currently working on a 2nd draft of this specification, which will incorporate changes and errata from the community censorship circumvention tool community. For instance, syntactic errors in the documentation of the Go interface will be fixed in draft 2. Tor developers participated in the specification meetings, and now feedback from the overall Tor community is requested for incorporation in the next draft. There will also likely be a 2.1 specification process, possibility starting August, where we will consider larger changes.

2 4

GSOC 2017: Revised Proposal for anon-connection-wizard
by irykoon 27 Mar '17

27 Mar '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello everyone! I have revised my previous proposal with the help of anonym's feedback. Could anyone offer me some feedback about it please? Any recommendation, suggestion and criticism are very welcome and appreciate d! #####What project would you like to work on? I would like to work on the anon-connection-wizard. It is a Python-clone of the Tor Launcher which aims at providing Tor users with a graphical instruction on configuring the Tor. This [application](https://github.com/Whonix/anon-connection-wizard) has been developed as a part of the Whonix Project. Some of the screenshots of its old version can be found [here](https://www.whonix.org/blog/connection-bridge-wizard). This application is especially helpful for users who live in Tor-censored area. This is because those users can only connect to the Tor network with the help of other censorship circumvention tools which include but are not limited to Tor bridges, pluggable transports and other third party Internet censorship circumvention tools like Lantern and VPN. Currently, the Tor Launcher is shipped with the Tor Browser Bundle and heavily relies on the Tor Browser for its implementation. Although thanks to the great efforts([[1]](https://git-tails.immerda.ch/tails/tree/config/chroot_loca l-hooks/06-adduser_tor-launcher?h=devel), [[2]](https://git-tails.immerda.ch/tails/tree/config/chroot_local-hooks/ 10-tbb?h=devel), [[3]](https://git-tails.immerda.ch/tails/tree/config/chroot_local-includ es/usr/local/sbin/tails-tor-launcher?h=devel), [[4]](https://git-tails.immerda.ch/tails/tree/config/chroot_local-includ es/usr/local/bin/tor-launcher?h=devel)) of Tails, the Tor Launcher can be run as a stand-alone XUL application currently, since the XUL will not be supported by mozilla in Firefox ESR branch [some time next year](https://blog.mozilla.org/addons/2016/11/23/add-ons-in-2017/), that implementation may not work for a long time. Beiseds, I agree with the Whonix core developer Patrick Schleizer that "the Tor Browser Bundle has its kind of users. system Tor (refers to Tor from packages.debian.org or deb.torproject.org) users, where Tor runs as daemon, is used in different ways for different purposes". Therefore, although anon-connection-wizard is a Python-clone of the Tor luancher, since all its dependencies are already in Debian and already packaged, it can still serve as a really useful tool for the system Tor users or a loose coupling substituition to the Tor Launcher. In addition, the current instructions provided by the anon-connection-wizard and Tor launcher is not clear enough for users to configure Tor correctly. Therefore I would like to implement and redesign the anon-connection-wizard. I hope that my work will help more people to connect to the Tor network efficiently and successfully. #####Your proposal should also try to break down the project into tasks of a fairly fine granularity, and convince us you have a plan for finishing it. As mentioned above, my project goals include two main parts: ######The clone implementation of Tor Launcher: Currently, I have helped to implement the basic functions of anon-connection-wizard. However, there are still several bugs need fixing and a large number of exciting features need implementing, which include: 1. The current implementation of configuring torrc file is very rudimentary. The anon-connection-wizard should read the previous bridge/proxy configuration from the file and adjust the default UI accordingly. Just like what Tor Launcher has been doing. The ["edit marker approach"](https://forums.whonix.org/t/graphical-gui-whonix-setup-wizard - -anon-connection-wizard-technical-discussion/650/226) is preferred way to implement this; 2. The password for proxy setting should be covered by character *. ######The redesign of the anon-connection-wizard: I have made a specific [proposal](https://forums.whonix.org/t/a-proposal-for-redesigning-anon-c onnection-wizard-for-better-usability/3681) for this topic. And the redesign should at least includes: 1. Rearranging the instruction page orders for better usability; 2. Rewriting the literal instruction so that it fits the actual situation of people in censored areas; 3. Adding more features to the custom Tor bridges configuration input box for more clear instruction. For example, syntax highlight, tool-tips, etc; 4. Doing user behavior experiment to find out what can be helpful for better usability; 5. Modifying the anon-connection-wizard based on the result of the experiment. #####A timeline for what you will be doing throughout the summer is highly recommended. Since the specific dates may be changed with the undecided working schedule. I arrange my timeline in a week unit. Please notice that I have communicated with my potential mentor that we can work on some tasks in advanve if the project plan for a specific week is finished earlier than expected. | TIME | TODO | |------|------| |Week 1 | The password for proxy setting should be covered by character *.| |Week 3 | Rewrite the literal instruction so that it fits the actual situationy of people in censored areas.| |Week 4 | Generate ideas on redesigning the anon-continence-wizard users interface, basing on the recommendations from outside sources,problems discussed above and suggestions from other people. Present the planning redesign to public to receive feedback.| |Week 5 | Rearrange the instruction page orders for better usability; Rewriting the literal instruction so that it fits the actual situation of people in censored areas.| |Week 6 | Add more features to the custom Tor bridges configuration input box for more clear instruction. For example, syntax highlight, tool-tips, etc.| |Week 7 | Prepare for the user behavior experiment, including recruitment and setting up environment.| |Week 8 | Conduct the experiment.| |Week 9 | Process and analysis the experiment data.| |Week 10| Write the research report.| |Week 11| Modify the anon-connection-wizard based on the result of the experiment.| |Week 12| Modify the anon-connection-wizard based on the result of the experiment.| #####Point us to a code sample: something good and clean to demonstrate that you know what you're doing, ideally from an existing project. The followings are a part of my pull requests to the anon-connection-wizard project on GitHub: 1. [Basic features implementation](https://github.com/Whonix/anon-connection-wizard/pull/1) ; 2. [Pluggable transport renew](https://github.com/Whonix/anon-connection-wizard/pull/2); 3. [Port from Python2 to Python3.4 & from PyQt4 to PyQt5](https://github.com/Whonix/anon-connection-wizard/pull/4). The following is my proposal for the redesign of anon-connection-wizard in Whonix Forum: 1. [A proposal for redesigning anon-connection-wizard for better usability](https://forums.whonix.org/t/a-proposal-for-redesigning-anon-c onnection-wizard-for-better-usability/3681) #####Why do you want to work with The Tor Project in particular? As one who was living in oppressive area, I deeply understand the importance of Internet freedom to a society. At first, I merely considered Internet freedom as fighting against Internet censorship. However, after a large amount of observation, reading and reflection, I realized that the self-censorship conducted by every scared citizens was much more powerful and terrible than the censorship conducted by the outside world. It was at that moment I realized the online anonymity was a vital component to Internet freedom because it frees people from fear. I value Tor/Whonix. Without it, I couldn't have been freed from the fear and explored the world freely and finally became who I am today. Therefore, contributing to Tor/Whonix as a career is not only a dream that I have been fighting for, but also an essential approach to my self-actualization. #####Tell us about your experiences in free software development environments. We especially want to hear examples of how you have collaborated with others rather than just working on a project by yourself. I agree that “[o]pen and clear communication is of utmost importance”. This is because of two main reasons from my point of view. First, a successful free and open source software development heavily relies on the collaboration between different people. A good communication skill will create a positive and supportive atmosphere which not only make everyone works for it more efficient but also attracts more people to join the development. Second, feedback from others, especially mentor, can be extremely beneficial to a student’s progress. Without the feedback, it may take a student years until one day after a frustrating debugging process to realize a mistake he/she made; while he/she may realize several mistakes he/she made almost immediately from his/her mentor’s feedback. I have already been working on the project with my potential mentor Patrick Schleizer. A small part of our open communication can be found [here](https://forums.whonix.org/t/graphical-gui-whonix-setup-wizard-ano n-connection-wizard-technical-discussion/650/222), which may be helpful to prove we have been having an open and clear communication. I also take Jean-Philippe Ouellet's words said on the Qubes-devel mailing list as an encouragement to me: > This kind of detailed and engaged communication is a model to all GSoC applicants #####Will you be working full-time on the project for the summer, or will you have other commitments too (a second job, classes, etc)? If you won't be available full-time, please explain, and list timing if you know them for other major deadlines (e.g. exams). Having other activities isn't a deal-breaker, but we don't want to be surprised. I am going to be enrolled for the Summer 2017 semester that begins May 22nd and ends June 23th at XXX University. I am going to take two classes from Monday to Friday for each week during the Summer semester. One will be from 3:20PM to 5:00PM (UTC) and another one will be from 7:00PM to 8:40PM (UTC). The sum of the time I will be in class for each weekday will be 3 hours and 20 minute which is totally fine to me. My current overall GPA is 4.0/4.0 which may help to prove I can handle my school study well. According to Google Summer of Code timeline, the “[c]oding officially begins” at May 30th which means there will be approximate three weeks that I have both school study and Google Summer of Code. To work around it, I have came up with three plans which either of them is fine to my potential mentor: 1. Since I have been familiar with the contributing workflow for Whonix, I do not have to spend a lot of time to get used to it. Therefore I can use the “Community Bonding Period” which is from May 4th to May 30th to do the real coding for the project; 2. I can also keep committing to the project during each weekend from now on before May 4th . This is also a way to work around the time conflicts. 3. If I am expected to code only during the official timeline, I can spend 5 hours each day during the weekdays and spend 8 hours each day during the weekends. #####Will your project need more work and/or maintenance after the summer ends? Yes! Tails developer anonym pointed out a promising future for the anon-connection-wizard on the tor-dev mailing list: > "I also see potential for future collaboration between Whonix and Tails for extending the usefulness of anon-connection-wizard beyond what Tor Launcher (and its replacement) offers [2]; anon-connection-wizard targets the OS, not just a single application, so it could integrate the choices of network configuration (wired? which wireless network? MAC spoofing?) and Tor configuration (proxy? pluggable transport?) in a single place which probably makes more sense for users and also allows us to more easily (optionally) save these settings so they are restored the next time you visit the same network. This could potentially even be used to help giving users control over entry node selection to avoid persistent Entry Guards from leaking information about you geographical movement. [3]" #####What are the chances you will stick around and help out with that and other related projects? Since I would like to take contributing to Tor/Whonix as a career, I will definitely stick around the Tor/Whonix community and help out with the future development of my project and other related ones. I never consider my project as a one-time project. Instead, I consider it as an important step to help myself get more invovled in the Tor/Whonix community. #####What is your ideal approach to keeping everybody informed of your progress, problems, and questions over the course of the project? Said another way, how much of a "manager" will you need your mentor to be? My plan is to take the [Whonix Forum](https://forums.whonix.org/) as the daily communication platform with my potential mentor Patrick. And just like what I have been doing, I will also post a detailed progress report for each working period which is no more than a week. Since the anon-connection-wizard is hosted on Github right now, people can also take it as a way to see my commits and progress. I can also send the posts to the tor-dev mailing list if it is considered as a good idea. #####What school are you attending? What year are you, and what's your major/degree/focus? If you're part of a research group, which one? If these information is necessary, please do not hesitate to contact me. My contact information is listed in the next section. #####How can we contact you to ask you further questions? Currently, people can contact me through the following ways: 1. Email: irykoon at gmail dot com [GPG](https://pgp.mit.edu/pks/lookup?op=vindex&search=0xA14B4DBC6DCDD53C ) 2. Github: @irykoon 3. Whonix Forum: @iry I will inform the public if there is any change to my contact informatio n. #####Are you applying to other projects for GSoC and, if so, what would be your preference if you're accepted to both? Having a stated preference helps with the deduplication process and will not impact if we accept your application or not. I am going to submit the same proposal to both the Tor Project and the Qubes Project. This is because I would like to avoid the situiation where one of the projects does not get as many slots as it wants from google. I will be extremly happy to be accepted by either of the projects. Since my project may benifit the Tor Project more, I would prefer it when I am accepted by both of the projects. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY2UGjAAoJEKFLTbxtzdU8coMQAIsfxRw5Fdyrnwp6Rb13zpEh ugDr9FdDOuIMmIQbEKn+kXoYUoECuuDXa0r+DLOS9HodPJ6MrksDr8956HsusEnw 7XyJLlfL+pccNPzsyXe+O5UgiMYlmIJpH4+7tHyZ0bYkjzrxsa6TPaP/iODoby3d B2f5GUXgt5X1vpGBmGGVpOzTYTSJwnNaFfpE4O6dCm41aMsuMsIGj1vRH80SqrsT XJKBdgEKbwewGEwLNgdMx5XlH+9rARv0Ytx83GI8894sx80Rl2S9wL9D5km7IoWW n3+8HS0wzFOkCIFPumfAtwAHtJRTyWVEc4jr/waObPwJtK/cnoOwkVHXbimvnWoc dr7qjNBDDms98rXDD6gxgKToIKgdgDJetMW9QWhDBTXuZcbq6bwmONoTZ94/4mR6 V0E2HhGkjF/RLCu8dP+oHVPdEsFN1er/l9SEUreqF78+VRFwspAc7y5nIo/0WXDV t/zKeiqYjsw+bHC7Dbaxax67QXNuWe3viToCYtPOKGMat7ORlTj+eqNaE6iRt+q/ N91Wd/B86v5ibWy9UEN4Uo/FqwT+YOjOYJ1yoXZRmnrdwhYalAt3ESCqCi3cMDc8 eRQGbtCwGeaGd5g03OfBe8zQwswj11yTwi1xsIOL/RdVXt7Af6Q1MMd6a0g0Rub0 6WV1NX+Knl88tbzyRpQ5 =ioNx -----END PGP SIGNATURE-----

1 0

Re: [tor-dev] GSOC 2017: Proposal for anon-connection-wizard (anonym)
by irykoon 27 Mar '17

27 Mar '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 anonym: > I might be misunderstanding what you and Patrick mean with > "impossible" (or rather, which use cases are impossible) w.r.t. > using Tor Launcher outside of the Tor Browser; Tails uses the Tor > Launcher shipped in Tor Browser, but it's run as a stand-alone XUL > application (`firefox --app ...`), so the *web* browser isn't > started as part of it. [1] One could even run it using > Iceweasel/Firefox, i.e. completely without Tor Browser. > Thank you very much for your explaination, anonym! I did find my words misleading here. I have corrected my mistakes. How do you like this one: " Currently, the Tor Launcher is shipped with the Tor Browser Bundle and heavily relies on the Tor Browser for its implementation. Although thanks to the great efforts([[1]](https://git-tails.immerda.ch/tails/tree/config/chroot_loca l-hooks/06-adduser_tor-launcher?h=devel), [[2]](https://git-tails.immerda.ch/tails/tree/config/chroot_local-hooks/ 10-tbb?h=devel), [[3]](https://git-tails.immerda.ch/tails/tree/config/chroot_local-includ es/usr/local/sbin/tails-tor-launcher?h=devel), [[4]](https://git-tails.immerda.ch/tails/tree/config/chroot_local-includ es/usr/local/bin/tor-launcher?h=devel)) of Tails, the Tor Launcher can be run as a stand-alone XUL application currently, since the XUL will not be supported by mozilla in Firefox ESR branch [some time next year](https://blog.mozilla.org/addons/2016/11/23/add-ons-in-2017/), that implementation may not work for a long time. Beiseds, I agree with the Whonix core developer Patrick Schleizer that "the Tor Browser Bundle has its kind of users. system Tor (refers to Tor from packages.debian.org or deb.torproject.org) users, where Tor runs as daemon, is used in different ways for different purposes". Therefore, although anon-connection-wizard is a Python-clone of the Tor luancher, since all its dependencies are already in Debian and already packaged, it can still serve as a really useful tool for the system Tor users or a loose coupling substituition to the Tor Launcher. " > That said, this approach will not be viable any more some time next > year when the Firefox ESR branch drops XUL support and Tor > Launcher is deprecated upstream. Thank you so much for pointing out the fact. It makes the anon-connection-wizard project even more meaningful and helpful because it may serve as a substitution to the Tor Launcher in the future. I have add the point to my proposal! > It remains to see how the replacement of Tor Launcher will look, > it might still work for Tails. However, if anon-connection-wizard > would be a (more or less) drop-in replacement for Tor Launcher in > Tails, that would be immensely helpful since we'd have a solution > that will be guaranteed to work for us without much work. I am really glad to hear that my project may potentially be helpful to Tails. If this can happen one day in the future, it can benifit even more Tor users. > And I guess as long as the UX is more or less identical to the new > Tor Launcher and rapidly adapts to changes, and there are good > translations, we'd probably prefer it over the new Tor Launcher, > since it probably will be even harder to decouple from the web > browser. The UX is a main part of the anon-connection-wizard proposal. During the summer, I will mainly focus on the improvement of verbal instructions and the user interface instructions in anon-connection-wizard. Patrick has helped me to get the latest paper by Linda on tor-launcher usability, so that I can redesign the anon-connection-wizard basing on some solid research findings. Please look forward to it :) I am not worried too much about the translation actually. If the anon-connection-wizard is good and useful enough, maybe I can turn to the Tor Project translation [team](https://www.transifex.com/otf/torproject/) for help. The team is very efficient and active. BTW could you please tell me where I can find more about the development progress of the new Tor Launcher? I believe some communication and collaboration between us will be benefitial to both the anon-connection-wizard and the new Tor Launcher. Thank you very much! > > Any way, I also see potential for future collaboration between > Whonix and Tails for extending the usefulness of > anon-connection-wizard beyond what Tor Launcher (and its > replacement) offers [2]; This can be a really good point! If you don't mind, I would like to quote your idea as the "future work" in my proposal. > anon-connection-wizard targets the OS, not just a single > application, so it could integrate the choices of network > configuration (wired? which wireless network? MAC spoofing?) I agree with you that: > "save these settings so they are restored the next time you visit > the same network. This could potentially even be used to help > giving users control over entry node selection to avoid persistent > Entry Guards from leaking information about you geographical > movement." However, I am not sure if integrating the system-network-setting-related configuration(like MAC spoofing) in anon-connection-wizard will be a good idea in terms of a low coupling design. I am probably wrong but I personally prefer considering the anon-connection-wizard only as an graphical application to configure Tor, specifically, to configure torrc file. Could you please share your insights about how we should define the anon-conncetion-wizard please? I am really looking forward to hearing your thoughts. > and Tor configuration (proxy? pluggable transport?) in a single > place which probably makes more sense for users Yes! Let's brainstorm more about the [torrc-related setting](https://www.torproject.org/docs/tor-manual.html.en) at least! How about the FascistFirewall setting?! Users who are not really live in Tor-censored area should avoid using Tor Bridges for better anonymity. > > Cheers! > > [1] The first two scripts are parts of the build process, the two > latter ones are for starting it: * > https://git-tails.immerda.ch/tails/tree/config/chroot_local-hooks/06-a dduser_tor-launcher?h=devel > > > > * https://git-tails.immerda.ch/tails/tree/config/chroot_local-hooks/10-tbb ?h=devel > * > https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/u sr/local/sbin/tails-tor-launcher?h=devel > > > > * https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/usr /local/bin/tor-launcher?h=devel > [2] https://tails.boum.org/blueprint/network_connection/ [3] We > discuss the issue of > https://tails.boum.org/blueprint/persistent_Tor_state/ Thank you so much for your helpful sources. I will look at them in detail soon! Please let me say thank you again for your feedback, anonym! I really appreciate your help! I have revised my proposal with the help of your feedback and I am going to send it to tor-dev mailing list in a seperate email! Please look forward to it! -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY2TTWAAoJEKFLTbxtzdU88AsP/0cCPcMrTt2lOtF21jrrZV8Q sEPfYRWfsDc1Yc5QT+9zlOLynw7+W9BJ/WwwytCk37YmxS/xvl2T2/mGkoLH0hhk G4kJ58HyNmnjEA8fYnT77QWvh96Uznz7jeOd0th/tg9aZVcbFur7YBMSRnNzpMGq leqtiYNtd/HmVXHAGkAhy7GvMOHrfaEQiRXCSUuAJ6NR6W2cagELVfurEdZw7KkO 2OvHbe61oFS5p4n5ILdg+OLmXevpFtUA8YsbIxttIiaBhwkBNlMFUr/5Z9JY53v3 Q6ueYEaxKzFXwiaicWfhVgEGuDl4Ez5a7bTEvXATcXN0AldTNou8MBeontca728B lmh4wEGb/WM8ktnq/87kQD4oHkSUomGhati09kw70dCdkQhI5KmQM/3RwLrm/KNV XKuA/eeOHyV1E+1uh5GCODNKfbDSNR9k+M2wSiXFsrDb+9tcczP4MND/moiziquU 4TvK8mM6cFy0d3hO2QFIaL3myIRdu/+MvLZxMOnsqUb0KegBnmhgBePq/Txuxyb5 9pKvO0Oy4cDsLwx/LAR/YBmJbvLVuyyK+2woB94o39UsZYwJqBw9/VBfhUND2Iyh w0c0CvsRjyXo1v/EySE9W4wnpCWc7YHaFL9luYTyzQiCJyXrCFYt6JIiyEYZ6dQw MXWPr7sds1a8YMYlGh/1 =QjbB -----END PGP SIGNATURE-----

1 0

The behavior of ClientRejectInternalAddresses
by Jesse V 26 Mar '17

26 Mar '17

Hi everyone, I would like some clarification on ClientRejectInternalAddresses. The manual says: > "If true, Tor does not try to fulfill requests to connect to an internal address (like 127.0.0.1 or 192.168.0.1) unless a exit node is specifically requested (for example, via a .exit hostname, or a controller request). (Default: 1) In other words, if I disable this flag and I open 127.0.0.1:8080 in the Tor Browser, will the browser or the tor binary attempt to connect to the client's 127.0.0.1:8080? This is essentially what I'm after, and I just want to confirm that ClientRejectInternalAddresses is the best approach, or if there is a better setting. Just to clarify, I want to connect the client's localhost and not an exit's. -- Jesse

2 1