<commit_before>Design of Flash proxies

0. Problem statement

  Provide access to the Tor network for users behind a restrictive
  firewall that blocks direct access to all Tor relays and bridges.

1. Overview and background

  We assume the existence of an adversary powerful enough to enumerate
  and block all public and non-public (bridge) relays. We assume that
  there is a relatively unrestricted portion of the Internet, addresses
  in which can both connect to public Tor relays and receive connections
  from restricted users.

  A browser-based proxy (Flash proxy), running in a web page in the
  unrestricted Internet, proxies connections between the restricted
  Internet and the Tor network. These proxies are expected to be
  temporary and short-lived, but their number will be great enough that
  they can't all be blocked effectively.

  The implementation of a browser-based proxy using Adobe Flash or other
  networking technologies is complicated by restrictions that prevent it
  being a straightforward proxy. Chief among these is the lack of
  listening sockets. Flash and, for example, WebSockets, can only
  initiate outgoing connections, not receive incoming ones. The Flash
  proxy can only connect to external hosts by connecting directly to
  them. The other significant restriction is that the proxy cannot

2. Components

  Conceptually, each Flash proxy is nothing more than a simple proxy,
  which accepts connections from a client and forwards data to a server.
  But because of the limited networking facilities available to an
  in-browser application, several other pieces are needed.

  1. Tor client: Is just ordinary Tor with a special configuration to
     allow it to connect through a Flash proxy. It advertises its need
     for a connection the the facilitator, and communicates with the
     Flash proxy through the connector.
  2. Connector: Runs on the same computer as the Tor client. It opens
     one socket to the Internet and another to localhost. It waits for a
     connection on both sockets, then starts proxying data between them.
     The connector speaks SOCKS on the localhost side so that Tor can
     connect to it using the Socks4Proxy configuration option. On
     startup, the connector informs the facilitator that it is waiting
     for a connection.
  3. Flash proxy: Runs in someone's browser, in an uncensored region of<commit_msg>Finish unfinished paragraph about Flash proxy socket limitations.<commit_after>Design of Flash proxies

0. Problem statement

  Provide access to the Tor network for users behind a restrictive
  firewall that blocks direct access to all Tor relays and bridges.

1. Overview and background

  We assume the existence of an adversary powerful enough to enumerate
  and block all public and non-public (bridge) relays. We assume that
  there is a relatively unrestricted portion of the Internet, addresses
  in which can both connect to public Tor relays and receive connections
  from restricted users.

  A browser-based proxy (Flash proxy), running in a web page in the
  unrestricted Internet, proxies connections between the restricted
  Internet and the Tor network. These proxies are expected to be
  temporary and short-lived, but their number will be great enough that
  they can't all be blocked effectively.

  The implementation of a browser-based proxy using Adobe Flash or other
  networking technologies is complicated by restrictions that prevent it
  being a straightforward proxy. Chief among these is the lack of
  listening sockets. Flash and, for example, WebSockets, can only
  initiate outgoing connections, not receive incoming ones. The Flash
  proxy can only connect to external hosts by connecting directly to
  them. The other significant restriction is that the proxy cannot
  connect to just any destination: Adobe Flash player requires the
  server to provide a "crossdomain policy" allowing access. A third, but
  less important, restriction is that browser-based networking does not
  provide low-level socket access such as control of source address.

2. Components

  Conceptually, each Flash proxy is nothing more than a simple proxy,
  which accepts connections from a client and forwards data to a server.
  But because of the limited networking facilities available to an
  in-browser application, several other pieces are needed.

  1. Tor client: Is just ordinary Tor with a special configuration to
     allow it to connect through a Flash proxy. It advertises its need
     for a connection the the facilitator, and communicates with the
     Flash proxy through the connector.
  2. Connector: Runs on the same computer as the Tor client. It opens
     one socket to the Internet and another to localhost. It waits for a
     connection on both sockets, then starts proxying data between them.
     The connector speaks SOCKS on the localhost side so that Tor can
     connect to it using the Socks4Proxy configuration option. On
     startup, the connector informs the facilitator that it is waiting
     for a connection.
  3. Flash proxy: Runs in someone's browser, in an uncensored region of
{'fraction_non_alphanumeric': 0.02374927000194666, 'fraction_numerical': 0.002725326065797158, 'mean_word_length': 3.897998093422307, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6142931', 'n_tokens_mistral': 1205, 'n_tokens_neox': 1137, 'n_words': 768}