Re: [tor-dev] Proposals should have reviews. Let's make sure that happens. Here's a schedule.
On 18 Jan (07:13:36), Tim Wilson-Brown - teor wrote: > > > On 15 Jan 2016, at 03:31, David Goulet wrote: > > > >> Friday January 29: 8:30 am eastern (1330 UTC) > >> > >> Prop#252: Single Onion Services [DRAFT] > >> Prop#260: Rendezvous Single Onion Services [DRAFT] > >> Prop#246: Merging Hidden Service Directories and Introduction Points > >> [OPEN] > > > > Fosdem is the next day so I'll be at a remote location called Brussels > > for this meeting for which I doubt I'll be able to attend. This one is > > about onion service proposals and I would really want to discuss those > > with others so moving this one before or after Febuary 2nd would be > > great for me. If impossible, I'll read the notes I guess :). > > This is at half past midnight on a Saturday for me, can we move it to time > somewhere in 4pm - 8pm eastern (2100 - 0100 UTC)? Hi Nick! Gentle bump on this one. teor and I won't be able to attend. At the very least, teor should be able to attend since he is very familiar with (R)SOS. Also, prop#246 is officially back in Needs-Research status. See proposal text for the update and reference on why. Thanks! David > > Thanks > > Tim > > Tim Wilson-Brown (teor) > > teor2345 at gmail dot com > PGP 968F094B > > teor at blah dot im > OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F > > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Release: obfs4proxy-0.0.6
Hello all, I just tagged obfs4proxy-0.0.6. There aren't many significant changes, and the internal changes primarily affect the client side initialization, so those of you that are perfectly content with obfs4proxy-0.0.5 can continue to use the existing version without issue. Tarball/Signature: https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.6.tar.xz https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.6.tar.xz.asc Changes in version 0.0.6 - 2016-01-25: - Delay transport factory initialization till after logging has been initialized. - Add a meek client implementation (WARNING: Does not support using a helper to normalize TLS signatures). The brave people that want to use it can do so as the "meek_lite" transport, with identical bridge lines to the real meek-client. This means "It's blatantly obvious that you're using a HTTPS client written in Go because the ClientHello is rather distinctive". The benefit is that it is a lot easier to package than meek-client + the external helper, and this can probably save binary size on things like Android. An example bridge line would be: Bridge meek_lite 0.0.2.0:1 url=https://meek-reflect.appspot.com/ front=www.google.com It has received moderate testing when I was on a business trip, and appears to function as intended, given the design constraints. There are minor internal API changes (which caused issues delaying the release) motivated by "meek's behavior is unlike most other transports" but I expect such things to be straight forward to those that actually hack on the code. Thanks to the person on Github for filing a pull request which saved me time debugging. Regards, -- Yawning Angel pgp65xew5gP_U.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Release: obfs4proxy-0.0.6
On Mon, Jan 25, 2016, at 09:38 AM, Yawning Angel wrote: >benefit is that it is a lot easier to package than meek-client + the >external helper, and this can probably save binary size on things >like Android. Yes, I've been waiting for this. It is especially useful since we will be including both ARM and x86 builds shortly, so the size of PT storage in the app is already going to double. Thanks for the continued hard work on this. +n ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Introducing Snowflake (webrtc pt)
Hi all, Snowflake is a webrtc pluggable transport inspired by flashproxy. (https://gitweb.torproject.org/pluggable-transports/snowflake.git) Arlo, David, and I have made lots of progress on it lately, and it now appears to have reached minimum viability. The following should result in a 100% bootstrap over WebRTC: ``` git clone https://git.torproject.org/pluggable-transports/snowflake.git cd snowflake/client go get go build tor -f torrc ``` In case you have a moment, it'd be cool if you tried it out and let us know whether it works for you. I'd really appreciate hearing about all the thoughts / concerns / issues before we move forward. -- More info -- Q: What are the benefits of this PT compared with other PTs? Snowflake combines the advantages of flashproxy and meek. Primarily: - It has the convenience of Meek, but can support magnitudes more users with negligible CDN costs. (Domain fronting only used for brief signalling / NAT-piercing to setup P2P webrtc which handles the actual traffic) - Arbitrarily high numbers of volunteer proxies are possible like in flashproxy, but NATs are no longer a usability barrier - no need for manual port forwarding! Q: How does it work? 1. Volunteers visit websites which host the "snowflake" proxy. (just like flashproxy) 2. Tor clients automatically find available browser proxies over the domain fronted signaling channel. 3. Tor client and browser proxy establish a WebRTC peer connection. 4. Proxy connects to some relay. 5. Tor occurs. Q: Why is it called Snowflake? There's a bunch of "ICE" negotiation happening for WebRTC, and it also involves a great abundance of ephemeral and short-lived (and special!) volunteer proxies... Anyhow, if Snowflake seems like it would be useful / desired here, it would be awesome if we had more help getting it stable, polished, audited, deployable, etc... Plenty of work to do! <3, ~serene P.S. Make sure you're using a recent version of Go (1.5+) P.P.S. The repo is available in these locations: - https://gitweb.torproject.org/pluggable-transports/snowflake.git - https://github.com/keroserene/snowflake ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Introducing Snowflake (webrtc pt)
On Mon, 25 Jan 2016 14:34:42 -0800 Serene wrote: > Anyhow, if Snowflake seems like it would be useful / desired here, it > would be awesome if we had more help getting it stable, polished, > audited, deployable, etc... Neat. Yes, this will be useful. What are your plans for getting https://github.com/keroserene/go-webrtc to build completely in a deterministic manner? The several hours isn't per platform right? (The "easy way" is not going to cut it for distribution). What are your plans for actually getting the server side to scale well? Since you're using cgo you will run into Really Interesting behavior wrt OS threads as you try to increase concurrency. Regards, -- Yawning Angel pgpLU1pLkbv_I.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Introducing Snowflake (webrtc pt)
On Mon, Jan 25, 2016 at 2:53 PM, Yawning Angel wrote: > What are your plans for getting https://github.com/keroserene/go-webrtc > to build completely in a deterministic manner? The several hours isn't > per platform right? (The "easy way" is not going to cut it for > distribution). Totally. Building native webrtc requires google's depot_tools, and `gclient sync` takes a long time (over an hour on my machine) because chromium. Per platform takes a few minutes. The plan is to provide a build script which: - gclient syncs to some known & tested commit hash on a release branch. - Apply a patch to remove unnecessary video/audio webrtc media API stuff (only datachannels are needed for our use-case) This will also greatly reduce the archive size. - Build the archive we need using a custom gyp or ninja file. - Concat and copy the archive over for go-webrtc Does that sound like a reasonable deterministic build? > What are your plans for actually getting the server side to scale > well? Since you're using cgo you will run into Really Interesting > behavior wrt OS threads as you try to increase concurrency. Right now, the server side is the same websocket relay from flashproxy. Webrtc currently happens just between the client and browser proxy - this already yields all the benefits listed above (as we assume the volunteer proxy has no problem connecting to Tor) However, it might be worth having webrtc on both sides. We already have prepared a webrtc server plugin, which the client plugin has successfully connected to directly. To use a snowflake proxy in between would require establishing two separate webrtc peerconnections per circuit. Maybe that's worth doing - but I'm not sure about the plan there, if we do decide to go that route. Best, ~s ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Introducing Snowflake (webrtc pt)
> What are your plans for getting https://github.com/keroserene/go-webrtc
> to build completely in a deterministic manner?
Just opened an issue, so that's about as far as we are
in the planning stages.
https://github.com/keroserene/go-webrtc/issues/29
> The several hours isn't
> per platform right? (The "easy way" is not going to cut it for
> distribution).
No, that's just to do the `gclient sync`.
Building itself is only ~10 mins on my machine.
>
> What are your plans for actually getting the server side to scale
> well? Since you're using cgo you will run into Really Interesting
> behavior wrt OS threads as you try to increase concurrency.
The proxy ("snowflake") to server connection is using the currently
deployed WebSocket bridge. The WebRTC part is only to avoid the
incoming connecting to the client. I don't think the current websocket
server pt uses cgo, right? It's a native implementation. But I should
look ...
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Introducing Snowflake (webrtc pt)
On Mon, 25 Jan 2016 15:32:55 -0800 Serene wrote: [snip] > > What are your plans for actually getting the server side to scale > > well? Since you're using cgo you will run into Really Interesting > > behavior wrt OS threads as you try to increase concurrency. > > Right now, the server side is the same websocket relay from > flashproxy. Webrtc currently happens just between the client and > browser proxy - this already yields all the benefits listed above (as > we assume the volunteer proxy has no problem connecting to Tor) This seems sensible. > However, it might be worth having webrtc on both sides. We already > have prepared a webrtc server plugin, which the client plugin has > successfully connected to directly. To use a snowflake proxy in > between would require establishing two separate webrtc peerconnections > per circuit. Maybe that's worth doing - but I'm not sure about the > plan there, if we do decide to go that route. Ah that's what that was. If you don't use it then, you won't have lots of misery fighting with cgo's quirks. Regards, -- Yawning Angel pgpH3WhBnsvR9.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Introducing Snowflake (webrtc pt)
> On 26 Jan 2016, at 09:34, Serene wrote: > > Hi all, > > Snowflake is a webrtc pluggable transport inspired by flashproxy. > (https://gitweb.torproject.org/pluggable-transports/snowflake.git) > Arlo, David, and I have made lots of progress on it lately, and it now > appears to have reached minimum viability. > > The following should result in a 100% bootstrap over WebRTC: > ``` > git clone https://git.torproject.org/pluggable-transports/snowflake.git > cd snowflake/client > go get > go build > tor -f torrc > ``` > In case you have a moment, it'd be cool if you tried it out and let us > know whether it works for you. I'd really appreciate hearing about > all the thoughts / concerns / issues before we move forward. I get about this far on OS X, I'm behind a NAT: Jan 26 12:25:50.063 [notice] Tor v0.2.7.6 running on Darwin with Libevent 2.0.22-stable, OpenSSL 1.0.2e and Zlib 1.2.8. … Jan 26 12:25:50.071 [notice] Opening Socks listener on 127.0.0.1:9050 Jan 26 12:25:50.000 [notice] Parsing GEOIP IPv4 file /opt/local/share/tor/geoip. Jan 26 12:25:50.000 [notice] Parsing GEOIP IPv6 file /opt/local/share/tor/geoip6. Jan 26 12:25:50.000 [notice] Bootstrapped 0%: Starting Jan 26 12:25:50.000 [notice] Delaying directory fetches: No running bridges Jan 26 12:25:52.000 [notice] Bootstrapped 5%: Connecting to directory server Jan 26 12:25:52.000 [notice] Bootstrapped 10%: Finishing handshake with directory server Any hints? Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Introducing Snowflake (webrtc pt)
> I get about this far on OS X, I'm behind a NAT: > > Jan 26 12:25:50.063 [notice] Tor v0.2.7.6 running on Darwin with Libevent > 2.0.22-stable, OpenSSL 1.0.2e and Zlib 1.2.8. > … > Jan 26 12:25:50.071 [notice] Opening Socks listener on 127.0.0.1:9050 > Jan 26 12:25:50.000 [notice] Parsing GEOIP IPv4 file > /opt/local/share/tor/geoip. > Jan 26 12:25:50.000 [notice] Parsing GEOIP IPv6 file > /opt/local/share/tor/geoip6. > Jan 26 12:25:50.000 [notice] Bootstrapped 0%: Starting > Jan 26 12:25:50.000 [notice] Delaying directory fetches: No running bridges > Jan 26 12:25:52.000 [notice] Bootstrapped 5%: Connecting to directory server > Jan 26 12:25:52.000 [notice] Bootstrapped 10%: Finishing handshake with > directory server > > Any hints? Can you paste a sanitized version of your snowflake.log (same dir as client) so we can see how far it gets? The pt should make a domain-fronted request to, https://snowflake-reg.appspot.com/ with an sdp offer and receive an answer, then try to negotiate a session with a snowflake (proxy) using, stun:stun.l.google.com:19302 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Introducing Snowflake (webrtc pt)
> On 26 Jan 2016, at 12:47, Arlo Breault wrote:
>
>
>> I get about this far on OS X, I'm behind a NAT:
>>
>> Jan 26 12:25:50.063 [notice] Tor v0.2.7.6 running on Darwin with Libevent
>> 2.0.22-stable, OpenSSL 1.0.2e and Zlib 1.2.8.
>> …
>> Jan 26 12:25:50.071 [notice] Opening Socks listener on 127.0.0.1:9050
>> Jan 26 12:25:50.000 [notice] Parsing GEOIP IPv4 file
>> /opt/local/share/tor/geoip.
>> Jan 26 12:25:50.000 [notice] Parsing GEOIP IPv6 file
>> /opt/local/share/tor/geoip6.
>> Jan 26 12:25:50.000 [notice] Bootstrapped 0%: Starting
>> Jan 26 12:25:50.000 [notice] Delaying directory fetches: No running bridges
>> Jan 26 12:25:52.000 [notice] Bootstrapped 5%: Connecting to directory server
>> Jan 26 12:25:52.000 [notice] Bootstrapped 10%: Finishing handshake with
>> directory server
>>
>> Any hints?
>
> Can you paste a sanitized version of your snowflake.log
> (same dir as client) so we can see how far it gets?
>
> The pt should make a domain-fronted request to,
> https://snowflake-reg.appspot.com/
> with an sdp offer and receive an answer,
> then try to negotiate a session with a snowflake (proxy) using,
> stun:stun.l.google.com:19302
I'm connected using dual-stack IPv4 and IPv6, but I'm not sure if that's the
issue.
-
2016/01/26 12:23:15 starting
2016/01/26 12:23:18 OnNegotiationNeeded
2016/01/26 12:23:18 OnIceCandidate {"candidate":"candidate:4081377822 1 udp
2122262783 2001:... 49215 typ host generation 0 ufrag
MhDVA7+9JyUZKlqY","sdpMid":"data","sdpMLineIndex":0}
2016/01/26 12:23:18 OnIceCandidate {"candidate":"candidate:44203497 1 udp
2122194687 10…. 60053 typ host generation 0 ufrag
MhDVA7+9JyUZKlqY","sdpMid":"data","sdpMLineIndex":0}
2016/01/26 12:23:18 OnIceCandidate {"candidate":"candidate:3183943406 1 tcp
1518283007 2001:... 64926 typ host tcptype passive generation 0 ufrag
MhDVA7+9JyUZKlqY","sdpMid":"data","sdpMLineIndex":0}
2016/01/26 12:23:18 OnIceCandidate {"candidate":"candidate:1277264153 1 tcp
1518214911 10…. 64927 typ host tcptype passive generation 0 ufrag
MhDVA7+9JyUZKlqY","sdpMid":"data","sdpMLineIndex":0}
2016/01/26 12:23:21 OnIceCandidate {"candidate":"candidate:1036294592 1 udp
1685987071 180... 60053 typ srflx raddr 10…. rport 60053 generation 0 ufrag
MhDVA7+9JyUZKlqY","sdpMid":"data","sdpMLineIndex":0}
2016/01/26 12:23:21 OnIceComplete
2016/01/26 12:23:21
{"type":"offer","sdp":"v=0\r\no=- 8307480261278365747 2 IN IP4
127.0.0.1\r\ns=-\r\nt=0 0\r\na=msid-semantic: WMS\r\nm=application 60053
DTLS/SCTP 5000\r\nc=IN IP4 180….\r\na=candidate:4081377822 1 udp 2122262783
2001:... 49215 typ host generation 0\r\na=candidate:44203497 1 udp 2122194687
10…. 60053 typ host generation 0\r\na=candidate:3183943406 1 tcp 1518283007
2001:... 64926 typ host tcptype passive generation 0\r\na=candidate:1277264153
1 tcp 1518214911 10…. 64927 typ host tcptype passive generation
0\r\na=candidate:1036294592 1 udp 1685987071 180…. 60053 typ srflx raddr 10….
rport 60053 generation
0\r\na=ice-ufrag:MhDVA7+9JyUZKlqY\r\na=ice-pwd:8P3MROhYGYJJ6PBD4sxh5Hs6\r\na=fingerprint:sha-256
6A:2F:9D:5D:DF:83:9C:0A:2F:73:CF:1E:2D:AF:FF:F4:05:08:C8:C5:30:37:1C:A0:CE:C8:C6:1A:D0:E0:12:44\r\na=setup:actpass\r\na=mid:data\r\na=sctpmap:5000
webrtc-datachannel 1024\r\n"}
2016/01/26 12:23:21
2016/01/26 12:23:21 waiting for answer
2016/01/26 12:23:21 Sending offer via meek channel...
Target URL: https://snowflake-reg.appspot.com/
Front URL: www.google.com
2016/01/26 12:23:25 MeekChannel Response:
200 OK
2016/01/26 12:23:25 Received Answer:
v=0
o=- 1195921414501541321 2 IN IP4 127.0.0.1
s=-
t=0 0
a=msid-semantic: WMS
m=application 48952 DTLS/SCTP 5000
c=IN IP4 199.241.201.138
b=AS:30
a=candidate:2885715399 1 udp 2122260223 192.168…. 48952 typ host generation 0
a=candidate:3800267063 1 tcp 1518280447 192.168…. 0 typ host tcptype active
generation 0
a=candidate:759726963 1 udp 1686052607 199... 48952 typ srflx raddr 192.168….
rport 48952 generation 0
a=ice-ufrag:gW3Squmad22xQeoQ
a=ice-pwd:OAGHWixl0ZICWg2JYTXOri3W
a=fingerprint:sha-256
A5:1A:FC:85:52:BE:D6:68:08:52:BE:66:B7:84:08:45:0F:63:47:70:1E:4F:E1:7D:1A:EC:67:47:D4:74:D3:07
a=setup:active
a=mid:data
a=sctpmap:5000 webrtc-datachannel 1024
2016/01/26 12:25:48 WebRTC: interrupted
-
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Fwd: Orbot v15.1.0-RC-4
Orbot update with new built-in bridges (currently using the TBB default list, randomly shuffled!) and some other small fixes for the user interface, reproducible builds, and VPN feature. - Original message - From: Nathan of Guardian To: guardian-...@lists.mayfirst.org Subject: Orbot v15.1.0-RC-4 Date: Mon, 25 Jan 2016 22:48:01 -0500 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Fixes based on feedback from our RC-2 release this will be up on Play and F-Droid shortly, and from the link below right now. /** 15.1.0-RC-4 / 25-January-2016 / 80491ea95bd62346bf3f3a579d3302dbd84f4ca9 **/ APK: https://guardianproject.info/releases/Orbot-v15.1.0-RC-4.apk SIG: https://guardianproject.info/releases/Orbot-v15.1.0-RC-4.apk.asc Improve Bridge selection to support built-in default bridges * c235e3e tweak the string about bridges a little bit * 2a72814 choose up to 2 bridges from default list randomly * 1dbe5ea make bridge allocation shuffle randomly to distribute load inspired by this work: https://trac.torproject.org/projects/tor/tic * cf1a644 add support for loading default bridges from asset file VPN mode now uses Google's DNS (tunneled through Tor) as default * 9af00fe change VPN mode DNS to use Google's 8.8.8.8 Other UI fixes * ba83559 this should be kbps in fact * ab8709d add orfox icon to replace orweb * 6eb0a93 improvements to Locale changing in app * 0669add re-add appcompat, update to latest, move to Android 23 to build - this is required for latest appcompat, and to address the bu * c05d8e7 remove appcompat, and just support support-v4 Fix our stpcpy implementation to ensure no buffer overruns * 4913b0c better implementation of stpcpy for pre-Android 21 NDK Make the build process better and more reproduceable * 735b298 make-release-build: remove faketime from `ant release` * 461e35d make-release-build: freeze time when running ndk-build * 5c86b5c make-release-build: make sure ndk-build can be found * 58d53ea make-release-build: use strip-nondeterminism to get reproducible build * 5ce1f5f make-release-build: make sure tag signers exist before verifying tags * 72eab39 build jtorctl directly, using a symlink to point to its source code * a6ac016 use symlinks to provide alternate folders for Hebrew and Indonesian * 5fb4e9b update ndk-builds to NDK 4.8 toolchain - -- Nathan of Guardian nat...@guardianproject.info - -- Nathan of Guardian nat...@guardianproject.info -BEGIN PGP SIGNATURE- Version: Mailvelope v1.3.4 Comment: https://www.mailvelope.com wsFcBAEBCAAQBQJWpuxcCRCoARg+abN6qQAABa8P/2AlGCzBOBWhb4rVTvfE 64af8Pw031oJyyFDvtlUeETS1Ct95Zz7prP41ywhItPi/6eLCTwkbcbDA+Zl xDK6eSy6NhyMgh2qrC3US45HvQGjSCA7496IM5T3lL71wEL71sxAIaPh2abP 1akDEiXiJTnRUqFGui0aQkt0rJKQ0GShqJXmDM6qvuMCoiJSJ/ehc6Rnkyam 3/m4j5+IZ5JNpPKPDFjmW5cNFSDr+11SSdWlzjC9QfE8Ebo0rceMgpFASqH+ alzl6dB7y2rA+QeQcFQfwTlckKELq/cNofruV4UYmEIIlt/3dPZkIoIPlxBT i/ozTkmSPyEUurnxmAJQMVhergN/0WzGOWST5ceLABjjuVsoVrCZ7ai4eKiX M2zHxPQdjeLnc1HG5IXYLQcABJ9j9ol84oIH4VfcMPBCSjb205S42ChBx8Tm 9LGSSkn1i7JmVR2BaXaxmhbgoU5X+abumy3fH2uwDS5WCMDAExVw43sb8qM9 pGbDxK/wYd4aBaYZQK9VO7nA48eiv7yIw7uoKOhA7JFOnLg8he0DcngikCIx VNEqaO231Kgj1kN8Uc8+ombelRxb++997gnWfqE2ZHsEt3BpRpSAephJMJyq pxOeW/0tQL860oObACLjIp9xZ5FecZPWB4QqDEBRdOtT4MsgjDRP/Wty8Rzt UF2G =9Fk9 -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Introducing Snowflake (webrtc pt)
On Mon, Jan 25, 2016 at 02:34:42PM -0800, Serene wrote: > Snowflake is a webrtc pluggable transport inspired by flashproxy. > (https://gitweb.torproject.org/pluggable-transports/snowflake.git) > Arlo, David, and I have made lots of progress on it lately, and it now > appears to have reached minimum viability. I started a wiki page. https://trac.torproject.org/projects/tor/wiki/doc/Snowflake ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Introducing Snowflake (webrtc pt)
Serene wrote: Q: Why is it called Snowflake? There's a bunch of "ICE" negotiation happening for WebRTC, and it also involves a great abundance of ephemeral and short-lived (and special!) volunteer proxies... Anyhow, if Snowflake seems like it would be useful / desired here, it would be awesome if we had more help getting it stable, polished, audited, deployable, etc... Plenty of work to do! This is really great work, Serene ^_^ Once it is a bit more stable (and perhaps audited!), I'd be happy to incorporate Snowflake into Cupcake if that's useful. I am curious why you chose CoffeeScript for the proxy, rather than JavaScript. woot, Griffin -- “I did then what I knew then, & when I knew better, I did better.” ― Maya Angelou ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
