Re: [tor-dev] Improving hidden services on mobile phones
Hi Chris, Chris Ballinger: > Glad to see more work on this! For a while I've been toying with the idea > of making a one-button Android XMPP server app that uses Tor HS to solve > the CGNAT reachability issue. Thanks for your interest! If you're building a messaging system based on Onion Services, please have a look at Ricochet [1]. I would be absolutely awesome if someone port/implement/improve it on Android! * The problem with XMPP is that there is a central system (server) to which metadata is exposed in order to work. It's bad. :) [1] https://github.com/ricochet-im/ricochet -- Ivan Markin ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [GSoC16] Expand Nyx - Status Report 3
Hi everyone, This is the third report for the 'Expand Nyx' project for GSoC 2016. I have been working on the following things since the past 2 weeks: * Added the basic interpreter panel. The interpreter panel now, internally uses Stem's interpreter panel. * Added help options to the interpreter panel. Appropriate error is shown when non-recognizable commands are entered. * The ANSI output from Stem's interpreter panel is now formatted to show appropriate color and attributes. * A scroll-bar has been added to the interpreter panel. The interpreter panel code that was added by me, can be seen at: https://github.com/sammyshj/nyx/pull/11 In the next weeks, I will be working on adding the history validation and tab completion for the interpreter panel. Hope everyone has a fun weekend! Thanks, Sambuddha ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [GSoC] Tails Server - status report 4
Hi everyone, this is the fourth status report on the Tails Server GSoC project. First off: There are nightly images of Tails with integrated Tails Server available for download [1]. Some notes if you want to test it: - Installation of the first service will take several minutes, because the APT package lists have to be downloaded - If you boot the image in a VM, the loading spinners won't spin. I couldn't yet figure out why. - The Gobby Service's status does not turn to "stopped", it remains in "deactivating" [1] http://nightly.tails.boum.org/build_Tails_ISO_feature-5688-tails-server/builds/ Here is what I did in the last two weeks: * Work on the GUI * Implement three different approaches to edit the options. Discuss each of them on the tails-ux mailing list. Start conducting short user tests to get some data on which approach provides the best UX. * Implement a status line (this replaces the loading window I implemented previously) * Group the options * Rework the displayed connection info * A lot of smaller improvements * Use stem to create ephemeral hidden services instead of editing torrc * Implement reset of the onion address * Make Gobby Server work * Integrate Tails Server into Tails * Fix a lot of issues Next up is (still) writing a short documentation for the upcoming user tests. Then I will begin to conduct the user tests. Also, the autostart and client authentication features are still not implemented. And I plan to include some doxygen-like specification in the code. Cheers. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] RelayAwards - incentives
> - We started this > website because we believe that competition can make more operators > improve their relay by following best practice. This would make the > whole Tor-network better if we have straight guidelines. > https://www.relayawards.com/ If it is about competing operators then you should aggregate an operator's tor instances not care to much about single tor instances of a given operator? You might just team-up with http://tor-roster.org/ Creating incentives for a high uptime would create incentives to run relays insecurely (never upgrade, never reboot, run vulnerable software longer). I wouldn't give away awards for low uptimes either - just leave it out of the equation? With over 94% CW [1] being routed by Linux relays, why is it good to run more Linux relays? I'd say create incentives for non-Linux relays. [1] https://github.com/ornetstats/stats/blob/master/o/os_share.txt How about anti-incentives? -5 for relays @ OVH added after a certain point in time? signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [GSoC] CONIKS for Tor Messenger - status report #3
Hi everyone, This is my third status report on the CONIKS for Tor Messenger project. These are things that I have been doing in the last two weeks: 1. Continue implementing the Merkle prefix tree module. Currently, the STR source code are under review. This module takes a lot of time since it is probably the biggest components. There are a lot of discussions over the development to make sure everything is on right track (e.g. the proof of absence …) 2. Continue working on libconiks library. This library currently consists of several modules: - CONIKS server construction from config file - TLS socker listener - Request handler I submitted a pull request for the registration implementation [1]. 3. Registration implementation (Tor Messenger-specific module). This work includes both server & client modules: - Server modules: the registration bot acts as a proxy between the client and the CONIKS server. Account verification is performed by comparing the fingerprint (base64 encoded) included in registration request and the DM sent to CONIKS twitter account. - Client modules: the client module consists of a preferences UI and coniks module which sends the request. Currently, the policies setting of each user is stored in a sqlite database. (source code of client module is pushed to [2]) - The server will return base64 encoded string of the temporary binding (TB). This would be changed when we start working on monitoring & key lookup modules. (i.e. returning more data along with TB) - The verification message (Twitter direct message) format is: ?CONIKS?b64Encode(fingerprint) The registration protocol can be illustrated as follows: Client - Registration bot (listening on port 3000) - CONIKS server (listening on port 3001) 1. Client sends a DM to CONIKS Twitter handle 2. Client sends a registration request to registration bot 3. Registration bot verifies the request 4. If it is valid, the bot forwards the request to the CONIKS server 5. The server returns a TB for the requested user 6. The bot forwards the TB to the client. The source code is available for review [3]. After some discussions with my mentors (Arlo and Marcela), we also came up with an improved account verification scheme. In the original proposal, the client would send the public key to the registration bot and the signed public key to the twitter handle. However, that doesn't always make much sense, since the Merkle tree really stores an opaque blob, not just a key. The verification protocol could be simplified by letting the client send the fingerprint to both registration bot and the twitter handle. Then we can do a comparison these two messages for the verification. The new verification scheme seems more effective in case of Tor Messenger and OTR protocol. Best, Huy — [1] https://github.com/coniks-sys/libconiks-server-go/pull/3 [2] https://github.com/c633/ctypes-otr/tree/coniks-registration [3] https://github.com/c633/tor-messenger-coniks/pull/1 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [GSOC16] Fingerprint Central - Status report n°3
Hi everyone, Here is my third status report for my GSOC project. https://github.com/plaperdr/fp-central 1 - Following my last report, I've added the following elements to Fingerprint Central: - A page that detects the current level of the security slider of the Tor browser - A page that looks if the current fingerprint is "acceptable" compared to the Tor guidelines. This feature will evolve in the future to be more complete and to provide more feedback to users. - Support of users without JavaScript - Improvements of the code of the main FP page so that it reduces server load (by storing locally the information of the current fingerprint) I've also added support of Promises so that computation-heavy tests can be run without blocking the whole collection process. The added test on the AudioContext API is the first one to make use of that feature. 2 - We will launch a beta next week of FP Central to get early feedback on the project. Any ideas and suggestions will be welcome so that the website will be the best it can be for both users and developers. The server is online but I'm still making some final tweaks and bug fixes so that the launch will be smooth. I'll send an email early next week to this mailing list to inform everyone when it'll be ready. My goal in the next two weeks is to launch the beta of the website and start working on a great statistics page along with a more complete version of the "acceptable fingerprint" page. Have a great week-end, Pierre signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Improving hidden services on mobile phones
Hey list, just for the record, during the past weeks we've been discussing how to improve hidden services hosted on mobile phones in this here trac ticket: https://trac.torproject.org/projects/tor/ticket/16387 Discussion has also spilled over ticket #18620. The discussion also has a design aspect as some suggested improvements would require protocol changes, hence I'm informing this list in case some people are interested in jumping in and participating. For example, for some use cases it might make sense to have an HS -> IP cell INTRODUCE2_ACK that acknowledges the receipt of INTRODUCE2 cells, so that the IP knows that the intro circuit is active and the HS received the introduction request before sending out its own INTRODUCE_ACK to the client. That's because mobile hidden services are unstable and their intro circuits break frequently, causing reachability issues. See the second part of https://trac.torproject.org/projects/tor/ticket/16387#comment:8 for more background. Have a good day :) ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] A meta-package for Pluggable Transports?
Ximin Luo: > Nima Fatemi: >> [..] >> >> After some discussion on #tor-project a little while ago, the idea of >> having a meta-package that includes all or the most recent transports >> came up. Where people would install this meta package and it would >> automatically take care of the required steps to get the latest >> obfsproxy and set it up. >> >> [..] > > I made something like this a few years ago: > > https://people.debian.org/~infinity0/apt/pool/contrib/t/tor-bridge-relay/ > > I had planned to add a lot more things to it, like what you suggested in the > rest of the email, but never got around to it. > > Someone else could take this as a base to start working from, though. > One reason is because #1922 was never completed. I built the packaging assuming that it would be fixed by the time I finished it, but this hasn't happened yet. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] A meta-package for Pluggable Transports?
Nima Fatemi: > [..] > > After some discussion on #tor-project a little while ago, the idea of > having a meta-package that includes all or the most recent transports > came up. Where people would install this meta package and it would > automatically take care of the required steps to get the latest > obfsproxy and set it up. > > [..] I made something like this a few years ago: https://people.debian.org/~infinity0/apt/pool/contrib/t/tor-bridge-relay/ I had planned to add a lot more things to it, like what you suggested in the rest of the email, but never got around to it. Someone else could take this as a base to start working from, though. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
