Roger Dingledine:
Whether these various "look, no hands" punching tools and tricks can be done using only websockets on the remote side is a great question for somebody to answer.
By the way, I found it in their design paper.
Quote:
The fact that clients must not be behind NAT is an impediment to usability. A NAT traversal mechanism that works within our threat model would be a great benefit. Typical NAT traversal technologies, such as STUN (Session Traversal Utilities for NAT) [21] and RTMFP (Real Time Media Flow Protocol) [22], rely on a stable third-party server to facilitate the connection, which is trivially de- feated by the censor blocking the third party by IP address. (Also we believe it is better to avoid informing a third party of each flash proxy connection if it can be avoided.) Tricks involving low-level packet manipulation, for example pw- nat [23], are not available to browser sockets. Ideally, any NAT traversal scheme will not require both the client and the proxy to know each other’s IP address, so that facilitator registration can remain unidirectional. New technologies like WebRTC [24] may fill this need in the future, if they become sufficiently popular that flash proxies’ use of them does not stand out as unusual.