On Sat, Jul 26, 2014 at 5:30 PM, David Fifield <[email protected]> wrote:
> On Sat, Jul 26, 2014 at 03:08:38PM +0100, Kevin P Dyer wrote: > > Are there any roadblocks that prevent us from doing the following? > > > > 1. Remove the hard-coded bridge_prefs.js in the TBB. > > 2. Set meek as the default pluggable transport in the TBB. > > 3. Use meek to acquire an up-to-date bridge_prefs.js from, say, > > torproject.org. > > 4. Use the information from the acquired bridge_prefs.js to connect to > Tor as > > normal. > > Flash proxy does something similar when it starts up and does > rendezvous. The helper program flashproxy-reg-appspot uses the meek > domain fronting trick (but simpler) to find out its own IP and send it > to the facilitator. You wouldn't actually need to fire up meek; you > could just front an HTTPS GET request for the document you need. > > > https://gitweb.torproject.org/flashproxy.git/blob/HEAD:/doc/flashproxy-reg-appspot.1.txt > > https://gitweb.torproject.org/flashproxy.git/blob/HEAD:/flashproxy-reg-appspot > > I don't know that you'd want to rely on it entirely--meek over App > Engine doesn't work in China and we haven't deployed any other backends > yet. Is App Engine blocked in China? > Nothing is ever going to be as reliable as a file you already have > on disk. > We could have a file on disk as a fallback option, right? > I supose this is because you want to make FTE bridges dynamic? > Exactly. -Kevin
_______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
