The meek pluggable transport is currently running on the bridge I run,
which also happens to be the backend bridge for flash proxy. I'd like to
move it to a fast relay run by an experienced operator. I want to do
this both to diffuse trust, so that I don't run all the infrastructure,
and because my bridge is not especially fast and I'm not especially
adept at performance tuning.
All you will need to do is run the meek-server program, add some lines
to your torrc, and update the software when I ask you to. The more CPU,
memory, and bandwidth you have, the better, though at this point usage
is low enough that you won't even notice it if you are already running a
fast relay. I think it will help if your bridge is located in the U.S.,
because that reduces latency from Google App Engine.
The meek-server plugin is basically just a little web server:
https://gitweb.torproject.org/pluggable-transports/meek.git/tree/HEAD:/meek…
Since meek works differently than obfs3, for example, it doesn't help us
to have hundreds of medium-fast bridges. We need one (or maybe two or
three) big fat fast relays, because all the traffic that is bounced
through App Engine or Amazon will be pointed at it.
My PGP key is at https://www.bamsoftware.com/david/david.asc if you want
to talk about it.
David Fifield
On Fri, Mar 20, 2015, at 04:05 AM, isis wrote:
> Nathan Freitas transcribed 0.8K bytes:
> > On Thu, Mar 19, 2015, at 06:58 PM, David Fifield wrote:
> > > What would it take to get some screenshots that show how to turn on
> > > pluggable transports? I would like to add a guide to
> > > https://trac.torproject.org/projects/tor/wiki/doc/meek#Quickstart and
> > > instructions to
> > > https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports#Howto…
> > > .
> > >
> > > Or do you have such a guide I can just link to?
> > >
> >
> > We're still finalizing the UI for the new features (QR code scanning,
> > meek bridge type selection, etc) so once that is completed, we'll do a
> > round of screenshots, guide updates, etc. This will most likely happen
> > in early April.
>
> Wow, this is awesome! Great work, to all of you!
>
> Let me know if there's anything more I can do to help.
In thinking about how users on phones/tablets will actually get
obfs3/4/scramblesuit bridges, I realized that going to
https://bridges.torproject.org on their mobile device will not be a
great experience. The QR code scanning if they or a friend also has a
PC, but in a pure mobile environment, it doesn't help so much.
I can create a ticket for this, but just to lay out the idea, I think we
need to have the bridge:// (or the improved proposed obfs4:// obfs3://
type specific scheme URLs) as a clickable link in both the bridges.tp.o
site and the gettor email response messages.
+n
I was going to write an email advocating for the removal of the wildcard
'*' transport specification in pt-spec.txt. But then I saw that the
current version of the spec doesn't mention the wildcard anymore; it was
replace with a TODO in
https://gitweb.torproject.org/torspec.git/commit/pt-spec.txt?id=4dcd7e94f17…
"TODO: Document '*' transport"
So how about we remove the TODO and just act like it never existed?
Normally tor tells the transport plugin what transports to activate by
giving it a string like "obfs3,obfs4"; but you're supposed to also be
able to pass "*", which means "activate all transports you are capable of."
Apparently this feature, though pyptlib and goptlib support it, has
never been implemented in tor itself:
Implement the wildcard "*" protocol in {Client,Server}TransportPlugin lines
https://trac.torproject.org/projects/tor/ticket/3725
A wildcard specification doesn't really make sense, anyway. For one
example, flashproxy-client knows two transport names, "flashproxy" and
"websocket", which are synonyms. But if tor asks for "*",
flashproxy-client shouldn't open up two listeners. Another case is fog
(a dynamic transport combiner), which constructs a chain of transports
from a transport name like "obfs3_websocket". The transports can be
combined in infinite ways; it doesn't make sense to say, "activate all
of them."
https://lists.torproject.org/pipermail/tor-dev/2013-December/005966.html
Let's just drop this part of the spec, and delete some underspecified
and unused code?
David Fifield
On Thu, Mar 19, 2015, at 06:58 PM, David Fifield wrote:
> What would it take to get some screenshots that show how to turn on
> pluggable transports? I would like to add a guide to
> https://trac.torproject.org/projects/tor/wiki/doc/meek#Quickstart and
> instructions to
> https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports#Howto…
> .
>
> Or do you have such a guide I can just link to?
>
We're still finalizing the UI for the new features (QR code scanning,
meek bridge type selection, etc) so once that is completed, we'll do a
round of screenshots, guide updates, etc. This will most likely happen
in early April.
This is funny
Tor Project Loves and Thanks Reddit
| |
| | | | | | | |
| Tor Project Loves and Thanks Reddit |
| |
| View on www.youtube.com | Preview by Yahoo |
| |
| |
ty
----- Original message -----
From: Nathan of Guardian <nathan(a)guardianproject.info>
To: guardian-dev(a)lists.mayfirst.org
Subject: [guardian-dev] Orbot v15 alpha 5 is out: MeekObfs4VPNQRCodez!
Date: Thu, 19 Mar 2015 11:12:59 -0400
Orbot v15 alpha work is nearly done...
APK: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-5.apk
SIG: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-5.apk.asc
Highlights:
* Updated to tor-0.2.6.4-RC
* VPN / full device "Apps" mode is fully implemented and stable - no
root needed to run all apps on your device through Tor
* Meek and Obfs4 pluggable transports are now included and working quite
well, even with the VPN mode
* Easy scanning and sharing of bridge address QR codes from
bridges.torproject.org
* Removed integrated webview/webkit for now, since Android WebView is
generally p0wn3d
More at: https://gitweb.torproject.org/n8fr8/orbot.git/tree/CHANGELOG
Thanks to nickm, isis, yawning, fifield, sandro, team psiphon and many
others for all the various amazing pieces coming together to make Orbot
v15 a very important and big release.
+n
--
Nathan of Guardian
nathan(a)guardianproject.info
_______________________________________________
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email: guardian-dev-unsubscribe(a)lists.mayfirst.org
As I mentioned at the dev meeting, Mashael and I were just finishing up
a survey paper on Tor performance and security research.
The tech report version was just posted on eprint:
https://eprint.iacr.org/2015/235
for your perusing pleasure. ;-)
Thanks,
- Ian
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi devs,
we're making some medium-term plans to produce automated screencasts
that explain how to download, verify, and run Tor Browser on Windows,
Mac OS X, and Linux, localized to at least half a dozen languages.
The focus here is really on *automated*. Whenever there's a new Tor
Browser version, we'd like to minimize manual steps for creating new
screencasts to the absolute minimum.
Here's our plan, and we'd appreciate your feedback on this:
1. Set up three systems (Windows, Mac OS X, and Linux) either as
virtual machines, using VirtualBox or VMware Fusion, or on a dedicated
triple-boot Mac Mini.
2. Install Sikuli (http://www.sikuli.org/; thanks for Lunar for the
suggestion!) either directly on these machines or on the virtual
machine host or on a separate host in the same network.
3. Write a Sikuli script for each operating system and language,
probably re-using large parts, to make all the necessary steps to
download, verify, and run Tor Browser. This script may include steps
for preparing the system by changing its language and for cleaning up
afterwards. Ideally, this script can easily be maintained whenever
Tor Browser changes.
4. Record audio snippets in the various language that explain the
steps that will later be performed in the screencast. Either include
these as part of the Sikuli script, or put them together separately
and add them to the recording later.
5. Start a screen recorder and run the Sikuli script for all three
systems and all supported languages.
6. Post-process the recording by cutting the video, attaching the
audio, and possibly adding text slides at beginning and end; hopefully
using scripts.
Again, the goal is to keep the overhead for recording a new set of
screencasts as low as possible. If it takes days to do this, nobody
will do it, and we'll soon have outdated videos.
What do you think about this plan? And do you have specific
suggestions for the single steps?
Thanks!
Cheers,
Karsten and Sherief
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQEcBAEBAgAGBQJVCp9HAAoJEJD5dJfVqbCrfTEH/2oTPvEYIZDys42MeKXmQFA9
bmVMky5sCO6/sOAx8BIVdUXF1b1m8mxPev5X2SarYCyNaZOkbtCOLyLzrFjUii0e
aH7cjc6QFm31TX5oJ10O7/7Of13q4l0jYY2j0KDmzbFrNndK9t9W+nh4/xSiTdEh
a3IzVnOVu4c1nE4xwCSxwqaia2xi5N8fUuZPN4ttGGVctp4ucglUwTCZodfqNUMK
Jiq4UO+ZeGvPaRGPLK8sxCfnR5DrZF5i3v4YhYy5d1g0yGDNFHv61zP1PQHx3BCG
47ne5o+FDsxLxDe1w4/l7i4HvdPHP7XovkR4yckYs/6e4462QUfBxVcwIm9p6rk=
=E8Kf
-----END PGP SIGNATURE-----
Hello,
Nickm mentioned to me that he was curious as to how LIONESS performs
these days (See #5460) with modern cryptographic primitives. I've
conveyed the results to several people, but I'm also sending them here
for posterity.
Code used: https://github.com/yawning/lioness (May be incorrect, don't
use for anything other than benchmarking. Numbers taken with a
previous version of the code without the initial memcpy, that was added
later so that the code in git could be used by the extremely brave for
other things.)
All measurements taked on an i5-4250U, so the usual caveats about
turboboost and hyperthreading apply.
Baseline (from tests/bench, AES-NI enabled):
===== cell_ops =====
Inbound cells: 231.33 ns per cell. (0.45 ns per byte of payload)
Outbound cells: 224.39 ns per cell. (0.44 ns per byte of payload)
(Note: Outbound with AES-NI disabled is ~3.0 ns per byte)
LIONESS (BLAKE2b/ChaCha, 509 byte block size):
* ChaCha20:
* Ted Krovetz's AVX2-ed ChaCha20/Ref AVX BLAKE2b: ~6.6 ns/byte
(~143 MiB/s)
* AVX2ed-ed ChaCha20, Andrew Moon's AVX2-ed Blake2b: ~5.0 ns/byte
(~190 MiB/s)
* ChaCha12:
* Ted Krovetz's AVX2-ed ChaCha12/Ref AVX BLAKE2b: ~6.1 ns/byte
(~156 MiB/s)
* AVX2ed-ed ChaCha12, Andrew Moon's AVX2-ed Blake2b: ~4.4 ns/byte
(~213 MiB/s)
* ChaCha8: (Yolo swag 420 blaze it)
* Ted Krovetz's AVX2-ed ChaCha8/Ref AVX BLAKE2b: ~5.8 ns/byte
(~164 MiB/s)
* AVX2ed-ed ChaCha12, Andrew Moon's AVX2-ed Blake2b: ~4.1 ns/byte
(~232 MiB/s)
NB: Using Andrew Moon's Blake2b isn't in git, because the way I tested
it was kind of kludgey.
Profiler output:
64.04% lioness_test_av lioness_test_avx2 [.] blake2b_compress
22.43% lioness_test_av lioness_test_avx2 [.] chacha_stream_xor
6.60% lioness_test_av lioness_test_avx2 [.] blake2b_init_key
2.72% lioness_test_av lioness_test_avx2 [.] blake2b
2.41% lioness_test_av libc-2.21.so [.] __memcpy_avx_unaligned
1.07% lioness_test_av lioness_test_avx2 [.] lioness_encrypt_block
Ted Krovetz's ChaCha implementation isn't quite the fastest out there,
but it doesn't lag massively behind Andrew Moon's. Benchmarks on the
same hardware from Andrew Moon's chacha-opt/blake2b-opt are:
BLAKE2b:
576 byte(s):
avx2, 1468.00 cycles per call, 2.5486 cycles/byte
avx, 1674.00 cycles per call, 2.9062 cycles/byte
x86, 2020.00 cycles per call, 3.5069 cycles/byte
generic/64, 2638.00 cycles per call, 4.5799 cycles/byte
ChaCha20:
576 byte(s):
avx2, 694.00 cycles per call, 1.2049 cycles/byte
avx, 1104.00 cycles per call, 1.9167 cycles/byte
ssse3, 1112.00 cycles per call, 1.9306 cycles/byte
sse2, 1376.00 cycles per call, 2.3889 cycles/byte
x86, 2528.00 cycles per call, 4.3889 cycles/byte
generic, 3200.00 cycles per call, 5.5556 cycles/byte
I don't think using CTR-AES (with AES-NI) in a LIONESS construct is
going to be that big of a win, at least on my hardware, and the sort of
performance I'm seeing feels too much of a performance hit to me.
Regards,
--
Yawning Angel
Another thing to remove/disable from Tor Browser "Mini" (aka Orfox)...
----- Original message -----
From: Mark Finkle <mfinkle(a)mozilla.com>
To: "mobile-firefox-dev(a)mozilla.org" <mobile-firefox-dev(a)mozilla.org>,
"dev-platform" <dev-platform(a)lists.mozilla.org>
Subject: Intent to Ship: 3rd Party Install Tracking
Date: Wed, 18 Mar 2015 14:28:57 -0400
We wanted to start some transparency around a new integration coming to
Firefox on Mobile [1]. We are planning to integrate a 3rd party install
tracking SDK from a company called Adjust [2] which will send data,
possibly device identity data [3], to a 3rd party server. We don't do
this
very much at Mozilla so we wanted to be proactive about messaging.
There are good reasons for wanting to collect the data. Our marketing
and
growth goals for 2015 will require spending non-trivial amounts of
money.
The data will help us spend the money responsibly and efficiently.
Advertising metrics on Mobile is not as simple as some Desktop systems.
On
Desktop, we can do most of this using the download links on our web
pages.
Mobile installs come from App Stores, and it's harder to integrate into
those system.
This is Mozilla, so we are worried about integrating the SDK from a
privacy
and tracking concern. The goal is to limit the data to non-PII sensitive
information and we'll only allow the data to be pushed once, on an
INSTALL_REFERRER intent [4] sent when Firefox for Android is first run
after being installed from the Play Store, and only when the install is
coming from an advertising campaign. No other data will be sent at any
other time. Normal installs from the Play Store would not have any data
collected.
We still need to audit the open source SDK to see exactly what data is
sent
and how it's collected. We also have started doing a
security/privacy/legal
audit of the vendor and their collection/storage practices.
Just a note, this is not the first attempt to add such 3rd party data
collection to Firefox on Mobile. The other attempts did not happen
because
we found flaws in the systems or the system failed to meet our concerns
about privacy. The proposed system seems to have a decent chance of
passing
our audits around privacy and security, so it's time to open the
discussion
to a wider audience.
Here are some other notes about the Adjust system:
* This is an open source SDK, fully transparent, based in Germany,
widely
adopted and regarded, beholden to the strictest EU privacy standards.
* We will collect the absolute minimum data, once, to measure for
install.
We’ll know exactly what data is being passed.
* We’re paying for the SDK and service, which is good because the
vendor's
model is not based on monetizing our data in aggregate to develop
behavioral segments for other advertisers.
* This will allow real-time optimization of marketing dollars, much like
virtually all major mobile apps do, and much like we have already been
able
to do on paid marketing desktop for quite some time
* We likely use this system until we can figure out how to do it by
ourselves, in house. Until then, we need to be pragmatic.
This is just a heads up email. We want the effort to be open and
transparent. Questions and comments welcome.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1143888
[2] https://github.com/adjust/android_sdk
[3] The SDK requires the use of the Google Advertising ID to uniquely
track
the device
[4] https://github.com/adjust/android_sdk/blob/master/doc/referrer.md
_______________________________________________
mobile-firefox-dev mailing list
mobile-firefox-dev(a)mozilla.org
https://mail.mozilla.org/listinfo/mobile-firefox-dev
--
Nathan of Guardian
nathan(a)guardianproject.info