Can't the censor just block the facilitator?
The short summary is 1) yes, the censor can block the facilitator, and 2) it doesn't matter. Our design assumes that the censor has permanently blocked communication with the facilitator; it is a design requirement that flash proxies continue to work in this situation. (See Sections 3.1 and 6 in the paper.) We don't rely on having multiple facilitators, nor on having secret ways of distributing their addresses. Assume that there is only one facilitator, at an IP address that doesn't change, blacklisted by the censor.
The way we get around this is that step 1, where the client registers with the facilitator, is a special rendezvous step that does not communicate directly with the facilitator, designed to be covert and very hard to block. The way this works in practice is that the flash proxy client transport plugin makes a TLS connection to Gmail, and sends an encrypted email from an anonymous address (nobody@localhost) to a special facilitator registration address. The facilitator checks this mailbox periodically, decrypts the messages, and inserts the registrations they contain.
The result is that anyone who can send email to a Gmail address can do rendezvous, even if the facilitator is blocked. Of course, censors have been known to censor Gmail, so this solution doesn't work for everyone. That's why we are working on more rendezvous techniques, for example #7559.
This idea is a common one in computer security: we turn a big problem into a small one. For example, cryptography turns the big problem of how to transmit a file securely, into the small problem of how to transmit a key securely. We turn the big problem of making all network communication covert and resistant to IP blocking, into the small problem of making one short rendezvous message covert and resistant to IP blocking. The smaller problem often additionally has relaxed constraints that make it easier to solve. In the cryptography case, you can transmit the key ahead of time when you have a secure channel. In the flash proxy case, the rendezvous message is one-way, low-bandwidth, and infrequent. While you can't do your web browsing over a write-only email channel, it's good enough for rendezvous, and the flash proxy takes care of the rest.
What's with the funny embed link? Isn't src="//crypto.stanford.edu/..." missing an http or https?
The link without http or https is sometimes called a scheme-relative or protocol-relative URL. It means that if the linking page uses plain HTTP, the URL will also use plain HTTP; and if the linking page uses HTTPS, the URL also uses HTTPS.
Wouldn't it be better to always use HTTPS? Yes, except that for technical reasons the proxy badge does not work when the enclosing page uses HTTPS. This is because pages using HTTPS are not allowed to make unencrypted WebSocket connections. If you are looking at the page https:crypto.stanford.edu/flashproxy/, the badge will appear to be running, but it will in fact be non-functional, incapable of making any WebSocket connections. The reason we must make unencrypted WebSocket connections is that we are connecting to clients who don't have CA-issued certificates.
Then why not always use HTTP? If we did this, it would cause mixed-content warnings for embedding sites that use HTTPS. To avoid breaking those sites, the badge appears, it just doesn't work. Please let us know if you have a nicer solution to this problem.