[tor-dev] Sponsor F: final Y3 meeting at 1100 Pacific today

[Tom Lowenthal]

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 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
>
>
> 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.