-----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@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----- _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev