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] <https://trac.torproject.org/projects/tor/attachment/wiki/org/sponsors/Otter/Cute/cute.txt.asc> [0] <http://apaf.readthedocs.org/en/latest/threat_model.html> -- mi.
-----BEGIN PGP SIGNED MESSAGE-----
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
<http://apaf.readthedocs.org/en/latest/>.
=========
Leviathan
=========
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
users.
(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"
package.
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.
===============================================================================
EOF
===============================================================================
[WSGI] <https://en.wikipedia.org/wiki/Web_Server_Gateway_Interface#WSGI-compatible_applications_and_frameworks>
[Py4A] <https://code.google.com/p/python-for-android/>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
iQIcBAEBCgAGBQJSVpUMAAoJEE0/ouWZbGdnq0QQAK1Qa3R4r4lUhw9eyTomiDTP
+DByIyfDexevRK0902hWzOUYcX5IxStChxkv/TGcoABgMVYhgtwq6eeF/EaVxt7V
4TxJyt5o/ejqH45ZT38qTyRN5ROMhB9sqrckFDsUPeoXuDlGdbNQjZG6szsbzF2A
RTaEQz9XK4WaQOm9j1VPKgKUu1o+q1R5aSil6fIu4ZjHosLC5KwpvB4RMvRABrOz
BPyNVpn6IHjBi8GOrErANmS9KBr4o9eqNiPEJ1NlfDsBM4gh4RcyBcMXk3NyxqNf
4G8/8PV6FgP8/hl6cNWGDQ/sqUcCdX+BVHBsV11CCsLWhwsuwlg/D7jLM7zjc2Rj
bz6fxufKdWtqWEmArHi7NlM/IWGL0GVewR8Bc+vNZemcLWSnr1vfrs8urEn1d9bz
FM8tBY3F9JPWB+Qq4Os6iUho6AdBY1X96HDKER4oAF3qeIwsROtMfWFhFA0OAhY0
1omd+uNiLzpArOCaawVMcjKtTcPQ8lMnnP+V5xn+rB6qbl3ThHhg3pMGZ7LUuAqn
mgHrPedW3uq1PSnid2L8vmfnIDWW+NItUuH6UtGWFVthpORL2r/ca3P3ndE31YVS
tGTRIb1PkLqx1lZyRaSHdRExS0g5pLPeyZ+mbtm0zeQf7MTKyx9HYBwGW4NJk8gz
oY5Q1p8J2dqO/kcGflPH
=psod
-----END PGP SIGNATURE-----
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev