[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] Please try and test bundles with the "meek" pluggable transport (3.6.2-meek-1)

Even if the idea of hidding the SSL/TLS destination is interesting (reminds me [1] somewhere) I find the concepts/implementation a bit strange.

In the list of "ideas" I would suggest (not related to the reflector principles directly but related to something that might make the connection to Tor nodes more difficult to censor, ie using a localhost talking the browser language):

- like [2], that's a background OP process connecting to the Tor nodes using ws (+SSL/TLS), supporting the socks interface to undertake the requests from the browser - or [2] in the future that will talk webrtc too, the intent for [2] with webrtc will be to discuss with browsers (which are "Tor" nodes too for our project) but it could talk to usual Tor nodes if they understand webrtc (see [3] for a short explaination, unless what is stated at the begining of the thread the signaling servers are not required as highlighted at the end)



[1] http://ianonym.com/project2.pdf
[2] https://github.com/Ayms/node-Tor/tree/master/install#peersm-client-installation [3] http://librelist.com/browser//webp2p/2014/2/20/serverless-peersm-and-webrtc/

Le 12/06/2014 06:44, David Fifield a écrit :
On Wed, Jun 11, 2014 at 07:57:07PM -0700, David Fifield wrote:
I picked a good day to announce this :) Google App Engine's URLFetch
service, which is the link between Google and meek's Tor bridge, has
been not working for about the last hour (since 18:30 PDT).

It seems to be working again.


"We have identified the issue affecting Google App Engine UrlFetch
service and latency is returning to normal. We will provide another
update by 22:00 Pacific."

David Fifield

Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to