Happy Monday,

This is your just-a-smidge-more-than-an-hour reminder that the final Sponsor F year 3 meeting will be in #tor-dev at 1100h Pacific. Bring true tales of your work, the final reports you've been preparing, and -- probably -- snacks.

Sadly, I suspect that this meeting will last slightly more than the 90 assigned minutes. I plan to proceed in deliverable number order, so you may be able to use that as a gauge. If you can only be near the beginning or the end of the meeting, I'd love to know that forthwith so that I can jazz up the order for optimal conveniencing.

Also, in the unlikely event that I still have your attention, it'd be really super neat if you could drop into the [Sponsor F year 4 riseup pad][1] and make sure that anything which sounds like you might want to help has your name near it, and that anything you might want to take point on has not just your name, but also as many time, difficulty, chance of success, and alternate result descriptions as you can.

See y'all in an hour or so. -Tom

1: https://pad.riseup.net/p/Vt0TDXcdH0PB_Tor-Sponsor-F_Year-4

On 30 September 2013 19:13, 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?

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.