[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #4562 [Pluggable transport]: Write a pluggable transport deployment roadmap
#4562: Write a pluggable transport deployment roadmap
---------------------------------+------------------------------------------
Reporter: karsten | Owner: asn
Type: project | Status: needs_revision
Priority: normal | Milestone: Sponsor G: March 31, 2012
Component: Pluggable transport | Version:
Keywords: | Parent:
Points: | Actualpoints:
---------------------------------+------------------------------------------
Comment(by asn):
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 [comment:4 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?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4562#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs