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

[Tom Lowenthal]

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


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.