[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fwd: [tor-dev] GSoC 2017 - unMessage: a privacy enhanced instant messenger

Hella links...

---------- Forwarded message ----------
From: Felipe Dau <dau at riseup.net>
Date: Sun, Apr 2, 2017 at 1:42 PM
Subject: Re: [tor-dev] GSoC 2017 - unMessage: a privacy enhanced
instant messenger
To: tor-dev at lists.torproject.org

On Sun, Apr 02, 2017 at 04:51:40PM +0000, dawuud wrote:
> Hi. I registered with Google to be a GSoC mentor for Tor Project.
> Hopefully Meejah will agree to be the backup mentor for this
> and register today or tomorrow before the deadline on Monday.
> Let me know if there's anything else timely that I must do for this.

Thanks David!

Here is the proposal I have so far. Please let me know what you think.
(It is also hosted at

I intend to upload to the GSoC website tonight and add updates until
the deadline.


# unMessage: an anonymity enhanced instant messenger

In an age where spying, surveillance and censorship evidently became
regular practices by various kinds of attackers, it is sensible to be
concerned about instant messaging applications, which are very popular
communication tools that handle private and identifying information.
Such a scenario demands solutions to prevent users from harm these
attacks might cause.

There are currently good solutions such as [Signal], [Wire] and
[OMEMO] apps that make end-to-end encrypted conversations possible.
Although such apps successfully provide privacy, they have a great
dependency on servers and metadata in order to work and they are not
able to provide anonymity. An app that solves this problem is
[Ricochet], by not having such dependencies. However, it heavily
relies on the transport it uses and does not offer its own encryption

[unMessage] is also one of those solutions: a peer-to-peer anonymity
enhanced instant messenger written in Python that I have been working
on for a while with [David Andersen] - my advisor. unMessage uses on
its own end-to-end encrypted [protocol] to maintain conversations,
focusing in not depending on servers, metadata and transport. We have
recently released an alpha version which should be easy for developers
to install and test its current features such as message exchanges,
authentication, and voice chat, but there is still a lot of work to do
in order to achieve a mature state where users can trust it due to its
properties and usability. As we believe unMessage has potential to
become a great anonymity enhancing app with a code that is simple,
readable and therefore easy to maintain, I propose to work on it
during this year's Google Summer of Code with the support of the Tor
Community to to make it closer to maturity. We expect to implement
fixes, improvements and features from our discussions (on its
[tracker] and [tor-dev]) in order to turn it into a maintainable,
feature-rich and useful app which everyone can benefit

## Technologies

unMessage's features were possible with the use of the following

- Transport makes use of [Twisted], [Tor Onion Services] and

- Encryption is performed using the [Double Ratchet Algorithm]
  implemented in [pyaxo] - which uses [PyNaCl]

- Authentication makes use of the [Socialist Millionaire Protocol]
  implemented in [Cryptully]

- Transport metadata is minimized by Tor and application metadata by
  the unMessage [protocol]

- User interfaces are created with [Tkinter] for the [GUI] and
  [curses] for the [CLI]

- Voice chat uses the [Opus codec] for constant bitrate encoding

## Contributions

Since its current (alpha) release, we have been discussing it with
[Patrick Schleizer] and [HulaHoop] from [Whonix], who are making
great contributions to help us test it, as well as suggesting new
features and improvements. We are also working to run it on Whonix
(which will allow it to be run on Tails as well) with help from
[meejah] by adding a new feature to txtorcon to make unMessage (and
all the apps that use txtorcon) "Control Port Filter friendly".

Since the introduction of this project for GSoC, [dawuud] became
interested in contributing and mentoring it and assisted me on making
this proposal.

## Tasks

The project is split into tasks, each assigned an ID (in parenthesis)
that is used to compose the timeline. I have been generous with how
much time each task will demand and I am also leaving the whole week
of each evaluation to review and make sure the deliverables meet
expectations. Therefore, it is possible that I am able to work on
additional tasks in case they consume less time than planned.

### Improve setup script (T1)

This task will improve unMessage's `setup.py` by removing redundant
package metadata, use files for the requirements and offer development
requirements. This task will be tracked in [issue 35].

### Use attrs (T2)

[attrs] is used to simplify the code by removing boilerplate, make it
more concise, and consequently improve its quality. Classes
definitions will be modified to use attrs' declarations so that
attributes have default types and values, as well as validation. This
task will be tracked in [issue 34].

### Support file transfer (T3)

unMessage is able to support various elements of a conversation such
as requests, messages and authentication. New elements to transmit
file requests and the actual files will be added and handle by the
elements parser. This task will be tracked in [issue 12].

### Add a logger (T4)

There is currently no logging being done and in order to debug, the
only possible approach is using the UIs. A module will be added to
send logs to the terminal and a file. This task will be tracked in
[issue 30].

### Use automat (T5)

There are certain objects in unMessage that are state machines. Their
implementation are very simple and limited as initially they were not
designed as state machines. In order to turn them into real state
machines, [automat] will be used. This task will be tracked in
[issue 26].

#### Design the concept (T5A)

Before implementing, I will map the state machines to be created, draw
the graphs and have a clear understanding of their transitions and

#### Use automat state machines (T5B)

With a design to follow once T5A is done, I will convert the objects
into automat state machines.

### Make functions/methods asynchronous (T6)

unMessage's initial implementation did not use Twisted and it had
pre-defined callbacks in order to continue the path of the action it
was performing. It later migrated to Twisted but the pre-defined
callbacks are still used. Such callbacks will be removed and the
functions that are part of these asynchronous actions will return
`Deferred`s to make an actual callback chain. This task will be
tracked in [issue 21].

### Add a test suite (T7)

There is not a single test written for unMessage and that is crucial
to continue its development. The test suite will be made with [pytest]
and will also use [hypothesis] for fuzzing/property tests. I do not
expect to achieve 100% converage, test the most important parts of
unMessage (mainly the `Peer` module). Also, as I am not familiar with
User Interface tests, these will not be part of the task (we are also
planning to use a different framework for the GUI, so its tests will
only be created after there is a decision). This task will be tracked
in [issue 33].

### Offline messages (T8)

As part of unMessage's design, no servers are used to establish and
maintain conversations. As a consequence, peer-to-peer communication
requires users to only be able to chat while both are online. Although
unMessage's protocol supports asynchronous communication, this
limitation forces conversations to be synchronous. In order to solve
this problem, a [Tahoe-LAFS] server will be used to temporarily store
unMessage's packets for peers that were not available when they were
sent and can be retrieved later once the peers are online. This task
will be tracked in [issue 32].

### Timeline

Tasks/Weeks | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
T1          | X |   |   |   |   |   |   |   |   |    |    |
T2          | X |   |   |   |   |   |   |   |   |    |    |
T3          | X |   |   |   |   |   |   |   |   |    |    |
T4          |   | X |   |   |   |   |   |   |   |    |    |
T5A         |   | X |   |   |   |   |   |   |   |    |    |
Mid-term 1  |   |   | X |   |   |   |   |   |   |    |    |
T5B         |   |   |   | X | X |   |   |   |   |    |    |
T6          |   |   |   |   | X | X |   |   |   |    |    |
Mid-term 2  |   |   |   |   |   |   | X |   |   |    |    |
T7          |   |   |   |   |   |   |   | X | X | X  |    |
T8          |   |   |   |   |   |   |   |   |   |    | X  |
Final       |   |   |   |   |   |   |   |   |   |    |    | X

# Background

I am a Senior studying Computer Engineering at the Federal
Technological University of Parana in Brazil. In January of 2014 I
went to the U.S. for an exchange program, which lasted until December.
During the Summer of that same year, I joined a research project lead
by David Andersen where I learned about Anonymous Communication and
became so attracted to the field that I continued to be part of the
project since then. We have mostly worked on [nymphemeral], [pyaxo],
[nymserv] and recently, unMessage.

# Code sample

I have a few repositories on my [GitHub profile] and I recommend
taking a look at the ones referenced above, but specially [unMessage]
and [nymphemeral], which are the ones I have mostly worked on.

# Why The Tor Project?

As I mentioned, I have been studying Anonymous Communication for
almost three years now and I intend to keep doing it not only because
I enjoy it, but because it is an important field capable of helping
millions of people around the world.

In my opinion, The Tor Project is the biggest organization of its
kind and working with people responsible for software I run everyday
is a dream of every developer.

The Tor community continues to grow every day and I believe that
participating in the Google Summer of Code will also contribute to

# Experiences with free software development environments

Since I joined the research project, I have been mostly working with
David Andersen on the projects I mentioned previously and git/GitHub
make our work a lot easier to work in parallel on the same code,
manage tickets to help us keep track of the development and interact
with contributors interested in what we do.

Whenever I see a project which I can contribute to, even if a it is a
small change, I open a ticket or make a pull request if I am able to.
My [GitHub profile] lists all my contributions.

PyNaCl is one of the recent projects I contributed to. While working
on pyaxo I noticed some of the encryption calls could be improved to
simplify their usage by making an argument optional. The developer
who reviewed the pull request was very positive about it and assisted
me while updating the docs to cover this new change.

While working on unMessage I asked Patrick Schleizer and HulaHoop for
help as it would be great to have it running on Whonix. We have had
great discussions and contributed to both projects in order to provide
this feature. Along with the development, some changes to txtorcon
were appreciated and we have also been working with meejah on that.

# Commitment

I have concluded all classes for my degree and I am currently
an industrial IT intern at an Engineering and Software company, which
is the only commitment I will have besides GSoC throught the duration
of the program. I intend to work on unMessage 5~6 hours on weekdays
and the remainder of the workload on weekends.

# Post GSoC

The tasks we picked to work on GSoC are a subset of all the ones we
have been discussing during unMessage's development, which means that
there will be more work to be done after GSoC. Also, unMessage is
quite a big project. There are lots of possibilities to explore in the
instant messaging field as well as many challenges to overcome when
offering an application with usability and features as good as the
popular ones, while protecting users' privacy and anonymity. I intend
to keep working on unMessage until we have an application that
accomplishes our goals.

Also, as I have been working with anonymous communication for a while,
I do not see myself going somewhere else soon, so the chances of
keeping contributing the Tor community are high.

# Communication

I intend to use IRC to discuss with my mentor and other tor devs (who
wish to contribute to the project) about ideas and actions to be

To formalize what is discussed on IRC, I will use unMessage's tracker
on GitHub to manage features/enhancements/issues to keep records and
maintain an organized environment for the development of the project,
as well as interact with contributors. I am suggesting this tracker as
we have already been using it for a while, but I can migrate to Tor's
Trac if needed.

To summarize everything, I will do what seems to have worked well for
previous students: regular reports on the mailing list to keep people
updated with what is happening on the project from a higher level.

## Contact info

OFTC: dau

Email: dau at riseup.net

PGP: 0xC5A49047572A0D47

# Other GSoC projects in mind?

I am only applying to this one.

# Anything else?

I encourage you to take a look at the git logs and issue trackers from
[unMessage], [nymphemeral] and [pyaxo]. I think I am a very organized
developer and I have been trying my best to follow the gitflow model
and take advantage of the features offered by GitHub.

[attrs]: https://attrs.readthedocs.io
[automat]: https://github.com/glyph/automat
[cli]: https://unmessage.readthedocs.io/en/latest/cli/cli.html
[cryptully]: https://github.com/shanet/Cryptully
[curses]: https://docs.python.org/2/library/curses.html
[david andersen]: https://github.com/rxcomm
[dawuud]: https://github.com/david415
[documentation]: https://unmessage.readthedocs.io
[double ratchet algorithm]:
[github profile]: https://github.com/felipedau
[gui]: https://unmessage.readthedocs.io/en/latest/gui/gui.html
[hulahoop]: https://github.com/HulaHoopWhonix
[hypothesis]: https://hypothesis.readthedocs.io
[issue 12]: https://github.com/AnemoneLabs/unmessage/issues/12
[issue 21]: https://github.com/AnemoneLabs/unmessage/issues/21
[issue 26]: https://github.com/AnemoneLabs/unmessage/issues/26
[issue 30]: https://github.com/AnemoneLabs/unmessage/issues/30
[issue 32]: https://github.com/AnemoneLabs/unmessage/issues/32
[issue 33]: https://github.com/AnemoneLabs/unmessage/issues/33
[issue 34]: https://github.com/AnemoneLabs/unmessage/issues/34
[issue 35]: https://github.com/AnemoneLabs/unmessage/issues/35
[meejah]: https://github.com/meejah
[nymphemeral]: https://github.com/felipedau/nymphemeral
[nymserv]: https://github.com/rxcomm/nymserv
[omemo]: https://conversations.im/omemo
[opus codec]: https://opus-codec.org
[patrick schleizer]: https://github.com/adrelanos
[protocol]: https://unmessage.readthedocs.io/en/latest/protocol.html
[pyaxo]: https://github.com/rxcomm/pyaxo
[pynacl]: https://github.com/pyca/pynacl
[pytest]: http://docs.pytest.org
[ricochet]: https://ricochet.im
[signal]: https://whispersystems.org
[socialist millionaire protocol]:
[tahoe-lafs]: https://github.com/tahoe-lafs/tahoe-lafs
[tkinter]: https://docs.python.org/2/library/tkinter.html
[tor onion services]: https://www.torproject.org/docs/hidden-services.html
[tor-dev]: https://lists.torproject.org/pipermail/tor-dev
[tracker]: https://github.com/AnemoneLabs/unmessage/issues
[twisted]: https://twistedmatrix.com
[txtorcon]: https://github.com/meejah/txtorcon
[unmessage]: https://github.com/AnemoneLabs/unmessage
[whonix]: https://whonix.org
[wire]: https://wire.com

tor-dev mailing list
tor-dev at lists.torproject.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 465 bytes
Desc: not available
URL: <http://lists.cpunks.org/pipermail/cypherpunks/attachments/20170402/dc0ce820/attachment.sig>