On Mon, 30 Sep 2013 19:13:37 -0700 Tom Lowenthal me@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.

---

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.

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!

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?

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/