PT Criteria
Things we need:
- TODO: One set of criteria for what a good pluggable transport should be.
- TODO: One set of criteria for getting a PT into the Tor Browser Bundle.
Existing Documents:
- TICKET: Formalize and document what it takes for a PT to get deployed. https://trac.torproject.org/projects/tor/ticket/16756
- Pluggable Transport Evaluation Criteria https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/PTEvaluationCriteria)
- For historical reference, the FTE review and deployment process is documented in #10362 (moved).
Before submitting a PT for inclusion into TBB a developer...
- MUST be able to be built the PT deterministically
- MUST have had the PT in TBB alpha for [X] period of time
- SHOULD build a patch for TBB and provide the patched TBB for review along with the PT for testing
For inclusion into TBB a PT...
- MUST offer a different feature than existing PT's.
- MUST have code that is well documented and maintainable by a party working without the support of the original developers
- MUST be audited by one of the existing core Tor PT developers
- therefore it MUST be very compelling, or provide funding, so that auditors will audit your code.
- The time it takes to audit code is considerable.
- e.g. Stegotorus
- We need to not ignore the costs on our side for doing the evaluations.
- The time it takes to audit code is considerable.
- therefore it MUST be very compelling, or provide funding, so that auditors will audit your code.
- MUST have an identified process and channels for handling support for users experiencing blocking or other errors that are PT related
- SHOULD have a well thought out deployment plan (e.g. plan for recruiting people who will run the specified PT on Tor Bridges)
- MUST be written in a reasonable language - e.g. MUMPS :) -
The Process for getting a PT included into TBB is to...
- A0) DON'T email individual developers
- A1) Send an email to tor-dev or create a trac-ticket announcing your intent to create a PT
- A2) A person should communicate to IRC during meeting times to announce their intent.
- TODO someone tell Nick that he inherited PT additions in the Tor Dev Meeting.
- B) TODO: Now what? PT-vangelist or interested Dev responds and says "read and respond to roadmap" and then provide [X] things in [Y] format to location [Z].
- C) TODO: Review happens here?
- D) TODO: It is included into TBB alpha here?
- E) TODO: Changes from Alpha deployment here?
- F) TODO: It is rolled out to TBB stable here?
The things that we need to do to ensure that outside developers have the greatest chance of success are...
- Create a website/page that tells you the steps involved in developing and deploying a PT
- Create a way for devs to find the website (See: PT-vangelist)
- Rewrite the PT spec to be less Tor specific and fully comprehensive
- TODO Add bootstrapping information to website and wiki
- In the short term "If you are interested f!**k off... but, try the wiki."
- In the long term "Communicate that there is a team and steer people towards the mailing list because it is permanent and asynchronous."
The process for removing a PT from TBB is
- We need a process & criteria for evaluating when a PT will get removed from Tor.
- Drop a PT when it is broken? But it is rarely broken in all countries just because broken in one.
- Drop when it takes up space? Two notions of space: package size, and UI/UX bloat.
- Drop when user count drops below X? (If X > 0, where should the line be drawn?)
- Drop when something similar but "better" exists and is officially deployed? (Eg:
obfs(N+1)replacingobfsN)