Write a pluggable transport deployment roadmap

added SponsorG20120331 component::circumvention/pluggable transport owner::asn priority::medium resolution::implemented status::closed type::project labels

Trac:
roadmap.tex

Trac:
roadmap.pdf

I attached an initial draft version of the deployment roadmap document.

The obfsproxy bundle contained 14 obfsproxy bridge addresses, not 25.

Trac:
Status: new to needs_revision

Maybe it's 25 together with the orbot thing?

Some comments:

The document doesn't have an author name nor contact information. Please consider putting in your name and email address.
Should Section 2 have its own subsection for saying what changes are required to Vidalia, maybe as new first subsection? If these changes are already made, great, but I think they should be stated in this roadmap. Speaking of Vidalia, are there plans to configure obfsproxy on the server side?
In Section 2.1, how will BridgeDB distribute obfuscated bridge addresses? Will users specifically ask for them instead of non-obfuscated bridge addresses, or will BridgeDB include an obfuscated bridge address or two in every response? If there are different transports, will BridgeDB tell you one address per transport, or will the user have to ask for a specific transport? I'm sure there are even smarter questions about possible BridgeDB designs, but I think they should be discussed in Section 2.1 or on Trac and referenced here.
Maybe add a remark that statistics mentioned in Section 2.2 won't be deployed on a 0.2.3.x timeframe.
Sections 2.2 and 2.4 talk about a future that is farther away than 2.1 and 2.3. Would it make sense to have Section 2 talk about the future in 3--6 months and a new Section 3 talk about the future after that? If not, feel free to ignore this suggestion.
In Section 3 you talk about updating obfsproxy on the server side. Are there any plans to have an Obfsproxy Bridge Bundle of some sort? Or will the Tor Bridge Bundle contain obfsproxy by default?
In the short-term future as sketched in Section 4, you say that users will download the Obfsproxy Browser Bundle and put in addresses obtained from BridgeDB. Will the bundle still contain any hard-coded addresses by then?
Instead of hacking the bibliography with custom \bibitem, please consider using footnotes for URLs.

We should also get feedback from the people who're actually affected by the planned changes. erinn, chiiph, aagbsn, and ioerror come to mind. Adding them to Cc. What do they think?

Trac:
Cc: nickm to nickm, erinn, chiiph, aagbsn, ioerror

All in all looks good with karsten's comments. I do think expected timeframe should be mentioned for each subsection, or do we stay vague on purpose?

About deployment, didn't we talk about including obfsproxy in TBB by default in the near (tor 0.2.3.x-stable) future? Maybe that should be mentioned. This would, if we did it, require the Vidalia support karsten mentioned.

There's still a bunch of grammar/spelling errors. Is this expected because it's a rough draft or do you want a patch to fix some?

Replying to Sebastian:

I do think expected timeframe should be mentioned for each subsection, or do we stay vague on purpose?

Good idea. No need to stay vague, at least not with respect to the next sponsor deliverable. We promised UPnP (#4567 (moved)) and hope to get BridgeDB integration (#4568 (moved)) done until June 30. We didn't make plans for Vidalia integration until June 30, both client and server side, though I think it would make sense. Anything else is for after June.

Thanks for the comments everyone!

I changed the 25 to 14, and made several changes based on Karsten's ideas. I hope to further improve the English and fix the spelling/grammar mistakes tomorrow or the day after.

I heard that git is good, so I pushed my progress into bug4562 in https://git.gitorious.org/tor-reports/tor-reports.git (https://gitorious.org/tor-reports/tor-reports/commits/bug4562).

Answering to Karsten's review:

Replying to karsten:

Some comments:

The document doesn't have an author name nor contact information. Please consider putting in your name and email address.

Done.

Should Section 2 have its own subsection for saying what changes are required to Vidalia, maybe as new first subsection? If these changes are already made, great, but I think they should be stated in this roadmap. Speaking of Vidalia, are there plans to configure obfsproxy on the server side?

Good idea. I added a section.

In Section 2.1, how will BridgeDB distribute obfuscated bridge addresses? Will users specifically ask for them instead of non-obfuscated bridge addresses, or will BridgeDB include an obfuscated bridge address or two in every response? If there are different transports, will BridgeDB tell you one address per transport, or will the user have to ask for a specific transport? I'm sure there are even smarter questions about possible BridgeDB designs, but I think they should be discussed in Section 2.1 or on Trac and referenced here.

I spoke with Aaron about this. He pretty-much told me that all approaches are quite easy to implement.

He told me that BridgeDB has the concept of each bridge having "characteristics", and that in the near future we will be able to query BridgeDB for specific characteristics.

So, I had in mind that initially we would just give out a couple of obfs2 addresses along with the usual bridge addresses, and then we would progress to a design where the user would be able to query bridgedb for specific transports and whatnot.

Aaron, any comments?

Maybe add a remark that statistics mentioned in Section 2.2 won't be deployed on a 0.2.3.x timeframe.

Sections 2.2 and 2.4 talk about a future that is farther away than 2.1 and 2.3. Would it make sense to have Section 2 talk about the future in 3--6 months and a new Section 3 talk about the future after that? If not, feel free to ignore this suggestion.

Hm, I'm not sure how to give out timeframes. Is it development timeframe? Or deployment timeframe? I'll have to think a bit about this. I hope to do it tomorrow.

In Section 3 you talk about updating obfsproxy on the server side. Are there any plans to have an Obfsproxy Bridge Bundle of some sort? Or will the Tor Bridge Bundle contain obfsproxy by default?

Ha! Very good question. I added a subsection to the User Workflow section for this.

My idea is that in the future (when obfsproxy is mature enough) the Tor Bridge Bundle will contain obfsproxy by default. No one wants to be the operator of a trivially blockable bridge. If you think this is not a good idea, I can remove it from the document.

In the short-term future as sketched in Section 4, you say that users will download the Obfsproxy Browser Bundle and put in addresses obtained from BridgeDB. Will the bundle still contain any hard-coded addresses by then?

I left this vague intentionally. I think we should decide as we go along, depending on how censors respond etc.

Instead of hacking the bibliography with custom \bibitem, please consider using footnotes for URLs.

Good idea. Done.

We should also get feedback from the people who're actually affected by the planned changes. erinn, chiiph, aagbsn, and ioerror come to mind. Adding them to Cc. What do they think?

Replying to asn:

Replying to karsten:

In Section 2.1, how will BridgeDB distribute obfuscated bridge addresses? [...] So, I had in mind that initially we would just give out a couple of obfs2 addresses along with the usual bridge addresses, and then we would progress to a design where the user would be able to query bridgedb for specific transports and whatnot.

Want to add a sentence about that plan to Section 2.2? Or is that too much detail?

Sections 2.2 and 2.4 talk about a future that is farther away than 2.1 and 2.3. Would it make sense to have Section 2 talk about the future in 3--6 months and a new Section 3 talk about the future after that? If not, feel free to ignore this suggestion. Hm, I'm not sure how to give out timeframes. Is it development timeframe? Or deployment timeframe? I'll have to think a bit about this. I hope to do it tomorrow.

I guess deployment timeframe, given that this is a deployment roadmap. Staying vague is fine, but maybe a hint that statistics in 2.3 will take us longer to deploy than NAT punching in 2.4 might be useful.

In Section 3 you talk about updating obfsproxy on the server side. Are there any plans to have an Obfsproxy Bridge Bundle of some sort? Or will the Tor Bridge Bundle contain obfsproxy by default? Ha! Very good question. I added a subsection to the User Workflow section for this.

My idea is that in the future (when obfsproxy is mature enough) the Tor Bridge Bundle will contain obfsproxy by default. No one wants to be the operator of a trivially blockable bridge. If you think this is not a good idea, I can remove it from the document.

Sounds like a fine idea to me. But I'm in no way involved in building packages, so don't count on my opinion here. Just raising the issue.

Instead of hacking the bibliography with custom \bibitem, please consider using footnotes for URLs. Good idea. Done.

I tweaked the footnotes a bit and made a set of other small changes. See the attached Git patches.

Trac:
0001-Tweak-footnotes-a-bit.patch

Trac:
0002-Make-some-minor-changes.patch

Thanks for the patches! I applied both, and also added a paragraph on how we plan to incrementally deploy the BridgeDB integration plan.

Why do you think that that statistics in 2.3 will take us longer to deploy than NAT punching in 2.4? Both features will probably go into 0.2.4.x. I care more about client statistics than NAT punching, so I will try to have client statistics ready, faster than the NAT punching code. Specifically, when #4773 (moved) gets merged, we will get GeoIP client statistics for free.

Grr! Deployment timeframes are hard to pin down.

Replying to asn:

Why do you think that that statistics in 2.3 will take us longer to deploy than NAT punching in 2.4? Both features will probably go into 0.2.4.x. I care more about client statistics than NAT punching, so I will try to have client statistics ready, faster than the NAT punching code. Specifically, when #4773 (moved) gets merged, we will get GeoIP client statistics for free.

Ah, I didn't know that you were planning to implement statistics before end of June, which is when we promised the NAT-punching code. And yes, I also think that both features will go into 0.2.4.x.

Very much looking forward to statistics support!