[guardian-dev] Methods for using anonymization tools

str4d str4d at i2pmail.org
Wed Apr 29 22:13:29 EDT 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Marvin Arnold wrote:
> Hi all, I heard there may have already been some discussion on this
> topic but I haven't been able to find it in the archives.
> 
> I'm interested in how to best use existing anonymization tools 
> (Tor, I2P, etc) with client applications. The current approach 
> requires users to install the anonymizer (Orbot, etc) + the client 
> (Chat Secure, etc) separately. Even if there was no further 
> configuration necessary, I believe this is a deal breaker for most 
> people.

I agree. This is something I thought over when I first started Bote
(how to integrate it with I2P). The conclusion I came to (based more
on instinct than numbers) was that the percentage of users who will
find the client app before the anonymizer was likely to be too large
to assume they would all be happy performing even one more out-of-app
step. Better to allow users to start using the app immediately, and
then later encourage them to install the anonymizer.

At the same time, running multiple I2P routers on an Android device is
generally a bad idea (battery drain, data usage, connection limit
issues, memory usage, ...). Judging by other responses to this thread,
it seems similar for Tor.

> 
> Alternatives that I have heard mentioned include a) putting Orbot 
> into every client that wants to use it, and b) some type of 
> embedded library that makes sure only one Orbot instance is
> running per device. Of course both of these solutions risk using up
> a lot of data for users who may not have understood what they are 
> downloading.

The approach I take with Bote is to bundle an I2P router inside, but
by default only use it if I2P Android is not installed. I also provide
a setting for the user to manually specify whether they want to use
the internal router, I2P Android or a remote I2P router (e.g. on the
LAN or via a SSH tunnel).

For interacting with I2P Android, I provide a client library that:
- - encapsulates all the I2P Java libraries necessary for client
applications
- - handles all communication between the client and I2P Android
- - provides UI helpers for detecting that I2P is installed, requesting
it be installed, or starting it

The process of bundling the I2P router in an app is not too hard, but
I plan on creating a separate Android library that will handle it
(depending on the client lib). So apps can include the client lib, and
optionally the router lib - basically an OnionKit for I2P.

All of the above is equivalent to your solution a) and part of b).
Detecting other apps that bundle I2P is AFAICT hard to do universally,
but if there was a mechanism established to do so then I would
definitely add it to the client library. I'm interested to know how
OnionKit plans to do this. But even without it, I would encourage app
developers to prompt users after some time that they should maybe
switch to using I2P Android, mostly for increased transparency of what
is actually going on.

str4d

> 
> This has led me to a thought that Tor (etc), regardless of how it 
> is incorporated, may be overkill for some applications. 
> Specifically, my friend and I have started working on a proof of 
> concept text messaging app that will use a custom mixnet to send 
> SMSs. It is likely to have higher latency and be more traceable 
> than a Tor based implementation, but will also consume less data 
> (we are interested in starting with the US where most plans
> include unlimited SMS), extend battery life, and be a single step 
> installation.
> 
> I'm very interested in hearing your thoughts about the best way to
>  incorporate existing anonymization tools and the merit of our 
> proposed approach of a custom mixnet implementation. Ultimately it 
> is a question about how to best manage privacy, usability, and
> user expectations.
> 
> Marvin
> 
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJVQY+9AAoJEBO17ljAn7PgwW8P/2qIKLxQLVqN+Lx/4h8uzLNF
90hqTuVqviY5VgQAytkSddBARyzNwlF/KueLj503NYWXQGZtPTjnn/YxGLYNjlwI
Xkc9H9HzVM6xU/R+UMq3vYJAktXYnIPqrIuvH0G7pSZuLa+KDzeMZYX4KSIDTwUa
C863CTMhtf+PZGxD+j9uIDkMBxRSBpj8BNNwfcv+hHE5d+C9O51J5B8FzSBCLBgA
cproK0qeTA81rjt9hOz7w1Tp74tXwEYNBuafVL93Fjufwrb7eNK43yVzqdVEIZRo
ykX+LoaM7VqFvrqi750u9bPAAVzMRSztKM5c7DjJxwlEzCNJX21YSqwY2a9LrGa+
MUoVzWHWUBR+UF4LqUHUVGgm7tiwXyKzAwRRcVVxlptXLwyRW7l76bFIR5CHodZH
wWMVjn/UfQ0+/opJ28JOzzt2LnhC68AR6oi3dlNHVBpZAjDhXhrdxGQ1VDTHubNz
V2KAit8PsXHXicYJGYNXW3t5Q38N/NdZWsbF4Na0cTLo3sRfzPd0VyOh6WvRuUPZ
tKBkObS1NHeYtFG4j0OskUh5+HV+OafGqt96nWGTYEXOQbIKccrnDXgzz+Le11kr
z6CqvZZ82MQo6zC/l3jfjTsxcAm28MmOh350vf5L69FvLIZ++lmkSfxrViNeAi8/
npxcHP8ZqMd9NtB7ZMIH
=dFlM
-----END PGP SIGNATURE-----


More information about the guardian-dev mailing list