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-almos... [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.a... [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.
-----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.
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!
[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.a...
[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?
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
On 01/10/13 03:13, Tom Lowenthal wrote:
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.
We have deployed and tested working instances of the combined obfs3/flashproxy transport. This includes all components - the client, server, facilitator and browser proxy - and they are all backwards compatible with the old components that only support the plain (non-obfs3) websocket protocol. Soon (this week) the code will be merged. There are a few other issues to iron out before a production-quality release. We may be able to do it by Halloween, but I'd prefer not to rush through them just to make that date (if that is fine for the sponsor). I'm more certain it will be production-quality sometime mid-November.
I haven't considered PTBB packaging and I'm not sure about the work needed, but if George does this in parallel with me making the code production-quality, the timings should line up as expected.
Specific remaining tasks:
- merge #9349, #6810, #9974 - push #7167 to an official tpo repo - do #9976, and #7167#comment:42 might require an obfsproxy fix
Other less-vital things which improve robustness/quality:
- connection reliability under churn: #9964, #5426, #8285 - flexibility of ecosystem: #9942, #9949, #9965 - various other code-quality issues, all on trac, see [1]
We've also made progress on the long-term goal of general PT composition, mentioned in the the intended/ideal outcomes, as #9744:
- solid and complete ideas in place - start of precise design specs - can now see a full path to eventual implementation
[1] Full list of tickets; though about half are not relevant to this deliverable. https://trac.torproject.org/projects/tor/query?status=!closed&component=...
On Mon, Oct 14, 2013 at 09:14:25PM +0100, Ximin Luo wrote:
On 01/10/13 03:13, Tom Lowenthal wrote:
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.
We have deployed and tested working instances of the combined obfs3/flashproxy transport. This includes all components - the client, server, facilitator and browser proxy - and they are all backwards compatible with the old components that only support the plain (non-obfs3) websocket protocol. Soon (this week) the code will be merged. There are a few other issues to iron out before a production-quality release. We may be able to do it by Halloween, but I'd prefer not to rush through them just to make that date (if that is fine for the sponsor). I'm more certain it will be production-quality sometime mid-November.
I haven't considered PTBB packaging and I'm not sure about the work needed, but if George does this in parallel with me making the code production-quality, the timings should line up as expected.
Specific remaining tasks:
- merge #9349, #6810, #9974
- push #7167 to an official tpo repo
- do #9976, and #7167#comment:42 might require an obfsproxy fix
I agree with this, except that I don't think #9974 (facilitator packaging) and #9976 (general argument passing to registration helpers) are necessary for this deliverable. They are nice and I want them, but in terms of this deliverable I would prioritize #9349 (facilitator transport support) and #7167 (obfs–flash composition) first.
Would you hate me if I suggest not merging #6810 (client code reorganization) until after we build at least one bundle? It's lower risk to go with the organization we know works, especially given that we are changing other things within the bundle.
Other less-vital things which improve robustness/quality:
- connection reliability under churn: #9964, #5426, #8285
- flexibility of ecosystem: #9942, #9949, #9965
- various other code-quality issues, all on trac, see [1]
Just one note here, #8285 (expiration of email registrations) is already closed.
David Fifield
On 19/10/13 06:31, David Fifield wrote:
On Mon, Oct 14, 2013 at 09:14:25PM +0100, Ximin Luo wrote:
Specific remaining tasks:
- merge #9349, #6810, #9974
- push #7167 to an official tpo repo
- do #9976, and #7167#comment:42 might require an obfsproxy fix
I agree with this, except that I don't think #9974 (facilitator packaging) and #9976 (general argument passing to registration helpers) are necessary for this deliverable. They are nice and I want them, but in terms of this deliverable I would prioritize #9349 (facilitator transport support) and #7167 (obfs–flash composition) first.
Would you hate me if I suggest not merging #6810 (client code reorganization) until after we build at least one bundle? It's lower risk to go with the organization we know works, especially given that we are changing other things within the bundle.
Strictly speaking, I *would* consider them part of the deliverable, from the view of software quality. Not having them, would be a "minimal outcome" IMO. If we don't consider it part of this deliverable, which deliverable *are* we supposed to consider it part of? These arguments could be made at any time.
If this is an isolated case then fine, but I don't want to see a pattern where unsexy sub-surface work is repeatedly neglected. We're not trying to capture a market so there's no need for "just good enough" tactics. That would be analogous to shoddy construction work / software engineering that looks ok and works ok until it collapses in an earthquake or gets your mass user-base auto-exploited, or in our case if someone does more work on top of flashproxy (#6810 fixes this) or wants to use a client with a different facilitator (#9976 would fix this) or wants to install a new facilitator (#9974 fixes this by greatly lowering the cost). (The last few are pretty important if we don't want a central point of failure.)
If you de-prioritise that work now to make a deadline, you must treat them with highest priority afterwards, before taking on newer features like webRTC or general PT composition. (As opposed to e.g. the previous cycle where we started with #7167, a big new feature.) Especially #6810 - I consider that to be paying off technical debt incurred from the previous cycle, so this isn't even de-prioritising, it's pushing back the correction of what should have been corrected already.
On Sat, Oct 19, 2013 at 12:46:33PM +0100, Ximin Luo wrote:
On 19/10/13 06:31, David Fifield wrote:
On Mon, Oct 14, 2013 at 09:14:25PM +0100, Ximin Luo wrote:
Specific remaining tasks:
- merge #9349, #6810, #9974
- push #7167 to an official tpo repo
- do #9976, and #7167#comment:42 might require an obfsproxy fix
I agree with this, except that I don't think #9974 (facilitator packaging) and #9976 (general argument passing to registration helpers) are necessary for this deliverable. They are nice and I want them, but in terms of this deliverable I would prioritize #9349 (facilitator transport support) and #7167 (obfs–flash composition) first.
Would you hate me if I suggest not merging #6810 (client code reorganization) until after we build at least one bundle? It's lower risk to go with the organization we know works, especially given that we are changing other things within the bundle.
Strictly speaking, I *would* consider them part of the deliverable, from the view of software quality. Not having them, would be a "minimal outcome" IMO. If we don't consider it part of this deliverable, which deliverable *are* we supposed to consider it part of? These arguments could be made at any time.
Don't get me wrong--I think these things are valuable and I want to do them right after building a test PT TBB. Those tickets aren't part of any deliverable, but they don't have to be part of a deliverable to be worth doing.
It's not that I'm trying to neglect unglamorous development--I'm really not. This is how I see it: As a software engineer, I am always trying to reduce risk. Refactoring code reduces risk in the long term but increases risk in the short term. Sticking with our old busted duplicated code is risky in the long term, but very predictable in the short term. We've already done a lot to destablize the code (just by adding new features), so if possible I prefer not to further destablize it before trying to build bundles. The risk associated with refactoring is one I think can be safely deferred for a couple of weeks.
Does it at least come across that there is some principled reasoning behind my recommendations?
I'm fully with you on doing code quality improvements before WebRTC and transport composition.
David Fifield
On 20/10/13 07:02, David Fifield wrote:
It's not that I'm trying to neglect unglamorous development--I'm really not. This is how I see it: As a software engineer, I am always trying to reduce risk. Refactoring code reduces risk in the long term but increases risk in the short term. Sticking with our old busted duplicated code is risky in the long term, but very predictable in the short term. We've already done a lot to destablize the code (just by adding new features), so if possible I prefer not to further destablize it before trying to build bundles. The risk associated with refactoring is one I think can be safely deferred for a couple of weeks.
Does it at least come across that there is some principled reasoning behind my recommendations?
I'm fully with you on doing code quality improvements before WebRTC and transport composition.
OK, I can get along with this.
-
Colin C. -
David Fifield -
Tom Lowenthal -
Ximin Luo