[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #16756 [Pluggable transport]: Formalize and document what it takes for a PT to get deployed.
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs