[tor-bugs] #16756 [Pluggable transport]: Formalize and document what it takes for a PT to get deployed.

[Tor Bug Tracker & Wiki]

#16756: Formalize and document what it takes for a PT to get deployed.
-------------------------------------+----------------------
     Reporter:  yawning              |      Owner:  yawning
         Type:  task                 |     Status:  new
     Priority:  normal               |  Milestone:
    Component:  Pluggable transport  |    Version:
   Resolution:                       |   Keywords:  SponsorS
Actual Points:                       |  Parent ID:
       Points:                       |
-------------------------------------+----------------------

Comment (by mikeperry):

 I am deeply wary of the fast-and-loose flashproxy model for lots of
 reasons. If the introducer can't manage to authenticate itself, and it
 can't tell you how to authenticate your traffic to the flashproxy bridges
 it gives you, then long-term I am against it and anything that behaves
 like it. In fact, I would be in favor of killing it until we can fix these
 issues, especially if we're thinking of trimming down the supported PT
 list anyway. I really, really don't want a future WebRTC-based version of
 flashproxy to end up as such an unauthenticated free-for-all mess, for
 example.

 I agree with the rest of your comments. For point 13, we could make the
 phrasing focused on requiring the consent of the person/entity who is
 ultimately accepting PT connections (not counting passive routers and
 intermediary middleboxes). That may cover the issues you're concerned
 about? It would also cover the related case of "ZOMG! I can deploy ONE
 MEEELION bridges if I pay this sketchy ad network $50 to turn a ton of
 random browsers into WebRTC bridges!!"

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16756#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online