[tor-dev] Sponsor F: update; next meeting [in *two weeks*]

[Matt Pagan]

On Mon, 30 Sep 2013 19:13:37 -0700
Tom Lowenthal <me at tomlowenthal.com> wrote:

> 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-almost-done/
> [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.asc
> [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
> 
> 

There still exists a bug in Mumble such that when network connections
are routed through a proxy they leak DNS requests. This past month I've
been reading QT documentation so that I can understand the Mumble code
better and find the bug. After the meeting on IRC, velope suggested
that fixing it might be as simple as implementing SOCKS5 with
hostname. DNS leaks also occur with HTTP proxies, which shouldn't
happen. See also: http://sourceforge.net/p/mumble/bugs/1033/