[tor-dev] [Otter/Cute] What's Cute in APAF

Michele Orrù maker at tumbolandia.net
Thu Oct 10 12:02:15 UTC 2013

Dear Team,

For completeness' sake I am attaching to this email the report I wrote last
week in order to summarize what the project APAF is about, and what there is in
common between it and the Otter/Cute proposal.
Eventually, feel free to add it to the trac page.

After reading ["Cute" design and challenges], though, I think the report lacks
an exhaustive description of APAF's threat model.
In APAF's documentation, the only document vaguely resembling a threat model is
embarassingly poor in terms of content[0]. If still possible, I would like to
remedy writing a more detailed one during this week-end, maybe really
pentesting the application with your help this time.

Does this sound visible to you?

["Cute" design and challenges]


-------------- next part --------------
Hash: SHA512

Principia Philosophiae

This short text's purpose is to report the current status of the GSoC2012 project
APAF, its similarities with Otter/Cute, and to share my personal opinions
about those two projects.

APAF stands for Anonymous Python Application Framework. It is a library
developed as part of my Google Summer of Code project associated with the
TorProject in 2012. The source code is available at
<https://gitweb.torproject.org/apaf.git>, released under the WTFPL. The latest
version of the documentation is available online at


APAF allows a python developer to easily expose web applications as hidden services,
and additionally provides one-click hidden service deployment to end users.

Example use cases that drove APAF development are as follows:

  (a) A python developer has written a XMPP server implementation. APAF allows him
      to deploy his service as a hidden service over the Tor network with minimal
      system administration training in order to reach the more privacy conscious

  (b) An activist seeks to publish documents and videos about government atrocities
      and oppression. APAF can help with a user-friendly interface and running
      on a low-cost smartphone to set up her own pubblication platform.

A rough overview of APAF's implementation and design decisions are as follows:

  APAF is written in python, and based Twisted and Txtorcon.

    The Tor project utilizes python for quite a few projects, and Twisted is a popular
    choice amongst Tor developers. Furthermore, Twisted is an "event-driven
    networking engine": indeed, it implements a wide range of different protocols.

    Txtorcon is an asynchronous Tor control protocol library that utilizes Twisted,
    and is developed by @meejah.  At the time of APAF's development (March 2012),
    Txtocon was under active development, welcoming external contributions, and
    getting attention from the tor community.

  APAF is multi-platform.

    APAF current fully supports Microsoft Windows, Debian Linux, and OS/X.

    The Windows version is deployed as a single executable that transparently creates
    the necessary backing-store required by the hidden services, cryptographic keys and
    static data in an isolated directory.

    The OS/X version is deployed as an .app that features Dock integration for
    controlling APAF, in addition to managing dynamic data storage.

    The Debian Linux version currently is targeted at deployment in the for of a ".deb"

    Additionally APAF has been experimentally deployed to Android based platforms via
    [Py4A] however additional development work is needed to create ".apk" packages.

  APAF is flexible and generic.

    In APAF parlance a "service" is an application running inside of APAF.  Each service
    can be individually toggled on and off and configured.  Additionally, there is a
    one-to-one mapping between APAF services and Tor's hidden services, with
    key/hostname/port isolation.

    In addition to services written using Twisted, APAF additionally supports services
    utilizing other [WSGI] compatible frameworks.

  APAF is user friendly.

    APAF provides a simple web-based administration interface, in the form of "panel".

    "panel" provides a HTML based front-end backed by a JSON/REST back-end to enable
    APAF service configuration.

Summae Logicae

Currently, APAF ships with the following services (and accompanying documentation):

  * "panel", the aforementioned JSON/REST/HTML based management interface, written using
    Twisted + Cyclone.

  * A static file server, showcasing how to write APAF services. The code,
    including documentation, fits in less than 30 lines.

  * Zinniablog, a Django based blog engine, integrated with APAF via the WSGI interface.

Kritik der reinen Vernunft

What follows are my *strictly personal* opinions about what went wrong during
APAF's original development and what can be improved.

First of all, I blame myself for not being a good user interface developer. I didn't
manage to create a good, original front-end to APAF, and ended up with a simplistic
bootstrap based web interface for administration. The Windows and OS/X versions in
particular could be significantly improved in terms of user experience.

Secondly, the scope of the project was considerably larger than initially expected.
Supporting four different platforms and targeting a diverse user base is
non-trivial, in terms of software design. Adopting twisted implies omitting all
projects based on libraries not in python and not speaking wsgi.
Also, for my experience, the standard python web developer uses
django, and has no background in twisted. It is yet possible to use APAF,
but that is certainly not the "mindless" standard way of INSTALLED_APPS += ['apaf'] he
would expect.

Finally, multiplatform development was hampered by lack of access to real hardware
and suffered due to the the use of virtualization and obsolete versions of Windows
(XP SP3) and OS/X (Lion).

Summa Theologica (aka. what's cute in apaf.)

Disclaimer: I don't really know much about the Otter/Cute project.
Besides the website, not really providing useful informations, I have been
speaking a little bit with Lunar^ about it.

In my opinion APAF fits perfectly the description of the deliverable, however
further work and developers are required to improve support for end user experience
in each specific platforms involved.

It is also worth noting that such a big project as this will most likely end up
requiring rather heavyweight libraries. For instance, an APAF instance with
Zinniablog means using Twisted+Django, which is a memory-eating monster,
and there cannot be done much to fix that.


[WSGI] <https://en.wikipedia.org/wiki/Web_Server_Gateway_Interface#WSGI-compatible_applications_and_frameworks>
[Py4A] <https://code.google.com/p/python-for-android/>
Version: GnuPG v1.4.15 (GNU/Linux)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20131010/a0a692cc/attachment.sig>

More information about the tor-dev mailing list