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

[Colin C.]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 30/09/13 09:13 PM, Tom Lowenthal 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. 
> _______________________________________________ tor-dev mailing
> list tor-dev at lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> 
Matt and I gave an update on #17 directly after the meeting ended. The
meeting was called before #17 was brought up, so it may have appeared
that we were not there.

The current state of #17 is that there is a leak in Mumble's proxy
settings that makes it difficult for users to use Mumble safely. There
is a bug open for this issue on Mumble's bug tracker at
http://sourceforge.net/p/mumble/bugs/1033/.

We will have further information for the next meeting, and Matt may
have a response with further details.

- -- 
- -Phoul
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJSSj7vAAoJEJ01Zvx7KO7YFAUP/3hEek8QTS9ws1E19y2sc9II
mtzuR7FuSJUj3a6nMHR901Em5SCl91Zm/NPUDaF43T2GtD+zl1ITynf5Satpzy3M
0f1Prq5ROWdY6ghJ5+oBQcTw2AmDFOT5enc6e3AJUx2tG7wyUCUOCOmiHqBfETkm
/p8jibo350/BXkeJvxPXOYO/thoCSYOWmeXf9BWZF1cyNXpg68eNwgqcOUvz4kkB
qHUogVNfi+ciGFAElwQifj7raNP0++Cg2dBKX7uZuQjs70xfL+PGCgTX+fZx3vBW
rg4LUzTy5gkIaUtjlfYMP0KHm/49EktNcjpTlbDQJul6vbLWW+mZcZrrVeOq/fuv
RLHbWv98FC5uOS7HlRTQBuWRJIDCFXZxFD7k2hLntf8MwkHrdrPirmbT/bD5SU6v
xsJrwTHSW1fey1ING8oaucx+P90z+oAmWs47wV0XdqvLYer+F3K3Sn9P6GzO9jjN
1JA7p1QRFaOUALayQ/OHXZ5CC3PKPXhXK7EUyUBKw1ZjOgelwNNj83ZZwoFTDfHx
0B37SjNwH62NccSl/h55onrw5tlWpSANiqbMnXySUk0X52JYt9WDazY3FCaFhc1c
fjJN2sd8/G6DdOzEHuwrR7ZW+jRnMHn9i5qSREYV0hr8HXofXwJ7LnDnT9bY0y6M
nzzq9Y9lawn+BMW1GkGZ
=NWD/
-----END PGP SIGNATURE-----