|author||127.0.0.1 <127.0.0.1@web>||2016-04-08 14:10:03 +0200|
|committer||amnesia <firstname.lastname@example.org>||2016-04-08 14:10:03 +0200|
Diffstat (limited to 'wiki/src/blueprint/tails_server.mdwn')
1 files changed, 4 insertions, 4 deletions
diff --git a/wiki/src/blueprint/tails_server.mdwn b/wiki/src/blueprint/tails_server.mdwn
index fe09447..355abfa 100644
@@ -4,7 +4,7 @@
# Vision #
-The Tails Server should provide a user-friendly way to start onion services in Tails to facilitate group collaboration, communication and data sharing.
+The Tails Server should provide a user-friendly way to start onion services that facilitate group collaboration, communication, and data sharing.
Such services are immensely helpful for working together in groups over distance. Usually they are hosted centrally by a third party. This comes with several perils: Users have to trust that the service provider protects their information and does not use it for other purposes or disclose it, and the provider poses as a single point of attack for adversaries. In contrast, a self-hosted onion service comes with several advantages:
@@ -15,7 +15,7 @@ Such services are immensely helpful for working together in groups over distance
* It works behind NATs and firewalls
* It limits attack surface
-The Tails Server should be usable via both a graphical user interface (GUI) and a command line interface (CLI) which can be used from within a running Tails session. The CLI solution would make it easy to administrate a Tails Server remotely via SSH.
+The Tails Server should be usable via both a graphical user interface (GUI) and a command line interface (CLI). The interfaces would be used from within a running Tails session (in contrast to the design in the [Legacy Blueprint](#index3h1). The CLI solution would make it easy to administrate a Tails Server remotely via SSH.
Both interfaces should automatically install the services chosen by the user, configure them for the use in Tails and start them. It should be a generic solution which makes it easy to add many different services.
The user should be able to choose:
@@ -29,7 +29,7 @@ In order to achieve this, the following problems have to be solved:
* Design an extendible and robust format describing the services and how they integrate into Tails.
* Installing the server software.
* Settings up the onion service, reusing an existing onion address and keys, if chosen by the user.
-* Persistently storing the data, configuration and onion service data.
+* Persistently storing the data, configuration, and onion service data.
* Integrating into Tails' firewall.
* Presenting the onion address and client credentials to the user in a way that s/he can easily share them with clients.
* Implementing a proper CLI and GUI to configure and activate services.
@@ -70,7 +70,7 @@ The current plan is to have one executable file per service, which must implemen
The CLI will provide a wrapper around these service executables, passing the arguments to the respective service executable. The service executables must provide output in a defined format, which should be easily readable and parsable - currently we plan to use YAML for this.
-The GUI will call the service executables with specific arguments and parse the output to get the information it then displays to the user.
+The GUI will call the service executables with specific arguments and parse the output to get the information it then displays to the user. The same applies to the configuration and actions chosen by the user in the GUI.
# Implementation #
In consideration of the work in progress of porting all Tails shell scripts to Python 3, and the good reasons for this, the Tails Server should also be implemented in Python 3.