- tor-dev - lists.torproject.org

Sponsor F: update; next meeting [in *two weeks*]
by Tom Lowenthal 21 Oct '13

21 Oct '13

Today, at 1100 Pacific, we spent more than 90 minutes discussing [Sponsor F][]. Here's the summary. **READ THIS**: The next Sponsor F meeting will be held in a mere two weeks on **2013-10-14, at 1100h Pacific in #tor-dev**. This is a schedule change: from now on, the meetings will be every two weeks. It's possible that we may have to increase this to every week, depending on how fast we work, and how long meetings are taking. If you should be at these meetings but cannot make Mondays at 1100h Pacific, please contact me, and I'll start the process of finding a better time or times. If you are individually in the `cc` field of this message, it's because I think that there's something which I think you need to do for Sponsor F before Halloween. You should also come to the next Sponsor F meeting. If you can't make the meeting, or don't think this work applies to you, you should get back to me ASAP so we can fix it. Is something else missing, wrong, or messed up? I'd like to know. [Sponsor F]: https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorF/Year3 * * * * * Core Phase 2 Deliverables ========================= UDP Transport [#10] ------------- **[On Track: Minimal]** Karsten will work with Rob to complete the Shadow simulation of this work, then write up a full report on this, probably with Stephen's help. We expect both tasks to be complete by Halloween. This likely represents a minimal outcome for this deliverable. Combine obfuscation (obfsproxy) with address-diversity (flashproxy) [#11] ------------------------------------------------------------------- **[On Track: Minimal]** The work of integrating obfsproxy with flashproxy is done. George will include this in the next released version of the pluggable transports browser bundle. George will also write a report on this work. Ximin and David will help. By Halloween, the report will be complete and the bundles will either be released or well on their way through testing. This likely represents some combination of minimal or intended outcomes for this deliverable. Bridge Metrics [#12] -------------- **[Done: Intended]** Our reporting code has been merged into master. It will ride the trains or flow downstream or whatever your favorite code development cycle imagery is, and show up in future releases. As it goes through alpha, beta, and release, gets picked up and adopted by more operators, we'll get more comprehensive sample coverage, and better data. This likely represents an ideal outcome for this deliverable. N23 Performance Work [#13] -------------------- **[On Track: Alternate]** Roger doesn't think that N23 is as good as we thought it was, so he's going to write a report on the various performance improvements we've implemented lately; the performance work which we though about, but decided not to implement, and why; and a wishlist of future performance work and research. He'll have this done by Halloween. This likely represents an alternate outcome for this deliverable. Improved Scheduling [#14] ------------------- **[On Track: Intended]** Nick will work with Roger and Andrea to implement an improved scheduler (possibly based on picking randomly, weighted by bandwidth), and -- if possible -- also to refactor `cmux`. If time permits, Nick will also attempt to simulate this using Shadow , probably with Karsten's help. Finally, Nick will produce a full report before Halloween. This likely represents an intended outcome for this deliverable. Alternate `Fast` Flag Allocation [#15] -------------------------------- **[At Risk]** The person who we initially expected to do this work does not seem to be available to do it. We need to find an alternate plan to execute this deliverable. If you think you can do it, please read [ticket #1854][#1854] and get in touch. [#1854]: https://trac.torproject.org/projects/tor/ticket/1854 VoIP Support [#16] ------------ **[On Track: alternate]** Our implementation strategy for this was high-latency send-an-mp3-over-XMPP using Gibberbot/Chatsecure, or a similar system. The internal milestone was to have a release candidate available today. Sadly, Nathan (who is on point for this) wasn't on the call. Fortunately, Nathan [blogged][guardian-1] about Chatsecure's `12.4.0-beta4` ten days ago, and a tantalizingly-named [`ChatSecure-v12.4.2-release.apk`][chatsecure-release] ([sig][chatsecure-release-sig]) is available in the Guardian Project [release directory][guardian-releases]. The outlook seems good, but Tom will follow up with Nathan as soon as possible to verify these outrageous claims. Nathan, if you're reading this, could you get in touch (email, IRC, XMPP, whatever). Thanks! [guardian-1]: https://guardianproject.info/2013/09/20/gibberbots-chatsecure-makeover-almo… [chatsecure-release]: https://guardianproject.info/releases/ChatSecure-v12.4.0-beta4-release.apk [chatsecure-release-sig]: https://guardianproject.info/releases/ChatSecure-v12.4.0-beta4-release.apk.… [guardian-releases]: https://guardianproject.info/releases/ Extended Phase 2 Deliverables ============================= VoIP Support [#17] ------------ **[Limbo: Intended]** Here we're talking about getting a general VoIP client (Mumble) to work over Tor. This discussed in [ticket #5699][#5699], and [instructions][torify-mumble] for using Mumble over Tor are on the wiki. We didn't get an update during the meeting, so if you're working on this, get in touch, eh? [#5699]: https://trac.torproject.org/projects/tor/ticket/5699 [torify-mumble]: https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/Mumble Simulating Tor [#18] -------------- **[On Track: Intended]** Linus will finish Shadow improvements as needed, and write a full report on his Shadow work. That'll all be done by Halloween. This probably represents the intended outcome of this deliverable. Relays as Bridges [#19] ----------------- **[Done: Minimal]** Using a public relay as a bridge works. Defiance [#20, #21] -------- **[At Risk]** We cannot work on these without open Defiance code. Throttling Classifiers [#22] ---------------------- **[On Track]** Adaptive throttling seems to come with unpleasant anonymity tradeoffs, so we're not doing that right now. It looks like static throttling will work really quite well, without these tradeoffs. Torbrowser Optimistic Data [#23] -------------------------- **[Done: Ideal]** It's in your TBB *right now*. FAQ === **Q**: Why do you keep talking about Halloween? **A**: We're currently in Phase Two of Year 3 of the Sponsor F project. That phase ends on October 31st 2013, so we should try to finish everything as best we can before then. Also: if we don't finish, at midnight (local time) each person who has an outstanding deliverable will be besieged by a seemingly-endless horde of zombies. Others may be besieged too: the zombie report is hazy.

4 6

Re: [tor-dev] Sponsor F: update; next meeting [in *two weeks*]
by matt＠pagan.io 21 Oct '13

21 Oct '13

I wanted to give another update as to the status of patching Mumble to support native Tor proxification. Mumble uses its own connection protocol to make external connections, a protocol which is defined in a 30-page pdf file which comprises most of Mumble's documentation (the comments in the code are quite sparse). Most of the methods laid out in mumble-protocol.pdf are defined in the file mumble.pro (or mumble.proto in the github version). I suspect the method named 'connect' of being a culprit in the DNS leaks. Unfortunately 'connect' is not defined in mumble.pro like the rest of the connection protocol. Right now I am searching for where this method is defined. I have visited #mumble on freenode, but no one there was able to offer any insight. I even wrote a simple tool to help me search for this method, but 'connect' is used in over 30 of mumble's *.cpp files (and none of the *.h files).

1 0

I2P's Syndie (wrt HS publishing)
by George Kadianakis 21 Oct '13

21 Oct '13

Hey people, there seems to be some movement on improving HS publishing (making it easier and more user friendly) lately. I just wanted to point you to a project by I2P called Syndie which looks relevant to your interests: http://syndie.i2p2.de/ (FWIW, I haven't checked its code or its architecture yet.)

2 1

Attentive Otter: Usability issues with existing OTR clients
by Mike Perry 18 Oct '13

18 Oct '13

Here's the major usability pain points I've run in to with various OTR clients over the years. Feel free to chime in with any additional issues you've noticed. 1. The multiple client problem: If you have two devices online simultaneously under the same account, they will fight and endlessly renegotiate. This issue may be specific to OTRv2 only. Arlo pointed out that this change in OTRv3 may solve a lot of these problems: "Both fragmented and unfragmented messages contain sender and recipient instance tags. This avoids an issue on IM networks that always relay all messages to all sessions of a client who is logged in multiple times. In this situation, OTR clients can attempt to establish an OTR session indefinitely if there are interleaving messages from each of the sessions." -- https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html We should be sure we use these features properly, and make sure the js-ctypes wrappers are updated to support the new libotr v3 APIs with these instance tags. The current js-ctypes wrapper may still be v2 only. If for some reason these tags in v3 can only be used if both parties support v3, perhaps we can add some additional code to track OTR state using XMPP resource/device info and tell the OTR lib underneath that different XMPP resources are actually different users, so that at least XMPP accounts won't have this problem. 2. Better TOFU support: We should track only one OTR key for a given XMPP resource/device ID. Some people I communicate with are constantly rotating OTR keys for security and other reasons. However, this doesn't help me any: I have accumulated about 50 keys of unknown age and usage pattern in my OTR fingerprint list for them, and I have no idea which ones have been changed due to compromise, device loss, or simply due to reinstall. Worse, I have no idea which keys should correspond to which XMPP resources/devices. If a user changes the key for a given XMPP resource ID, we should expire the previous key and loudly alert the user of the fact that the resource's key has changed, and ask them if they want to replace the old key with the new key. We should not simply accumulate more keys by default, especially for the same XMPP resource/device, and especially not for unverified keys. At the same time, we should allow a different OTR key for each unique XMPP resource ID, and perhaps allow non-XMPP keys to accumulate at user option. 3. "Unreadable encrypted message" errors should be visible only to advanced users/in the error console, and the client should transparently renegotiate and resend. It looks like OTR has an ERROR_START_AKE flag for this, but for some reason, some states of OTR in Pidgin still cause me to get and send these errors and miss messages though, usually if one client has crashed or restarted without properly ending the conversation. We should try extra hard to force key re-negotiation in these cases. We probably also want an auto-responder after the renegotiation that informs the other party that N messages were missed (for clients that don't support OTR's built-in notifications). 4. OTR shouldn't get stuck in the "Finished" state when you end a conversation. I've noticed in the past that OTR seemed to refuse to automatically negotiate/re-negotiate if it is still "Finished" regardless of your "Require/Force OTR" setting. This is just bad, and often causes plaintext to leak. 5. It should be impossible for our client to send a message in plaintext by default, and the client should discourage counterparties from sending more than one plaintext message. Perhaps related to issue 3, I've not had very good results with the "Require OTR"/"Force OTR" options on many clients. It also seems like many people's clients will still send the first message unencrypted (to get the handshake hint), and on all clients OTR doesn't seem to try very hard to negotiate if an unencrypted message is received. On our side, we should hold those messages and send only the handshake initiation (ie our default OTR mode should be REQUIRE_ENCRYPTION). We may also want to consider a plaintext auto-reply for when we receive unencrypted messages. Something like "Please install and enable OTR before sending further messages" as a separate message in *addition* to attempting an OTR handshake. 6. The UI should have per-message encryption indicators (send and receive) For many clients, the UI is not clear which messages were sent encrypted, especially if the OTR state has changed due to autonegotiation or "Finishing". We should have per-message icons for both sent and received messages that indicate encryption status for that message in the chat scrollback window. 7. Logging should be off by default when OTR is on. -- Mike Perry

3 2

REMINDER: Attentive Otter IM meeting in 1h [1430 Pacific]
by Tom Lowenthal 18 Oct '13

18 Oct '13

Today at **1430h Pacific** (an hour from now), we'll be in #tor-dev talking about how to turn Instantbird into TorMessenger, or MessengeTor, or OnionTalk, or something. Some of you noticed my cunning test of putting different times in the subject and the body. The body was right, it's 1430 Pacific! See y'all soon! -Tom On 15 October 2013 21:57, Tom Lowenthal <me(a)tomlowenthal.com> wrote: > Sorry about this late notice too. I thought I'd sent these times out > already, but apparently I was rather mistaken. > > We'll be in #tor-dev tomorrow Wednesday 2013-10-16 at 1430 Pacific to > talk about the Tor IM project. We may take up to 90 minutes, and plan > to meet again next week, probably at the same time unless there are > conflicts. > > Arlo came up with [a cunning plan][1] m'lord. You should totes read it > and come tomorrow with questions and suggestions about how best to > implement Instantbird as the Tor IM app. > > See y'all tomorrow. Play nice, now. > -Tom > > [1]: https://gist.github.com/arlolra/6969273

2 1

REMINDER: 1 hour until Cute Otter hidden services & publishing
by Tom Lowenthal 16 Oct '13

16 Oct '13

Just under an hour until 1130 Pacific on Wednesday 2013-10-16. We'll be in #tor-dev, talking hidden services and publishing. -Tom On 15 October 2013 21:40, Tom Lowenthal <me(a)tomlowenthal.com> wrote: > Sorry about the late notice, folks. I thought I'd sent these times out > already, but apparently I was rather mistaken. > > We'll be in #tor-dev tomorrow Wednesday 2013-10-16 at 1130 Pacific to > talk about hidden services, scaling thereof, and safe publishing > therewith. We may take up to 90 minutes, and plan to meet again next > week, probably at the same time unless there are conflicts. > > It'd be super neat if you could familiarize yourself with [Sina's > proposal][1] before the meeting. Come with constructive comments and > suggestions. > > See y'all tomorrow. > -Tom > > > [1]: https://lists.torproject.org/pipermail/tor-dev/2013-October/005558.html

1 0

Attentive Otter IM: tomorrow Wednesday 2013-10-16 at 1400h Pacific
by Tom Lowenthal 16 Oct '13

16 Oct '13

Sorry about this late notice too. I thought I'd sent these times out already, but apparently I was rather mistaken. We'll be in #tor-dev tomorrow Wednesday 2013-10-16 at 1430 Pacific to talk about the Tor IM project. We may take up to 90 minutes, and plan to meet again next week, probably at the same time unless there are conflicts. Arlo came up with [a cunning plan][1] m'lord. You should totes read it and come tomorrow with questions and suggestions about how best to implement Instantbird as the Tor IM app. See y'all tomorrow. Play nice, now. -Tom [1]: https://gist.github.com/arlolra/6969273

1 0

Cute Otter hidden services & publishing: tomorrow Wednesday 2013-10-16 at 1130 Pacific
by Tom Lowenthal 16 Oct '13

16 Oct '13

Sorry about the late notice, folks. I thought I'd sent these times out already, but apparently I was rather mistaken. We'll be in #tor-dev tomorrow Wednesday 2013-10-16 at 1130 Pacific to talk about hidden services, scaling thereof, and safe publishing therewith. We may take up to 90 minutes, and plan to meet again next week, probably at the same time unless there are conflicts. It'd be super neat if you could familiarize yourself with [Sina's proposal][1] before the meeting. Come with constructive comments and suggestions. See y'all tomorrow. -Tom [1]: https://lists.torproject.org/pipermail/tor-dev/2013-October/005558.html

1 0

Comments Requested: General anonymity with Tor video
by Sherief Alaa 15 Oct '13

15 Oct '13

Hello Everyone, I am working on a general anonymity with Tor video [0] and a script [1] for it. This video will be translated to all of the help desk languages. Basically, the video will some slides playing while I talk/explain them, both the video script and the slides can be found on trac [0][1] I would appreciate your comments/suggestions before I start recording the video. (Deadline 18-Oct-2013.) If you find any mistakes, please let me know here or on trac [0][1] Thanks! [0] https://trac.torproject.org/projects/tor/ticket/5991 [1] https://trac.torproject.org/projects/tor/ticket/6922 -- Sherief Alaa pgp 0x8623B882

2 1

REMINDER: Boisterous Otters helpdesk meeting in 1h
by Tom Lowenthal 15 Oct '13

15 Oct '13

Today at 1100h Pacific (an hour from now), we'll be in #tor-dev to discuss how we're going to start offering webchat support, in line with the [draft][1] produced by Colin (Phoul), with help from Lunar and Erinn (Helix). See y'all soon! -Tom [1]: https://trac.torproject.org/projects/tor/wiki/org/sponsors/Otter/Boisterous…

1 0