summaryrefslogtreecommitdiffstats
path: root/wiki/src/blueprint
diff options
context:
space:
mode:
authorTails developers <amnesia@boum.org>2013-07-18 21:14:11 +0200
committerTails developers <amnesia@boum.org>2013-07-18 21:14:11 +0200
commitba0f4201f0d8d1d63087cf72909ebc43ec84c4d5 (patch)
tree9e4de88be84c136ce592ab57ce3b5a766566a4fe /wiki/src/blueprint
parenta2b7cfc709ce9f38bb4cea766e238962c5ae95ae (diff)
Move blueprints to a dedicated directory.
Diffstat (limited to 'wiki/src/blueprint')
-rw-r--r--wiki/src/blueprint/Add_Gnome_PPP_for_Dial-Up_Users.mdwn144
-rw-r--r--wiki/src/blueprint/Return_of_Icedove__63__.mdwn146
-rw-r--r--wiki/src/blueprint/UEFI.mdwn74
-rw-r--r--wiki/src/blueprint/Wheezy.mdwn48
-rw-r--r--wiki/src/blueprint/accessibility.mdwn73
-rw-r--r--wiki/src/blueprint/automated_builds_and_tests.mdwn133
-rw-r--r--wiki/src/blueprint/better_pidgin_and_otr_documentation.mdwn15
-rw-r--r--wiki/src/blueprint/better_task_manager.mdwn362
-rw-r--r--wiki/src/blueprint/bridge_support.mdwn110
-rw-r--r--wiki/src/blueprint/centralize_Git_repositories.mdwn21
-rw-r--r--wiki/src/blueprint/detect_captive_portals.mdwn69
-rw-r--r--wiki/src/blueprint/easier_YouTube.mdwn56
-rw-r--r--wiki/src/blueprint/find_another_irc_commit_bot.mdwn39
-rw-r--r--wiki/src/blueprint/improve_translators_documentation.mdwn12
-rw-r--r--wiki/src/blueprint/incremental_upgrades.mdwn834
-rw-r--r--wiki/src/blueprint/macchanger.mdwn271
-rw-r--r--wiki/src/blueprint/protect_against_external_bus_memory_forensics.mdwn26
-rw-r--r--wiki/src/blueprint/remember_installed_packages.mdwn98
-rw-r--r--wiki/src/blueprint/replace_truecrypt.mdwn27
-rw-r--r--wiki/src/blueprint/server_edition.mdwn410
-rw-r--r--wiki/src/blueprint/tails-greeter:_revamp_UI.mdwn281
-rw-r--r--wiki/src/blueprint/vpn_support.mdwn60
22 files changed, 3309 insertions, 0 deletions
diff --git a/wiki/src/blueprint/Add_Gnome_PPP_for_Dial-Up_Users.mdwn b/wiki/src/blueprint/Add_Gnome_PPP_for_Dial-Up_Users.mdwn
new file mode 100644
index 0000000..136ff75
--- /dev/null
+++ b/wiki/src/blueprint/Add_Gnome_PPP_for_Dial-Up_Users.mdwn
@@ -0,0 +1,144 @@
+[[!toc levels=2]]
+
+# Rationale
+
+Tails should be usable by those stuck with dial-up Internet access. Recent
+events have shown that in some cases, dial-up might be the last option to
+reach the Internet when broadband operators have been shut down.
+
+This was [[discussed on the forum|forum/GNOME_PPP_for_Dial-Up__63__]].
+
+# Roadmap
+
+**Next thing to do**: make up our mind wrt. towards which one of the
+possible solutions we want to go: [[todo/choose_direction_for_PPP_support]].
+
+Possible solutions:
+
+ * fix [[!debbug 258064]], but GNOME PPP looks dead upstream, so
+ it might be an option to create a custom package handling resolvconf the way
+ we want.
+ * find alternative ways to use WvDial or PPP.
+
+Ideal solution: [[todo/NetworkManager:_PSTN_dial-up]]
+
+# Research
+
+NetworkManager (and ModemManager) have full support for **mobile** modems. But
+nothing for old school dial-up modems at the moment: see [b.g.o #348330 -
+Tracker: Integrated PPP support](https://bugzilla.gnome.org/show_bug.cgi?id=348330)
+
+Fallback option: provide GNOME PPP, a GUI front-end to old but trusty WvDial.
+
+# Dial-up emulation
+
+Here is a method to test dial-up PPP connections without resorting to a real modem
+and a real Internet provider available on the Plain Old Telephony System. It needs
+a system running Tails and another one (the *gateway*) running standard Debian.
+So this requires either two computers in the same LAN or runing Tails using
+virtualization.
+
+1. Prepare the networking stack on the *gateway*:
+
+ # iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
+ # sysctl -w net.ipv4.ip_forward=1
+
+2. In Tails, create `.wvdial.conf`:
+
+ [Dialer Defaults]
+ Baud = 115200
+ Init = ATZ
+ Init2 = AT%R1
+ Phone = 192.168.1.2:6789
+ Username = test
+ Password = test
+ Carrier Check = off
+
+ Replace the IP address in `Phone` with the IP address of the other system.
+
+3. In Tails, install the `modemu` package.
+
+4. In Tails, remove the default route to let room for the one provided by PPP:
+
+ # ip route del default
+
+5. On the *gateway* run:
+
+ # pppd noauth local lock nodefaultroute persist debug nodetach 10.1.2.3:10.4.5.6 pty "nc -l 6789"
+
+6. And fairly quickly (before `pppd` times out), run on Tails:
+
+ $ sudo modemu -c 'ln -nsf %s /dev/modem ; wvdial -C .wvdial.conf'
+
+Repeat the last two steps if the connection is broken at some point.
+
+# PPPoE emulation
+
+To ensure that PPPoE (broadband DSL) support is not broken by tweaks
+to PPP configuration files, here is a test procedure. This needs
+a standard Debian system (the *gateway*), and either a spare wired network card
+or using virtualization.
+
+This reciepe uses `kvm`, but could be easily adapted to other setups:
+
+1. On the *gateway*, install the `pppoe` package.
+2. On the *gateway*, create `/etc/ppp/pppoe-server-options`:
+
+ debug
+ noauth
+ lcp-echo-interval 10
+ lcp-echo-failure 2
+ ms-dns 8.8.8.8
+ defaultroute
+ noipdefault
+
+3. Start KVM, adding those arguments: `-net nic,model=virtio -net tap,ifname=tails`.
+4. On the *gateway*, *up* this interface:
+
+ # ip link set tails up
+
+5. On the *gateway*, start the PPPoE server:
+
+ # sudo pppoe-server -I tails -F -S test -m 1412
+
+6. On Tails, you can now right-click the NetworkManager icon, and select
+ *Edit connections...*. In the *DSL* tab, click *Add*. *Service name*
+ should be set to `test`. Other settings should not matter.
+
+7. On Tails, left-click the NetworkManager icon and selection the newly
+ created connection.
+
+To debug, use `tcpdump`, and look at `/var/log/syslog`.
+
+# Implementation
+
+## GNOME PPP
+
+As WvDial (and thus GNOME PPP) is not integrated with NetworkManager in any
+way, the hooks in `/etc/NetworkManager/dispatcher.d` are not normally run upon
+connection.
+
+They will be after adding the following script as
+`/etc/ppp/ip-up.d/010call-nm-hooks`:
+
+ #!/bin/sh
+
+ run-parts --regex='^[a-z0-9-]+(\.sh)?$' /etc/NetworkManager/dispatcher.d --arg="$1" --arg="up"
+
+But this will probably has the undesired effect of calling NetworkManager
+hooks twice when using PPPoE. This does not look like a real issue, but Tor
+is still restarted twice which is not nice.
+
+Answer to this problem is fairly simple: when using WvDial with a good ol'
+modem, a `SPEED` environment variable is defined when `01call-nm-hooks`
+runs. Let's simply use this to determine if we should run NetworkManager hooks
+manually.
+
+Remaining issues:
+
+* `gnome-ppp` conflicts with `resolvconf`, see [[!debbug 258064]].
+* Clarify what groups must the user be part of to run wvdial /
+ gnome-ppp? We've been told [[on the
+ forum|forum/GNOME_PPP_for_Dial-Up__63__#comment-9b26e5014164c5ff0ebd3cc3223f6301]]
+ the answer was `dialout` (which is already the case) and `dip`
+ (which is not).
diff --git a/wiki/src/blueprint/Return_of_Icedove__63__.mdwn b/wiki/src/blueprint/Return_of_Icedove__63__.mdwn
new file mode 100644
index 0000000..26e798e
--- /dev/null
+++ b/wiki/src/blueprint/Return_of_Icedove__63__.mdwn
@@ -0,0 +1,146 @@
+[[!toc levels=3]]
+
+Rationale
+=========
+
+Pros
+----
+
+* Icedove has a *much* easier guide for setting up an email account -- just enter a name, email address and password, and Icedove will check if the domain of it has IMAP (preferred) or POP, and SMTP, and set up an account correctly and automatically, beginning with trying SSL/STARTTLS so no login credentials are unnecessarily leaked. Claws is pretty much impossible to setup for normal people, but seeding the config could make that easier, but will it be as easy?
+* Enigmail has a *much* easier guide for generating a key and setting up GnuPG. The guide starts pretty much automatically and is very informative.
+* Icedove is more widely used, so it's less fingerprintable and perhaps familiar to more users. This (and its larger development team) also likely results in earlier bug fixes.
+
+Cons
+----
+
+* It will be somewhat harder to implement the [[todo/easy_MUA_configuration]] with Icedove compared to claws. That would allow us some flexibility for our use case, e.g. specific recommendations w.r.t. anonymity.
+* Icedove's automatic account creation process will fallback to plaintext POP/IMAP/SMTP if SSL/STARTTLS fails. That could result in leaks of login/password in many circumstances, like if the user types the wrong domain in the email address. I can't seem to find any options to disallow plaintext, although mail.smtp.ssl=2 (must use SSL) seems interesting (haven't found anything for POP/IMAP though).
+* Icedove requires an additional ~20 MB uncompressed space over claws.
+* Icedove probably has more bugs given its code size.
+
+I think implementing the [[todo/easy_MUA_configuration]] is pretty far from trivial, at least if we want it to be as easy as Icedove's account creation guide, which brings that whole idea into question. Maybe a better approach would be to write an addon for Icedove that alters the account creation process (if that is possible -- I have no insight in how much addons can do)? It'd give the user some use case specific information, e.g. to not use a non-anonymous email account, and also implement the other ideas from [[todo/easy_MUA_configuration]]. And it would disallow plaintext plaintext POP/IMAP/SMTP.
+
+Roadmap
+=======
+
+1. List blockers (from the *Things to implement* list bellow).
+1. Implement blockers.
+1. Write design documentation.
+1. Adapt [[end-user documentation|doc/anonymous_internet/thunderbird]]
+ from Incognito.
+
+Design decisions
+================
+
+* Follow the suggestions in [tagnaq's paper](http://bit.ly/qDZm7C)
+ as much as possible. We'll likely ignore some impractical stuff
+ like using PGP-inline instead of PGP/MIME.
+
+* Our Iceweasel says it prefers English. It does not try to pretend it
+ has no locale. Our Icedove shall do the same. So we will keep
+ `mailnews.reply_header_authorwrote` default value (that is, `%s
+ wrote` and will ignore tagnaq's suggestion on this; details: [doc on
+ reply_header_](http://kb.mozillazine.org/Reply_header_settings)
+
+Things to implement
+===================
+
+TorBirdy
+--------
+
+### Plans
+
+See tickets on [[Redmine|todo/Return of Icedove?]].
+
+### Design
+
+[TorBirdy](https://github.com/ioerror/torbirdy) ([Design
+goals](https://trac.torproject.org/projects/tor/raw-attachment/wiki/doc/TorifyHOWTO/EMail/Thunderbird/Thunderbird%2BTor.pdf))
+aims to take care of (among other things):
+
+* Enhance the privacy of the emails (prevent email header information
+ leaks)
+* Protect against all kinds of HTML issues
+* Support Tor's prop 171 (stream isolation via per-account proxy
+ settings)
+* Mixmaster/Mixminion integration.
+
+All these seem terrific, so this is something we definitely want to
+include.
+
+Spoof or remove User-Agent header
+---------------------------------
+
+Maybe done by Torbirdy, see tickets on [[Redmine|todo/Return of
+Icedove?]].
+
+Modified autoconfig wizard
+--------------------------
+
+This was implemented in the `secure_account_creation` branch in that
+Git repository: `git://labs.riseup.net/tails_icedove.git`.
+
+### Plans
+
+See tickets on [[Redmine|todo/secure_Icedove_autoconfig_wizard]].
+
+### Design
+
+In order to mitigate the concern's raised by tagnaq about Icedove's
+autoconfig wizard, the following changes has been made to it:
+
+* When probing a mail provider for an xml config, first try HTTPS,
+ then http (old behaviour: http only).
+* Introduce a boolean pref called `mailnews.auto_config_ssl_only`
+ (that has a checkbox in the autoconfiguration wizard) that does the
+ following when true:
+ - Only allow HTTPS when fetching xml configs from mail provider.
+ - Only allow HTTPS when fetching xml configs from Mozilla's database
+ (luckily the default URL *is* using HTTPS).
+ - Don't check DNS MX records for mail configurations. This may need
+ some rethinking for DNSSEC.
+ - Only accept fetched xml configs that use safe email protocols
+ (SSL/TLS for SMTP/IMAP/POP).
+ - Only probe the mail server for safe protocols (SSL/TLS for
+ SMTP/IMAP/POP).
+
+To prevent TorBirdy from disabling the autoconfig wizard, we set the
+`vendor.name` Icedove pref to `Tails`.
+
+Basic configuration & integration
+---------------------------------
+
+* Use `127.0.0.1:9061` SOCKS proxy.
+* Don't display the "Adblock Plus installation complete" tab.
+* Don't prompt whether one wants to report usage and performance
+ information to Mozilla.
+* Disable FoxyProxy.
+* Enable "Only use secure protocols" by default (one may still
+ uncheck it when needed).
+* Don't check updates for Add-ons.
+* Add launcher to the GNOME panel.
+* More generally: have a look at our Iceweasel prefs and copy all
+ those that exist and make sense for Icedove.
+* The [[security/IP_address_leak_with_icedove]] can be fixed by
+ setting `mail.smtpserver.default.hello_argument` to "localhost".
+ See [this Tor wiki
+ entry](https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorifyHOWTO/EMail#ExperimentalSuggestionsforpossiblymakingthunderbirdandorclawsstopleakinginfoExperimental)
+ for other goodies. By applying those configurations I think both
+ claws and icedove comes to an equal level security-wise.
+* Disable by default the indexer from
+ `Preferences -> Advanced -> General -> Enable Global Search and Indexer`.
+ Otherwise pinentry dialogs can appear while checking email in the
+ background.
+
+Resources
+=========
+
+* [tagnaq's paper](http://bit.ly/qDZm7C)
+* how well are Enigmail, Icedove and l10n packages maintained in
+ Debian? -> seems acceptable - I've seen much worse times, especially
+ for this set of packages.
+* how much size does Icedove + Enigmail + l10n packages add to the
+ SquashFS compared to Claws Mail? -> *9MB* (as of Tails pre-0.8 devel
+ branch with XZ SquashFS compression)
+
+[[!tag priority/high]]
diff --git a/wiki/src/blueprint/UEFI.mdwn b/wiki/src/blueprint/UEFI.mdwn
new file mode 100644
index 0000000..2098817
--- /dev/null
+++ b/wiki/src/blueprint/UEFI.mdwn
@@ -0,0 +1,74 @@
+For Tails [[!taglink release/2.0]], we want at least basic UEFI boot
+including Mac.
+
+Some hardware ([[bugs/ThinkPad_X220_vs_GPT]], recent Mac) cannot boot
+Tails from USB, due to firmware limitations. Making Tails support UEFI
+would fix this problem on such hardware.
+
+* Mike Hommey's
+ [Debian EFI mode boot on a Macbook Pro, without rEFIt](http://glandium.org/blog/?p=2830)
+* Steve McIntyre's EFI installation progress:
+ - [[!debpkg debian-cd]] 3.1.11 has x86 EFI support, see the
+ `debian/changelog` for details
+ - [fourth](http://blog.einval.com/2012/09/03#Debian_EFI_4) (2012-09-03)
+ - [third](http://blog.einval.com/2012/08/24#Debian_EFI_3)
+ - [second](http://blog.einval.com/2012/08/22#Debian_EFI_2) (2012-08-22)
+ - [first](http://blog.einval.com/2012/08/12#Debian_EFI) (2012-08-12)
+* <https://lists.debian.org/debian-devel/2012/01/msg00168.html>
+* [Debian: switch to UEFI boot](http://tanguy.ortolo.eu/blog/article51/debian-efi)
+* [[!debbug 658352]] about adding UEFI support to Debian CDs
+* a recent snapshot of Liberte Linux has added UEFI support
+* the [SprezzOS](http://www.sprezzatech.com/sprezzos.html)
+ Debian derivative is [working on this](https://github.com/dankamongmen/SprezzOS/wiki/Installer) too:
+ - [bug 11](https://www.sprezzatech.com/bugs/show_bug.cgi?id=11)
+ - [bug 104](https://www.sprezzatech.com/bugs/show_bug.cgi?id=104)
+* rEFIt developer, Rod Smith, may be willing to help:
+ [[forum/Boot_fails_from_usb_thumb_drive_on_Macbook_Pro]]
+* ArchLinux' page about
+ [UEFI Bootloaders](https://wiki.archlinux.org/index.php/UEFI_Bootloaders)
+* syslinux 6 will have UEFI support (status as of January 2013: alpha
+ is available). Debian Live's UEFI support will be based on it.
+* Kanotix, based on Debian Live and GRUB2, has a isohybrid setup that
+ allows "multi-hybrid booting" as CD-ROM (EFI or El Torito) or as
+ a hard-drive (e.g. a USB pendrive) on Intel-Macs (EFI) and PCs (EFI
+ or MBR). [See
+ details](https://mailman.boum.org/pipermail/tails-dev/2013-February/002587.html).
+
+Debian's Linux 3.2 kernel has "UEFI stub" support, which
+allows it to be started directly since the EFI boot menu.
+
+Matthew Garrett:
+
+* [Secure Boot bootloader for distributions available now](http://mjg59.dreamwidth.org/20303.html)
+* [Getting started with UEFI development](http://mjg59.dreamwidth.org/18773.html)
+* detailed [the ISO images for Fedora 17 installation
+ CD](http://mjg59.dreamwidth.org/11285.html) and [their Mac
+ support](http://mjg59.dreamwidth.org/12037.html): it supports BIOS,
+ UEFI, Mac platforms when burned to a CD or written directly to a USB
+ stick. This might be nice for the ISO that Tails distribute, but not
+ applicable to support USB sticks with incremental updates.
+* [An overview of Fedora's Secure Boot implementation](http://mjg59.dreamwidth.org/18945.html)
+
+More technical details:
+
+ * <http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/doc/boot_sectors.txt#L398>
+
+There is then two big area that needs work to support EFI:
+
+ * ISO images need to support EFI, both for DVD and when [[dumped on USB
+ sticks|contribute/design/hybrid_ISO]]. A work similar to the one done by
+ Matthew Garrett on Fedora 17 should probably be done [[!taglink
+ todo/upstream]] in [live-build](http://live.debian.net/).
+ * The [[USB installer|contribute/design/usb_installation]] needs to
+ setup the partition table and system partition in a way that can boot
+ on both BIOS and UEFI systems. Proper Mac support would be a nice bonus.
+
+Later
+=====
+
+Secure Boot
+-----------
+
+* Matthew Garrett's [Handling UEFI Secure Boot in smaller distributions](http://mjg59.dreamwidth.org/17542.html)
+
+[[!tag priority/high]]
diff --git a/wiki/src/blueprint/Wheezy.mdwn b/wiki/src/blueprint/Wheezy.mdwn
new file mode 100644
index 0000000..432d7fe
--- /dev/null
+++ b/wiki/src/blueprint/Wheezy.mdwn
@@ -0,0 +1,48 @@
+We need to start porting Tails to Wheezy, and test it.
+
+Work is done in the `feature/wheezy` Git branch.
+
+**Current state** (2013-06-30): builds, boots. Quite some things are
+broken, and many minor features had to be disabled to workaround
+build issues.
+
+[[!toc levels=2]]
+
+Research to do
+==============
+
+[[!tag todo/research]]
+
+Windows Camouflage
+------------------
+
+How to implement the Windows Camouflage mode in GNOME3 "Classic" (aka.
+fallback) mode?
+
+* Ubuntu's GNOME Classic is not that far from a good old GNOME2 DE:
+ https://help.ubuntu.com/community/PreciseGnomeClassicTweaks
+* The default theme (`/usr/share/themes/Adwaita/gtk-3.0/`) can be
+ forked and customized.
+* GTK3 Windows-like themes seem to be
+ [in the works](http://blogs.gnome.org/alexl/2012/03/27/moar-windows-themes/),
+ and <http://gnome-look.org/> has a few ones.
+* some [customization tips](http://askubuntu.com/questions/69576/how-to-customize-the-gnome-classic-panel)
+
+What works
+==========
+
+* Reading (IMAP) and sending email with Claws.
+* OpenPGP applet symmetric enc/dec
+* Roundcube webmail
+* MAT cleans a PDF
+* Erase memory on shutdown
+* USB installer (Clone & Install)
+* Iceweasel/torbrowser works
+* FTP works on LAN in Nautilus
+* Streaming in Totem
+* Unlocking and using already created persistence
+* Tails-additional-software works
+* Unsafe browser
+* Orca
+
+[[!tag release/1.1]]
diff --git a/wiki/src/blueprint/accessibility.mdwn b/wiki/src/blueprint/accessibility.mdwn
new file mode 100644
index 0000000..3fb0add
--- /dev/null
+++ b/wiki/src/blueprint/accessibility.mdwn
@@ -0,0 +1,73 @@
+[[!toc levels=2]]
+
+# Rationale
+
+Tails should be usable by every [[target user|contribute/design]],
+regardless of their abilities or inabilities. Only other key
+requirements of [[Tails design|contribute/design]] (such as Free
+Software and maintainability) shall limit this one.
+
+Tails therefore needs to ship with accessibility technologies.
+
+# Enabling accessibility features
+
+These accessibility tools could be enabled at boot time by people who
+need it, by passing `access=` option(s) to live-boot:
+
+ access=ACCESS
+ Set the accessibility level for physically or visually
+ impared users.
+ ACCESS must be one of v1, v2, v3, m1, or m2. v1=lesser
+ visual impairment, v2=moderate visual impairment,
+ v3=blindness, m1=minor motor difficulties, m2=moderate motor
+ difficulties.
+
+We might want to use the syslinux boot menu to enable accessibility features.
+
+However, live-boot 3.0~a27-1 removed this feature: "Removing outdated
+and broken accessibility script, this will be redone in
+live-config properly." This did not happen upstream.
+
+# Visual
+
+Orca does not work with iceweasel yet. Also think of the Unsafe Browser.
+
+# Motor
+
+live-boot's `access=m1` and `access=m2` options enable various GNOME
+options suitable for people having motor difficulties. This might be
+enough.
+
+We also probably want to install the `dasher` graphical predictive
+text input system, that adds eyetracking into the mix. It brings 10MB
+.deb files in: [[todo/install_dasher]].
+
+# Resources
+
+* [[!debwiki accessibility-devel]]
+* [[!debwiki accessibility]]
+
+# Archive: discarded tools
+
+## Compiz
+
+We have been told that Compiz is the preferred accessibility solution
+for some people with sight impairment; such features Compiz includes are:
+
+- inverting colors: good for the color blind or those who need better
+ contrast
+- looking glass: (small area of screen enlarged) good for those who
+ still like to see the whole desktop while working. This one provides
+ some nice graphics too.
+- magnifier: like looking glass but without the other graphics
+- sharpen: makes the entire desktop look sharper for better readability
+- track mouse: (very helpful) it is very easy for a sight impaired
+ person to loose their mouse. this feature helps prevent that. This
+ is much clearer cut than the mouse tracking in gnome-mag.
+- zoom: magnify the entire desktop
+
+On the other hand, Compiz requires modern graphics hardware, seems
+pretty hard to get working on Debian Squeeze, and won't be in Wheezy
+=> discarded.
+
+[[!tag priority/normal]]
diff --git a/wiki/src/blueprint/automated_builds_and_tests.mdwn b/wiki/src/blueprint/automated_builds_and_tests.mdwn
new file mode 100644
index 0000000..dbc6085
--- /dev/null
+++ b/wiki/src/blueprint/automated_builds_and_tests.mdwn
@@ -0,0 +1,133 @@
+[[!meta title="Automated builds and tests"]]
+
+[[!toc levels=2]]
+
+Rationale
+=========
+
+An automated build and test environment would be pretty useful to
+ensure a few facts:
+
+- new code does not break anything
+- new build tools (`live-build`) and included software
+ (`live-config`, `live-boot`) don't break anything
+- updates pushed to the APT repositories we don't control (e.g. Debian's)
+ don't break anything
+- the quality of our releases is good enough
+- power users get to test early images built from feature branches,
+ or from `experimental`
+- we can ask bug reporters to test an image built from a bugfix
+ branch, and see if it fixes their problem
+
+What we have
+============
+
+* An unconfigured Jenkins instance running on lizard.
+* A partially automated test suite:
+ - [[documentation|contribute/release_process/test/automated_tests]]
+ - [[setup|contribute/release_process/test/setup]]
+ - [[usage|contribute/release_process/test]]
+ - [[test cases|contribute/release_process/test]] that are not
+ implemented yet.
+
+Roadmap
+=======
+
+0. Complete phase one (**build and publish ISOs automatically**):
+ fix all child tickets of
+ [[todo/automated_builds_and_tests:_complete_phase_one]].
+0. Create tickets for the next phase.
+0. Setup notifications:
+ a. Setup email notifications.
+ a. Setup IRC notifications (see [[resources|automated builds and tests/jenkins]]).
+0. Build Debian packages for our custom programs:
+ a. Setup [jenkins-debian-glue](http://jenkins-debian-glue.org/).
+0. Run our various [[custom programs|contribute/git]]' test suite
+ (see the section about Perl projects on [[automated builds and tests]])
+ a. set up a `perl-tester.lizard` Jenkins slave
+0. Add more Jenkins jobs such as:
+ - check PO files [[validity with
+ i18nspector|contribute/l10n_tricks]]
+ - automated test suite
+0. Think through a plugins upgrade policy, create tools if needed.
+0. Make our Jenkins visible and read-only on the web.
+0. Start/stop `builder.lizard` before/after building an ISO.
+
+What we need
+============
+
+Automated builds
+----------------
+
+Ideally, every commit pushed to Git should result in an ISO being
+built, and made available online.
+
+Automated tests
+---------------
+
+Ideally, every automatically built ISO should be automatically tested,
+and the results displayed online.
+
+Infrastructure
+--------------
+
+Putting automatic builds and automatic tests on the same physical
+machine (while using
+virtualization to separate concerns) saves hosting and bandwidth costs:
+fresh images can be tested without being transferred.
+
+In order to be able to build Tails in memory (which greatly speeds up builds)
+and to properly test HIGHMEM memory wipes, the test server should have at
+least 32 GB. Using KVM inside a KVM
+virtual machine is supported by the "nested KVM" feature available since
+Linux 3.1. VirtualBox (Vagrant) in KVM is not supported as of March 2013.
+
+We could set a threshold of tests that have to be successful before publishing
+one daily build image. This would prevent too-broken images to spread out and
+potentially harm users.
+
+The setup of the automated build and test server should be done
+with public Puppet modules.
+
+Resources
+=========
+
+## Jenkins
+
+See [[our wiki page|automated builds and tests/jenkins]] dedicated to Jenkins.
+
+## Testing tools and examples
+
+- <http://live.debian.net/gitweb/?p=live-autobuild.git> is currently
+ used to build "official" daily Debian Live images
+- [buildbot](http://buildbot.net) : a continous integration bot, able to
+ communicate over mail or IRC. Used by many projects.
+- Tor project's [buildbot configuration](https://gitweb.torproject.org/admin/buildbot-conf.git)
+- Martin Pitt
+ [announces](http://www.piware.de/2013/02/umockdev-record-and-mock-hardware-for-debugging-and-testing/)
+ umockdev ([source code](https://github.com/martinpitt/umockdev)),
+ a set of tools to record and mock hardware for debugging and testing
+
+## emulated boot from USB
+
+See [[the page that's dedicated to that|automated_builds_and_tests/USB]].
+
+## Buildbot
+
+We [[used to have a buildbot setup|todo/automated_builds_and_tests/buildbot]].
+
+Buildbot can be seen as a [framework](http://jacobian.org/writing/buildbot/) to
+deploy continuous integration. It has no real configuration file, but
+what deserves this role is a file that can be thought programatically.
+Thus it provide a very flexible environment that can be customize for
+most projects needs.
+
+Some interesting pages, might be worth reading for people willing to
+play with buildbot and understand its logic :
+
+* [Chromium's buildbot config](http://src.chromium.org/viewvc/chrome/trunk/tools/build),
+ which is the one driving their [builbot instance](http://build.chromium.org/)
+* [Buildbot's documentation](http://buildbot.net/buildbot/docs/latest/)
+
+[[!tag category/continuous_integration]]
+[[!tag release/2.0]]
diff --git a/wiki/src/blueprint/better_pidgin_and_otr_documentation.mdwn b/wiki/src/blueprint/better_pidgin_and_otr_documentation.mdwn
new file mode 100644
index 0000000..141533a
--- /dev/null
+++ b/wiki/src/blueprint/better_pidgin_and_otr_documentation.mdwn
@@ -0,0 +1,15 @@
+The [[documentation about Pidgin and OTR|doc/anonymous_internet/pidgin/]] should be improved.
+
+Pidgin
+======
+
+- [[todo/mention_IRC_channel_in_Pidgin_documentation]]
+- [[todo/document_the_random_nick_preset]]
+
+OTR
+===
+
+- [[todo/better_link_to_the_OTR_homepage]]
+- [[todo/integrate_with_external_OTR_documentation]]
+
+[[!tag priority/normal]]
diff --git a/wiki/src/blueprint/better_task_manager.mdwn b/wiki/src/blueprint/better_task_manager.mdwn
new file mode 100644
index 0000000..c35eda0
--- /dev/null
+++ b/wiki/src/blueprint/better_task_manager.mdwn
@@ -0,0 +1,362 @@
+Our current approach to managing Tails [[!tails_todo "" desc="todo"]]
+does not scale. We have some ideas to improve it slightly, but it's
+unlikely the result will be good enough, so we will instead migrate
+to Redmine.
+
+[[!toc levels=2]]
+
+# Roadmap
+
+* [[!tag todo/code]] write a conversion script to import our existing
+ tickets (see *Convert and import* section below).
+* update developers documentation
+* migrate!
+ - import existing tickets
+ - setup rewrite rules from the ikiwiki tickets URL to the new ones
+ - remove tickets that are not blueprints from ikiwiki
+* If needed, have additional plugins packaged and installed to fine
+ tune our processes.
+
+# Wiki / Tasks
+
+Let's keep our wiki for blueprints and research for long-term big next
+features.
+
+Let's try not to use the wiki for tasks (else it defeats the purpose of
+tracking tasks), let's not try to use the tasks manager for research and other
+things that would be better suited for the wiki (else it harms mostly-offline
+developers).
+
+# Specifications
+
+## Must have
+
+ * Should have categories (and display the related tasks in a meaningful way).
+ => Redmine, bugs-everywhere
+ * Should let us assign tasks to individuals
+ => bugs-everywhere
+ * Can handle tasks and sub-tasks
+ => Redmine, bugs-everywhere
+ * Create tickets over email.
+ => Redmine, bugs-everywhere
+ * Reply to tickets over email.
+ => Redmine, bugs-everywhere
+ * Being able to search through tickets offline (caching).
+ Ability to import a DB dump into a local instance of the webapp would be
+ an acceptable way to do it, even if clearly suboptimal.
+ => bugs-everywhere
+ * Email notifications: subscribing to a ticket, or to new tickets, etc.
+ => Redmine (for existing tickets), bugs-everywhere
+ * Advanced search queries, or filters (among metadata)
+ (roadmap, milestone, overview, individual dashboard)
+ => Redmine
+ * Hosted somewhere else **or** fully available in Debian
+ (or all deps in Debian? to be discussed if need arises.)
+ => Redmine (Riseup Labs & in a little bit outdated Debian),
+ bugs-everywhere (needs some care)
+ * milestones (target version)
+ => Redmine, bugs-everywhere
+ * Random users may reply to tasks.
+ => bugs-everywhere
+
+## Important
+
+ * Blocking property
+ => Redmine, bugs-everywhere
+ * Change a ticket's metadata via email.
+ => Redmine, bugs-everywhere
+ * Due time, deadlines
+ => Redmine (with email reminders), bugs-everywhere
+
+## Bonus
+
+ * Having tags
+ => bugs-everywhere
+ * Possible to assign tasks to a team / to multiple people
+ * Sub-tasks having precedence support or wait state or something that makes
+ the "let's create all future sub-tickets for a task at the same time"
+ workflow practically doable (i.e. I don't want to be shown all future steps
+ that are blocked by the first one)
+ * Possible to change a ticket's state from Git commit messages (todo->pending),
+ bonus points if merging that branch into stable ->done, or something like
+ that.
+ * Reminder for deadlines.
+
+## Unsorted
+
+ * Encryption support.
+
+# Redmine
+
+* [homepage](http://www.redmine.org)
+* easy to setup thanks to the Debian package
+* supports [issue creation or comments via
+ email](http://www.redmine.org/projects/redmine/wiki/RedmineReceivingEmails),
+* supports [updating ticket attributes over
+ email](https://we.riseup.net/cgdev/using-email-with-redmine#sending-emails)
+* the email interface, according to someone I trust who set it up and
+ uses it, is quite fragile and can be a bit mysterious to setup
+* apparently, there no more powerful way to interact with it
+ asynchronously ([feature request for offline
+ mode](http://www.redmine.org/issues/2728))
+* Textile syntax. Pandoc knows how to convert our existing Markdown to
+ Textile, but still, having Markdown support would be awesome.
+* Git integration won't easily work with our many-branches workflow,
+ but we can probably do without for a while.
+
+## Plugins of interest
+
+* Markdown syntax.
+ A blocker is that each such plugin switches the syntax
+ instance-wide, no way to enable it for a single project.
+ - [redcarpet formatter](https://github.com/alminium/redmine_redcarpet_formatter)
+ In Debian unstable ([[!debpkg redmine-plugin-markdown]]).
+ Marked as compatible with 1.x and 2.x,
+ but the packaged version is the one for 2.x.
+ Depends on [[!debpkg ruby-redcarpet]] that is in Wheezy, but not
+ in Squeeze, and may be a pain to backport due to a few missing build-deps.
+ - [Markdown formatter](https://github.com/bitherder/redmine_markdown_formatter)
+ Depends on [[!debpkg ruby-rdiscount]] that is in Wheezy, but not
+ in Squeeze, and a pain to backport (due to the gem2deb (>=
+ 0.3.0~) dependency). Untouched since 2010.
+ - [Markdown Extra formatter](https://github.com/juno/redmine_markdown_extra_formatter/tree)
+ Depends of [BlueFeather
+ gem](http://ruby.morphball.net/bluefeather/index_en.html) that is
+ not in Debian. Untouched since 2010.
+* [Carousel](http://www.redmine.org/plugins/redmine_carousel): can be used
+ for periodic actions that occur during project development process. It
+ automatically generates issue assigned to the next user in the carousel
+ queue every specified time period. Marked as compatible with 1.1.x
+ and 1.4.x.
+ > Looks interesting, but most (if not all) tasks we do switches for
+ > depend on our availability etc., so I'm not sure an automated
+ > solution would do. --intrigeri
+* [Digest](http://www.redmine.org/plugins/digest): send a summary of a
+ project's activity over a period of time by email. Marked as
+ compatible with 1.4.x and 2.0.x. The [sample email
+ output](https://github.com/drewkeller/redmine_digest/blob/master/screenshot_emailoutput.png)
+ does not make me think this is any better than some way (feed
+ reader or rss2email) to subscribe to the project's activity.
+* [Importer](http://www.redmine.org/plugins/importer): import issues in bulk
+ from .csv files. Compatible with 1.1.x. We do need this to import
+ existing tickets.
+ A [fork](https://github.com/ksauzz/redmine_importer/tree/redmine2.x)
+ supports Redmine 2.x.
+* [Issue checklist](http://www.redmine.org/plugins/issue_checklist):
+ add checklist functionality to issues. Marked as compatible with
+ 2.0.x -- what about 1.4.x or older? Having something lighter than
+ sub-tickets could be good, but certainly not critical. We'll see.
+* [Git branch hook](https://github.com/mikoto20000/redmine_git_branch_hook):
+ add issue related revision by branch name. Can close tickets
+ on merge. One apparently may configure the branch that, when
+ merged into, triggers this behavior, thanks to the
+ `merge_branch` setting. Apparently impossible to use it for
+ the two-steps pending + fixed workflow we've been using,
+ but we may want to change this when switching tools anyway.
+ According to Git log, should at least support Redmine 1.4.x and
+ 2.0.x.
+ We can start using Redmine and see later how much we need something
+ like this.
+* [Silencer](http://www.redmine.org/plugins/silencer): suppress email
+ notifications (at will) when updating issues. Marked as
+ compatible with 1.1.x, not with 1.4.x.
+ > I'm not sure why we would want this. --intrigeri
+* [Whining](http://www.redmine.org/plugins/redmine_whining): email alerts
+ when an issue had not been updated since X days. Marked as
+ compatible with 1.1.x, not with 1.4.x.
+ Would be very useful, looks easy to package and install.
+* [Custom Workflows](http://www.redmine.org/plugins/custom-workflows):
+ define own rules of issue processing, e.g. change issue properties
+ or create sub-task if some conditions are met, enforce policies...
+ Marked as compatible with 1.2.x to 2.1.x.
+ Hopefully we won't need it, but it's still good to know it
+ exists.
+
+## Offline usage
+
+ * Sending an email can create an issue with:
+ - subject: mail subject
+ - description: mail body
+ - tracker: keyword (`Tracker:`) in mail body
+ - priority: keyword (`Priority:`) in mail body
+ - status: keyword (`Status:`) in mail body
+ - category: keyword (`Category:`) in mail body
+ - assignee: keyword (`Assigned To:`) in mail body
+ - kind of next thing to be done: keyword in mail body
+ - target version: keyword (`Fixed version:`) in mail body
+ - QA check (or any other custom field): keyword (name of the
+ custom field) in mail body
+ * Sending an email with '[#24175]' in the subject will add
+ information to the ticket. Same keywords as before can be used to change
+ metadata.
+ * Email address in From, To, or Cc are added to watchers (if they match
+ a Redmine user) when *creating* a new ticket over email.
+ * Clicking on *Watch* enables one to receive emails when the ticket changes.
+ * Every ticket has an Atom feed that contains all changes made to a ticket.
+ * There is an Atom feed with all open tickets, together with status and
+ description.
+ * Missing: set parent task, set related issues, delete ticket.
+
+## Convert and import
+
+**Note**: this is an initial rough draft, that probably misses tons of
+things to do, but should be enough to run some initial tests to
+confirm the general idea is workable.
+
+### Set up Redmine
+
+1. **done** Add a `External Id` custom field. Check "Used as a filter".
+1. **done** Add a `QA Check` custom field. Make it searchable.
+1. **done** Add a `Type of work` custom field whose possible values
+ are the same as our current `todo/*` tags:
+ Code
+ Discuss
+ Documentation
+ Pass Test
+ Promote
+ Qa
+ Research
+ Sysadmin
+ Test
+ Translate
+ Upstream
+ Wait
+ Website
+ Mark it as "used as a filter" and searchable.
+1. **done** Add a `Blueprint` text custom field, with regexp `^https://tails[.]boum[.]org/blueprint/`.
+1. **done** Add a `Fix committed` issue status.
+1. **done** Make the `Fix committed` status available in Administration -> Workflow.
+1. **done** Add a `Confirmed` issue status.
+1. **done** Make the `Confirmed` status available in Administration -> Workflow.
+1. **done** Mark the `Resolved` issue status as "Issue closed".
+1. **done** Add an `Elevated` issue priority, rank it between Normal and High.
+1. **done** Add a `Feature branch` custom field to ease review.
+
+### Adapt impacted stuff
+
+1. **done** Prepare a branch that updates the website to advertise the new task
+ manager instead of the old one.
+1. Generate the Apache rewrite rules from the (External Id, Redmine
+ Id) mapping.
+ (`PRODUCTION=1 make rewrite-rules` should do the job.)
+
+### Clean up and gather data
+
+1. **done** Close wishlist tickets not modified since more than a year.
+1. Split tickets that have several `todo/*` tags, and save the
+ parent/child relationship using `[[!parent]]`. In the end, each
+ ticket should only have one `todo/*` tag:
+
+ PRODUCTION=1 make list-more-than-one-todo-tag
+
+1. Write a custom ikiwiki plugin to:
+ - **done** save original ikiwiki ticket name as `External Id` column
+ - **done** save parent/child relationship
+ - **done** wrap the whole ticket information into a CSV line
+ - **done** filter out `toc`
+ - **done** save `todo/*` tags into the "Type of work" column
+ - **done** save `release/1.0` and `todo/2.0` tags into the "Fixed
+ version" column, ditto for broken windows
+ - **done** turns `todo/qa` into `QA Check` == `Ready for QA`.
+ - **done** convert ikiwiki shortcuts to external links
+ - **done** turn internal links to non-todo pages into external links
+ - **done** convert Markdown to Textile
+ - **done** removes links to wishlist
+ - **done** converts TOC directive into Redmine's syntax
+ - **done** drops obsolete taglinks
+ - **done** import `priority/*` tags
+ - **done** import `category/*` tags
+ - **done** feed the blueprint custom field with the URL to the
+ relevant blueprint, if any
+
+### Freeze and import data
+
+1. Run ikiwiki with this special plugin, then merge all these CSV
+ lines to produce a first CSV file that can be imported with the
+ Importer plugin.
+
+ PRODUCTION=1 make export1.csv
+
+1. Import the first CSV file:
+ * use an account that has Manager privs on the current project
+ * ignore `Parent Issue` fields
+1. Import this CSV file again to apply the relationships:
+ * use an account that has Manager privs on the current project
+ * use `External Id` as `Unique Column`
+ * check "Update existing issues"
+1. Build a (External Id, Redmine Id) mapping
+
+ PRODUCTION=1 make ids.map
+
+1. With a modified version of the ikiwiki plugin, plus this mapping
+ information, produce a second CSV files with tickets description
+ modified so that links to other tickets are updated to use Redmine
+ ticket linking syntax.
+
+ PRODUCTION=1 make export2.csv
+
+1. Import the second CSV file, using `External Id` as `Unique Column`
+ again, and enabling the *Update Existing Issues* option.
+ Links between tickets should now be good.
+
+### Polish imported data and update the rest of the world
+
+1. Mangle the content of the Git repository:
+ * Move blueprints tickets to `wiki/src/blueprint/`:
+ `PRODUCTION=1 make move-blueprints`
+ * Move attachments out of the way for future processing:
+ `PRODUCTION=1 make move-attachments`
+ * Delete the rest.
+1. Manually take care of tickets sub-pages that were imported as
+ full-blown tickets. These sub-pages are used in too many different
+ ways to allow us to process them automatically:
+
+ PRODUCTION=1 make list-sub-pages
+
+1. Manually add attachments (the Importer plugin does not support
+ this).
+1. Add some tickets relationships back:
+ - screen_locker is blocked by deactivate_screensaver_until_time_is_set
+ - clean_the_forum is blocked by decide_what_kind_of_web_support_do_we_want_to_provide
+ - new_greeter_ui:_implement_specifications is blocked by new_greeter_ui:_clarify_specifications
+ - new_greeter_ui:_call_for_translation is blocked by new_greeter_ui:_implement_specifications
+ - new_greeter_ui:_call_for_translation is blocked by new_greeter_ui:_update_documentation
+ - new_greeter_ui:_test_prototypes is blocked by new_greeter_ui:_propose_prototypes
+ - new_greeter_ui:_update_documentation is blocked by new_greeter_ui:_implement_specifications
+1. For each ticket:
+ - Add a *Category* value.
+ - Add a *Type of work* value.
+ - Decide if it should have been kept as a blueprint. If so, salvage
+ the content of the old ikiwiki ticket into a shiny new blueprint.
+ - If *Type of work* is *wait*, mark the ticket as blocked by the
+ relevant other ticket, if any.
+1. Remove the `Qa` value from possible types of work.
+1. Mark the `Type of work` custom field as mandatory.
+1. Sort bugs and features to the relevant trackers.
+1. Add sub-tickets blocks/before/after relationships, starting with
+ tickets that are tagged `todo/wait` for another one.
+1. Remove the `External Id` field.
+1. Clean `tags/*` up.
+
+## Setup
+
+1. Install a Squeeze system with backports enabled.
+1. Install packages:
+
+ apt-get install redmine/squeeze-backports redmine-sqlite/squeeze-backports
+
+1. Follow the "QUICK LAUNCH USING WEBRICK" instructions in
+ `/usr/share/doc/redmine/README.Debian.gz`
+
+1. Install the importer plugin:
+
+ cd /usr/share/redmine/vendor/plugins && git clone https://github.com/leovitch/redmine_importer.git
+ cd /usr/share/redmine && rake db:migrate_plugins RAILS_ENV=production
+
+1. Install a backport of [[!debpkg ruby-fastercsv]], that's
+ a dependency of the importer plugin.
+ One has to decrease the build-dep on gem2deb to 0.2.7~.
+
+1. Restart WEBrick.
+
+[[!tag release/2.0]]
diff --git a/wiki/src/blueprint/bridge_support.mdwn b/wiki/src/blueprint/bridge_support.mdwn
new file mode 100644
index 0000000..0ba937b
--- /dev/null
+++ b/wiki/src/blueprint/bridge_support.mdwn
@@ -0,0 +1,110 @@
+[[!toc levels=2]]
+
+Given the increasing practice of blocking Tor usage in more
+authoritarian countries, censorship resistance is getting more
+important. To merely try to use Tor might even be dangerous in these
+countries as the government can log it and take action against the
+user. Hence we should provide an easy to use facility for our users to achieve:
+
+* Reliability: make sure that they always can reach the Tor network, and
+* Obfuscation: prevent others from knowing that our user may be using the Tor network.
+
+In Tor there is the concept of
+[bridges](http://www.torproject.org/bridges). By relaying the user's
+Tor traffic through a so called *bridge node* which is not listed in
+Tor's directory the user may be able to achieve a reliable connection
+and hide the fact that the user is connecting to a Tor server.
+Tor's bridging makes no attempt to mask the (Tor) nature of the
+traffic between the Tails user's client and the bridge node.
+Therefore the users access to the Tor network can still be determined
+by simple traffic analysis.
+See [[obfsproxy|todo/obfsproxy]] for a much better
+solution to the obfuscation problem.
+
+Bridges in Tails
+================
+
+While Vidalia makes it straight-forward to use bridges there are some
+special considerations that needs to be accounted for in the context
+of Tails. Since all Tor is started at boot, it is immediately
+disclosed that Tor is used. We need to make it possible for our users
+to prevent this, for instance by toggling some option in the boot
+menu. However, since all internet traffic is routed through Tor, if a
+user doesn't know of any bridges we have a Catch-22 situation since the
+user's best possibility to get a bridge is by getting it over the
+Internet, for instance from [the Tor project's
+website](https://bridges.torproject.org/), IRC or IM buddies and
+similar.
+
+Specification
+=============
+
+The use of bridges should be optional, and if desired it must be
+chosen before Tor starts. The best place for such an option is
+probably in tails-greeter. When activated the following things should
+happen:
+
+* Tor doesn't try to connect directly to the Tor network.
+* The user is somehow helped to setup a bridge, and possibly
+ instructed how to get one.
+* Once a bridge has been chosen, Tor should immediately start to use
+ it.
+
+Current work
+============
+
+We are going to use Vidalia's bridges configuration UI.
+
+When bridges are enabled (by adding `bridge` to the kernel
+command-line):
+
+* [[!tails_gitweb
+ config/chroot_local-includes/lib/live/config/204-bridge]] adds a
+ buggy bridge (127.0.0.1:7777) to `/etc/tor/torrc` and enables
+ `UseBridges` so that Tor does not even try to connect directly to
+ the network, even when restarted.
+* Vidalia is started with the `-bridgeconf` option brought by our
+ custom patch (XXX):
+ - network settings are displayed on startup
+ - `UseBridges` is enabled
+ - a Tails-specifig pop-up is shown.
+* As a workaround to [[!tor_bug 2355]], [[!tails_gitweb
+ config/chroot_local-includes/etc/NetworkManager/dispatcher.d/60-tor-sighup.sh]]
+ cleans up the Tor data directory when a network interface goes up.
+ A real fix for this bug is being worked on, see the bug page for
+ details and status updates.
+* When a network interface goes up, Tor and Vidalia are restarted. Tor
+ cannot reach its network until the real (working) bridges
+ configuration is applied by Vidalia, either saved from previous
+ input or newly entered by the user.
+
+Left to do
+==========
+
+General
+-------
+
+Fix all child tickets of [[todo/bridge_support:_complete_phase_one]].
+
+Find bridges button
+-------------------
+
+Vidalia has a "Find bridges now" button which won't work for us
+since it can't reach bridges.torproject.org. To get it to work we
+would need some kind of exception in the firewall rules.
+
+Anyway, bridges.tpo now asks for a CAPTCHA, so an automated,
+out-of-the-browser solution seems not doable this way.
+
+It should be noted that just connecting to bridges.torproject.org
+can be dangerous if the regime is hostile towards Tor, and/or it
+could simply be censored. This must be explained to the user, and
+manual input of bridges must be available as an alternative.
+
+One can also get Obfsproxy [bridges by email](https://www.torproject.org/docs/bridges.html.en#FindingMore) (currently sent from Yahoo
+and Gmail email accounts only).
+
+Until a solution is found for this issue, we should probably [[hide this
+button|todo/hide_Find_bridges_button]].
+
+[[!tag release/1.0]]
diff --git a/wiki/src/blueprint/centralize_Git_repositories.mdwn b/wiki/src/blueprint/centralize_Git_repositories.mdwn
new file mode 100644
index 0000000..a44367e
--- /dev/null
+++ b/wiki/src/blueprint/centralize_Git_repositories.mdwn
@@ -0,0 +1,21 @@
+We're going to have a dedicated Gitolite instance at immerda.ch so
+that we can create repos and manage ACLs ourselves without delays, as
+well as setup IRC commit notifications.
+
+We're going to move all our repos there but the website.
+
+[[!toc levels=2]]
+
+# Resources
+
+* the [documentation](https://wiki.immerda.ch/index.php/GitRepositoriesImmerda)
+ about immerda's Gitolite setup
+* core developers can clone the Gitolite admin repository from
+ `tails@git.tails.boum.org:gitolite-admin.git`
+
+# Roadmap
+
+1. [[todo/migrate_Git_repositories_to_immerda]] **done**
+1. [[setup IRC commit notifications|todo/find_another_irc_commit_bot]]
+
+[[!tag todo/done]]
diff --git a/wiki/src/blueprint/detect_captive_portals.mdwn b/wiki/src/blueprint/detect_captive_portals.mdwn
new file mode 100644
index 0000000..b2c5db5
--- /dev/null
+++ b/wiki/src/blueprint/detect_captive_portals.mdwn
@@ -0,0 +1,69 @@
+For users that haven't read the documentation about the unsafe browser
+and/or just don't understand when it's necessary, it would be good if
+Tails does a reasonable job to try to detect whether a captive portal
+seems to be in place and notify the user if so. The approaches could
+range from simplistic to more sophisticated:
+
+* If `wait_for_tor_consensus()` fails during time syncing. Note that
+ this would happen if Tails is booted on a LAN without Internet
+ conneciton.
+* Use [ooni-probe](https://gitweb.torproject.org/ooni-probe.git)?
+* Other approaches.
+
+The method used likely has to be active, but it should preferably hook
+into some common, innocent looking network connection in order to
+avoid fingerprinting.
+
+Tools
+=====
+
+Using WWW::Mechanize::Shell
+---------------------------
+
+For each kind of hotspot:
+
+* list of possible ESSID
+* optional: allocated IP address classes
+* optional: network test script?
+* optional: SSL certificate fingerprint?
+* a WWW::Mechanize::Shell script
+
+Main script in in /etc/NetworkManager/dispatcher.d.
+
+Test current connection against known hotspots.
+
+When connected to a known hotspot, starts WWW::Mechanize::Shell
+script. Values are entered through a callback than will uses
+Gtk2::Notify and some custom widgets. Known login/passwords should be
+put in gnome-keyring with a browser like completion system (enter
+first letters, pick login, password is prefilled). Maybe we could use
+the same login/password database as Epiphany.
+
+For hotspots that requires a periodic refresh, we can run another
+WWW::Mechanize::Shell script in a loop. NetworkManager is meanwhile
+monitored through DBUS to kill the loop if connection is lost. If loop
+fails try once more through default script before displaying a
+notification.
+
+Existing hotspot connection applications
+----------------------------------------
+
+Looks like there is at least two Python apps doing this already:
+
+* [autowifi](http://www.manatlan.com/page/autowifi)
+* [autologin-applet](http://antoine.mairesse.free.fr/autologin-applet/)
+
+Captive portal detection
+------------------------
+
+hellais and friends are working on
+[ooni-probe](https://gitweb.torproject.org/ooni-probe.git) which may be
+interesting, depeding on how stealthy the probe is.
+
+Beta testers
+============
+
+* San Bergmans <info@sbprojects.com>: FON network, KPN hotspots in the
+ Netherlands
+
+[[!tag todo/research]]
diff --git a/wiki/src/blueprint/easier_YouTube.mdwn b/wiki/src/blueprint/easier_YouTube.mdwn
new file mode 100644
index 0000000..b8faf0b
--- /dev/null
+++ b/wiki/src/blueprint/easier_YouTube.mdwn
@@ -0,0 +1,56 @@
+[[!toc levels=2]]
+
+Next steps
+==========
+
+0. integrate the test reports below and the next steps they suggest as
+ part of this roadmap
+0. wait a bit for [[todo/smtube]] to mature; if
+ it's acceptable and merged, then perhaps we will consider the
+ *easier YouTube* task as completed.
+0. [[todo/benchmark_YouTube_HTML5_addons]]
+0. make audio and video codecs autoplay (so that the Tails web browser
+ works in a less surprising way, especially for new users; also, the
+ idea is that when one goes to a page with audio or video objects,
+ they want to read them more often than not)
+
+Alternatives
+============
+
+* [[todo/Flash_support]]
+* [YouTube Video Download for
+ Greasemonkey](https://userscripts.org/scripts/show/62634)
+
+Background
+==========
+
+* [[forum thread|forum/Youtube_is_now_automatically_HTML5_enabled]],
+* [[!tor_bug 3347]]
+
+Test reports
+============
+
+Out-of-the box YouTube support in Tails 0.18
+--------------------------------------------
+
+With Tails 0.18, I visited one of the featured videos on youtube which
+is <https://www.youtube.com/watch?v=aK_eKGK4JrM>.
+
+At first it gave me the usual msg flash player, then I added
+`&html5=1` on the URL and refreshed the page. It worked as it should
+be no issues. After that, most of the videos played out of the box
+without the `&html5=1` that where on the right side as
+featured/similar.
+
+> I can reproduce this with 0.19. However, one still has to
+> click-to-play their way through the "Additional plugins [...]"
+> message. --intrigeri
+
+From one of them I got the msg "The browser does not currently
+recognize any of the video formats available."
+
+Later I entered <https://www.youtube.com/html5> where I verified that
+my browser does not support h.264, also I had the msg "You are not
+currently in the HTML5 trial." Hope that helps.
+
+[[!tag priority/normal]]
diff --git a/wiki/src/blueprint/find_another_irc_commit_bot.mdwn b/wiki/src/blueprint/find_another_irc_commit_bot.mdwn
new file mode 100644
index 0000000..bfc415a
--- /dev/null
+++ b/wiki/src/blueprint/find_another_irc_commit_bot.mdwn
@@ -0,0 +1,39 @@
+[CIA.vc is
+dead](http://shadowm.rewound.net/blog/archives/245-CIA.vc-is-dead.html). It
+would be good to find another way to have commits announced to the IRC
+channels.
+
+`repo.or.cz` which was used to send updates to CIA is also able to trigger
+HTTP post compatible with HTTP post compatible with [GitHub
+webhooks](https://help.github.com/articles/post-receive-hooks).
+[gitbot](https://github.com/thedjinn/gitbot) is a fairly trivial bot
+written in Ruby that receives these kind of commit notifications and
+write them on an IRC channel. However, repo.or.cz does not support
+notifications for mirror projects. It does not look that hard to add
+this feature to their software, but we were not able to get an
+up-to-date copy thereof after 2 emails and 5 weeks, so this does not
+look viable a solution.
+
+Other options: [irker](http://www.catb.org/esr/irker/) and
+[KGB](http://kgb.alioth.debian.org/). Both needs to be able to set custom
+post-receive hooks in the repository. That's why we have
+[[centralized Git repositories|todo/centralize_Git_repositories]].
+
+Next steps
+==========
+
+## immerda
+
+1. [[todo/kgb-bot]]
+1. [[todo/have_kgb_client_hooks_installed]]
+1. [[todo/enable_kgb_client_hooks]]
+
+## plan B
+
+If it does not work as planned at immerda, we could research for
+a third-party to offer either the "IRC notification reacting on GitHub
+webhooks" service or the full "monitor Git repositories and notify on
+IRC" one.
+
+Or we could host the whole set of our own Git repositories ourselves,
+so that we can use KGB or irker.
diff --git a/wiki/src/blueprint/improve_translators_documentation.mdwn b/wiki/src/blueprint/improve_translators_documentation.mdwn
new file mode 100644
index 0000000..96b2b75
--- /dev/null
+++ b/wiki/src/blueprint/improve_translators_documentation.mdwn
@@ -0,0 +1,12 @@
+[[!tag todo/documentation]]
+
+The current documentation for translators could be improved:
+
+1. pointers to basic Git usage documentation
+
+See [R. Hertzog's "Contributing to the translation of
+Debian"](http://raphaelhertzog.com/2012/01/31/contributing-to-the-translation-of-debian/)
+for great inspiration.
+
+See also [[todo/update_translation_instructions_for_Transifex]].
+
diff --git a/wiki/src/blueprint/incremental_upgrades.mdwn b/wiki/src/blueprint/incremental_upgrades.mdwn
new file mode 100644
index 0000000..854a894
--- /dev/null
+++ b/wiki/src/blueprint/incremental_upgrades.mdwn
@@ -0,0 +1,834 @@
+[[!toc levels=4]]
+
+# Rationale
+
+Partial upgrades should provide only what has changed between two
+releases (deltas) and have a way to apply those changes to the
+previous version.
+
+At boot-time the security warning telling that a new Tails version is available
+should provide an automated way of doing the upgrade.
+
+# Definitions
+
+* **update-description file**: a file that describes the update from
+ a given version, to another, newer given version of a software
+ product.
+* **Incremental Upgrade Kit (IUK)**: a file that contains everything
+ needed to update from.
+* **full image**: a file that is sufficient to install and run Tails
+ (currently, that means an ISO image).
+* **target files**: the whole set of files included by reference into
+ an update; e.g. this may be an IUK or a full image.
+
+# Roadmap
+
+1. (**past**) Tails 0.13 has the harmless part of the
+ `feature/incremental-upgrades` branch merged (users creation with
+ sudo credentials, dependencies installation), leaving aside the
+ part about running the update frontend automatically at startup.
+ => Tails 0.13 should have been able to incrementally upgrade to
+ something newer, when running the update frontend by hand,
+ but the included Tails OpenPGP signing key expired too quickly for
+ this to happen.
+
+2. (**past**) Now that 0.14 is out:
+
+ * Prepare IUK: **done**
+ * Update update-description files: **done**
+ * Ask beta testers to try the incremental upgrade process: **done**
+ * Find most critical bugs: **done**.
+
+3. Complete **phase one: make ready for more alpha testing**
+
+ Fix all child tickets of
+ [[todo/incremental_upgrades:_complete_phase_one]], and then:
+
+ * Prepare IUK
+ * Update update-description files
+ * Ask alpha testers to try the incremental upgrade process
+ * Catch and fix most remaining bugs
+
+4. Complete **phase two: make ready for beta testing**
+
+ Fix all child tickets of
+ [[todo/incremental_upgrades:_complete_phase_two]], and then:
+
+ * Prepare IUK
+ * Update update-description files
+ * Ask beta testers to try the incremental upgrade process
+ * Catch and fix most remaining bugs
+ * Review user documentation and translations
+
+5. Complete **phase three: deploy in production**
+
+ Once we're happy with the whole thing, ship it, enabled by
+ default, in the next Tails major release.
+
+ See child tickets of [[todo/incremental_upgrades:_complete_phase_three]].
+
+6. Later
+
+ * make it easy to **generate update-description files** for a point
+ release: phase two
+
+# Scenarios
+
+## As a Tails user
+
+### When I boot Tails
+
+The scenarios are described in Cucumber-style, using [[!cpan
+Test-BDD-Cucumber]], in the `features/frontend` directory of the
+`tails-iuk` [[contribute/Git]] repository. Use the `pherkin
+features/frontend` command to run them.
+
+## As a Tails developer
+
+### When I prepare a point-release
+
+#### I should prepare an IUK
+
+The scenarios about this are described in Cucumber-style, using
+[[!cpan Test-BDD-Cucumber]], in the `features/create` directory of the
+`tails-iuk` [[contribute/Git]] repository. Use the `pherkin
+features/create` command to run them.
+
+#### I should test the IUK
+
+Until we have [[automated tests|todo/automated_builds_and_tests]],
+I should manually try to install the IUK as intended on top of the old
+version of Tails, and I should check that the resulting system behaves
+as it should.
+
+#### I should prepare update-description files
+
+FIXME
+
+* for the previous release (to announce they may update using the IUK
+ that's being prepared)
+* for the new release (to announce no update is available)
+
+#### I should publish the IUK
+
+FIXME
+
+#### I should publish update-description files
+
+FIXME
+
+### When I prepare a major release
+
+FIXME
+
+#### I should prepare an update-description file
+
+FIXME
+
+* for the previous release (to announce they may update using the
+ release that's being prepared)
+* for the new release (to announce that no update is available)
+
+#### I should publish the update-description file
+
+FIXME
+
+# Implementation
+
+## Upgrade paths
+
+To ease implementation, only upgrades to the next closest step
+are supported in phase one.
+
+E.g. say one has installed Tails 0.11 a while ago, and forgets
+about it. We then release Tails 0.11.1, and publish a `0.11_to_0.11.1`
+IUK, advertised by the update-description file for 0.11 users. We then
+release Tails 0.11.2, and publish a `0.11.1_to_0.11.2` IUK, advertised
+by the update-description file for 0.11.1 users. If the user starts
+their Tails 0.11, the upgrade system proposes upgrading to 0.11.1.
+Say the user accepts, the upgrade is performed, the user reboots, and
+the upgrade system now proposes upgrading to 0.11.2.
+
+Allowing to run these two steps in a row, without rebooting, is
+mainly a GUI problem, and is postponed.
+
+## Infrastructure
+
+### generate an IUK
+
+We have a `tails-create-iuk` program that takes two Tails full images as input, and:
+
+* builds the "diff" SquashFS
+* gets the new kernel(s), initrd(s), bootloader configuration
+* brings all this together into a single file, in the IUK format
+
+### Incremental Update Kit
+
+#### IUK format
+
+An IUK is a tar archive, compatible with GNU tar, that contains the
+following files:
+
+* `FORMAT`: contains the version of the IUK format (that is *1*), as
+ a positive integer encoded in ASCII.
+* `control.yml`: YAML associative array with the following keys:
+ - `delete_files`: a list of files to delete from the
+ system partition.
+* zero, one or more `*.tar[.bz2]`: tar archives, compatible with GNU tar, optionally
+ compressed with bzip2, that contain the set of files to add to, or
+ update in the system partition: kernel(s), initrd(s), bootloader
+ configuration, `*.squashfs` (the SquashFS "diff" that must be
+ stacked on top of the older SquashFS filesystem(s)), etc.
+
+File paths, both in `*.tar[.bz2]` and in the `delete_files` list, are
+relative to the Tails system partition root, and must be compatible
+with a FAT32 filesystem.
+
+Tarballs contained in the IUK are meant to be extracted, one after the
+other, sorted by ASCII order.
+
+#### Initial implementation details
+
+(This section is not a specification.)
+
+The initial IUK generator will ship those files in every IUK:
+
+* `system.tar` contains files that are already compressed
+ (e.g. kernel, initrd, `*.squashfs`)
+* `boot.tar.bz2` contains files that are not compressed already
+ (that is the syslinux configuration)
+
+These are implementation details the IUK installer software must not
+rely upon.
+
+### mirrors infrastructure
+
+Using something like [Mozilla's
+channels](https://wiki.mozilla.org/Software_Update:Channels)
+(*stable*, *beta*, *nightly*) would e.g. allow us to push beta
+updates earlier to a brave subset of users. Subscribing to a channel
+other than *stable* is something that would be worth
+[[persisting|doc/first_steps/persistence]]. We are not likely to
+implement a channels system in phase one, but the infrastructure we
+setup should leave room for such future extension.
+
+### Update-description files
+
+We want the client to get an answer to questions such as "I run
+version N of product P on architecture A, what stable release update
+is available?". To allow us changing the way the answer is computed in
+the future, the amount of work done on the client's side should be
+kept to a minimum. So, let's insert a level of indirection, and
+pre-compute server-side the answer to the queries we want to support.
+
+The answers are distributed on our HTTP servers in the form of a set
+of update-description file files.
+
+#### update-description file URL
+
+* `https://tails.boum.org/update`
+* URL schema version (so we can change it in the future), that is `v1`
+ to start with.
+* product name (e.g. *Tails*, but some day we may have *TailsServer*,
+ *TailsHandheld* or whatever)
+* product version -- the currently running version to upgrade from,
+ e.g. *0.11* or *0.11.1*
+* build-target (e.g. *i386*)
+* channel (e.g. *stable* or *beta*)
+* `update.yml`
+
+Example: <https://tails.boum.org/update/v1/Tails/0.11/i386/beta/updates.yml>
+
+Such a file shall be shipped along with its OpenPGP detached signature
+(`updates.yml.pgp`).
+
+#### update-description file format
+
+An update-description file contains a YAML associative array with the
+following top-level keys:
+
+* `product-name`
+* `product-version`
+* `build-target`
+* `channel`
+* `updates`: a list of update elements.
+
+Each update element is itself an associative array describing an
+update to an individual product version, with the following keys:
+
+* `version` -- the version of this update, that is the version of the
+ running product after the update is completed and the system
+ restarted (e.g. *0.11.1*)
+* `type` -- *major* or *minor* (in phase one, all IUK will be about
+ point-releases, and the type will therefore always be *minor*, but
+ let's make room in case we want to announce major releases this way
+ too at some point)
+* `details-url` (optional) -- a URL to a web page with more
+ information about the specified update (e.g.
+ <https://tails.boum.org/news/version_0.11.1/>)
+* `update-paths` -- a list of at least one and no more than two
+ update path elements.
+
+An update path element describes a set of target files that lives on
+a remote server that must all be downloaded and applied to the product
+to update it to that version. The keys for an update path element are
+as follows:
+
+* `type` -- *full* or *incremental* (IUK are about incremental
+ upgrades, but let's make room to announce full images this way too
+ at some point)
+* `target-files`: a list of target files for this upgrade path.
+
+Every target file element has the following keys:
+
+* `url` -- A URL to the target file.
+* `size` -- The size of the update, in bytes.
+* `sha256` -- The SHA-256 hash of the patch file, encoded as an
+ hexadecimal string. If the client
+ generated value does not match this, the integrity check fails after
+ download. (Other kind of hashes may be added in a future revision of
+ the update-description file format -- which of these multiple hashes
+ the client must verify will need to be specified when this happens.)
+
+Example that would be found at
+<https://tails.boum.org/update/v1/Tails/0.11.1/i386/stable/updates.yml>:
+
+ product-name: Tails
+ product-version: 0.11.1
+ channel: stable
+ build-target: i386
+
+ updates:
+ - version: 0.11.2
+ type: minor
+ details-url: https://tails.boum.org/news/version_0.11.2/
+ update-paths:
+ - type: incremental
+ target-files:
+ - url: http://dl.amnesia.boum.org/tails/stable/iuk/Tails_i386_0.11.1_to_0.11.2.iuk
+ size: 37345648
+ sha256: 5c5c47f6155e7807c971251fdad28d5f72ff78db446e43a41e4b900f29229a7d
+ - type: full
+ target-files:
+ - url: http://dl.amnesia.boum.org/tails/stable/tails-i386-0.11.2/Tails-i386-0.11.2.iso
+ size: 762123456
+ sha256: 1015e37e14c6daaecd528b4a841ef6ac2156a5790346d0fd036f9566ce5f641b
+
+### Initial implementation details
+
+This section is not a specification. The URL where the IUK's are
+stored, and their file name, may change. If this happens, any
+update-description file available on Tails HTTP mirrors, that
+references an IUK whose URL changes, must be updated accordingly.
+
+#### IUK file basename
+
+An IUK's file basename is not an authoritative source of information
+regarding its content. However, it should be unique (among IUKs that
+exist on the Tails HTTP servers at a given time).
+
+An IUK's file name is built from these underscore-separated elements,
+followed by the `.iuk` suffix:
+
+* product name (e.g. *Tails*)
+* build-target (e.g. *i386*)
+* product version -- the currently running version to upgrade from,
+ e.g. *0.11* or *0.11.1*
+* `to`
+* the version of this update, that is the version of the running
+ product after the update is completed and the system restarted (e.g.
+ *0.11.2*)
+
+Example: `Tails_i386_0.11.1_to_0.11.2.iuk`
+
+#### IUK URL
+
+A given IUK is meant to be made available at the URL composed from:
+
+* `http://dl.amnesia.boum.org/tails/iuk/`
+* the IUK file basename
+
+Example: <http://dl.amnesia.boum.org/tails/iuk/Tails_i386_0.11.1_to_0.11.2.iuk>
+
+## Client and user interface
+
+The program currently telling that a new Tails version is available
+must be adapted to use update-description files instead of the current
+Atom feed.
+
+### update-description downloader and verifier
+
+This program has the responsibility to download and verify an
+update-description file.
+
+* Build the URI to its update-description file (might even be done at
+ build time and hard-coded into the image) and to its
+ cryptographic signature.
+* Fetch the update-description file and its signature at these URIs.
+* Verify the cryptographic signature of the update-description file.
+* Check that content of the update-description file matches the
+ currently running system (in terms of product name, product
+ version, build-target and channel).
+* Once all these steps have been successfully performed, the content
+ of the update-description file is trusted to be legit, and is
+ returned to the caller as such.
+
+Failure, at any of the above steps, must be reported to the caller.
+
+### update frontend
+
+* Get a verified update-description file from the update-description
+ downloader and verifier.
+* Extract information about available updates from the
+ update-description file.
+* Present such information to the user, let them decide if they want
+ to perform the update.
+* If an incremental update path to the new version is available:
+ - securely create a tempdir in `tmpfs`, owned by
+ `tails-iuk-get-target-file:tails-iuk-get-target-file`,
+ with mode 0750
+ - run the IUK downloader and verifier, asking it to drop the
+ verified target file into the tempdir (either the default umask
+ will do, or steps shall be taken to make sure the
+ `tails-install-iuk` user may read the resulting files)
+* Else, point at full upgrade documentation.
+* Shutdown the network.
+* Remount the system partition read-write.
+* Perform the update using the files provided by the "target files
+ downloader and verifier".
+* Tell the user the upgrade process is finished, and they *MUST*
+ immediately reboot (due to system partition being left mounted
+ read-write, 'cause we cannot remount it read-only once it's been
+ mounted read-write).
+
+### target file downloader and verifier
+
+This program has the responsibility to download and verify a target
+file, and make available to the caller either the verified target
+file, or some error message.
+
+* Takes as arguments: URI, size, hash type, hash value, destination
+ path where the verified target file should be left, and
+ possibly options.
+
+Detailed executable scenarios describe and test the behaviour of this
+piece of software in Cucumber-style, using [[!cpan
+Test-BDD-Cucumber]]. They may be found in the
+`features/download_target_file` directory of the `tails-iuk`
+[[contribute/Git]] repository, and run using the `pherkin
+features/download_target_file` command.
+
+### install an IUK
+
+Once a user has downloaded an IUK, they must have it installed.
+
+We need an installer for IUKs:
+
+* **Input**: the path to an (already verified) IUK.
+* **Output**: success or failure (with error message)
+
+Installing an IUK should happen at the same time as normal Tails
+operation, but very carefully, because we need to remount the boot
+medium read-write.
+
+* Verify the IUK is in a supported format.
+* Remount the boot-medium read-write.
+* Extract the IUK archive.
+* Move stacked squashfs found in the IUK in place.
+* Extract tarballs (`*.tar[.bz2]`) contained in the IUK, one after the
+ other, sorted by ASCII order.
+* Delete files that are listed in the `delete_files` control field.
+* Append the new SquashFS diff file name to the `live/Tails.module`
+ file, in the Tails system partition.
+
+Detailed executable scenarios describe and test the behaviour of this
+piece of software in Cucumber-style, using [[!cpan
+Test-BDD-Cucumber]]. They may be found in the `features/install`
+directory of the `tails-iuk` [[contribute/Git]] repository, and run
+using the `pherkin features/install` command.
+
+Resources:
+
+* [Mozilla's updates
+ processing](https://wiki.mozilla.org/Software_Update:Processing_Updates):
+ building up some mechanism (such as their pending / applying /
+ succeeded / failed status) to avoid retrying the same buggy update
+ in a loop seems worth being considered.
+
+### full update
+
+The Tails USB installer is still in charge of performing full updates.
+It must delete any `live/*.squashfs` file other than the one shipped
+in the new ISO.
+
+### signature verification
+
+update-description file polling, parsing and verification will be
+implemented in Perl. Signature verification will be made using
+`GnuPG::Interface`'s `verify` method.
+
+The verify method is run on a `GnuPG::Interface` object built with
+`--homedir` pointed to a dedicated keyring directory, created at Tails
+boot or ISO build time, that contains only the Tails signing public
+OpenPGP key, which is assigned the minimum level of trust so that
+GnuPG trusts the signatures made with the associated private key.
+
+The `verify` method return value is `waitpid`'d for, and the GnuPG
+child process exit status examined (zero means verification succeeded,
+non-zero means verification failure).
+
+# Code
+
+* The bulk of the code needed to implement this design lives in the
+ `tails-iuk` [[contribute/Git]] repository.
+* Integration work is being done in the `feature/incremental-upgrades`
+ branch of the main Tails [[contribute/Git]] repository.
+
+# Security
+
+We want to use secure update tools such as TUF or Thandy once they are
+ready enough for production wrt. our usecases. Unfortunately, this is
+not the case yet, and we haven't the resources to seriously contribute
+to TUF or Thandy.
+
+Therefore, given we want to have some incremental update system
+*soon*, the simple one we will ship in phase one will clearly be less
+secure than TUF of Thandy against certain types of attacks.
+
+However, we believe it is at least as secure as the way users are
+currently able to manually check if a new Tails version is available,
+to download and to verify it. Let's discuss this.
+
+In what follows, we will call "the old Tails update system" the way
+users are currently able, as of May 2012, to manually check if a new
+Tails version is available, download target files, and verify
+their integrity.
+
+## Update-description files
+
+Given:
+
+* update-description files are published on <https://tails.boum.org/>;
+ in the old Tails update system, this is the canonical place where
+ Tails users can check for updates availability.
+* The update-description downloader and verifier checks the SSL
+ certificate presented by the server is valid (in phase one, using
+ simple CA-based validation; using Monkeysphere instead would be
+ a great future improvement).
+
+Hence, the trust-path to availability and freshness of
+update-description files is as good as with the old Tails
+update system.
+
+Moreover, update-description files are signed by the Tails OpenPGP
+signing key. Then, the trust-path to the content of update-description
+files is better than the old Tails update system.
+
+## Target files
+
+Given:
+
+* Communication to HTTP servers that provide target files is made in
+ cleartext (`http://`). No security is to be expected from
+ transport-level security here. Mirrors are not trusted anyway.
+* Availability, location, hash and size of target files are published
+ in update-description files, towards wich some minimal trust-path
+ was established (see above).
+* In the old Tails update system, target files are signed by the Tails
+ OpenPGP signing key.
+
+As a consequence, the availability, freshness and content of target
+files is protected as well as it is in the old Tails update system.
+
+## Discussion
+
+**Note**: the attack definitions bellow come straight from the [TUF
+security
+documentation](https://www.updateframework.com/wiki/Docs/Security)
+(2012-05-04).
+
+We believe the update system described on this page is at least as
+secure as the old Tails update system.
+
+### Arbitrary software installation
+
+> An attacker installs anything they want on the client system.
+> That is, an attacker can provide arbitrary files in response to
+> download requests and the files will not be detected
+> as illegitimate.
+
+Both the old and new Tails update systems are immune to this attack,
+as long as the trust-path to the update-description file is not
+broken, and OpenPGP signatures on the target files are carefully
+verified. We have seen above why we believe the trust-path to
+update-description files to be at least as secure as the old Tails
+update system. In the new Tails update system, OpenPGP signatures are
+automatically verified, which provides this kind of protection even to
+users would not have checked manually in the context of the old
+update system.
+
+### Rollback attacks
+
+> An attacker presents a software update system with older files than
+> those the client has already seen, causing the client to use files
+> older than those the client knows about.
+
+Given the update-description downloader and verifier checks the
+version of the proposed updates against the version of the currently
+running system, the update system described on this page is immune to
+this attack.
+
+### Indefinite freeze attacks
+
+> An attacker continues to present a software update system with the
+> same files the client has already seen. The result is that the
+> client does not know that new files are available.
+
+Both with the old and new Tails update systems, mounting such an
+attack requires either to take control of the Tails website or to
+break the SSL/TLS connection between the client and the server.
+
+The move to a secure update system, such as TUF, would make this
+stronger, thanks to short-lived signatures on meta-data.
+
+### Endless data attacks
+
+> An attacker responds to a file download request with an endless
+> stream of data, causing harm to clients (e.g. a disk partition
+> filling up or memory exhaustion).
+
+The old Tails update system offers no protection at all against
+performing this class of attacks, so the new one cannot do worse.
+However, the new Tails update system, by including the expected size
+of the target files in the set of meta-data verified before
+downloading them, opens the possibility for the target files
+downloader and verifier to avoid downloading more data than expected;
+also, the update-description files downloader and verifier could avoid
+downloading update-description files bigger than some
+reasonable constant.
+
+### Slow retrieval attacks
+
+> An attacker responds to clients with a very slow stream of data that
+> essentially results in the client never continuing the
+> update process.
+
+The old Tails update system offers no protection at all against this
+class of attacks, so the new one cannot do worse. However, one change
+brought by the new Tails update system is that we control the programs
+used to download update-description files and target files; hence, we
+could set timeouts on download operations so that, at least, the user
+can be made aware of what is happening.
+
+### Extraneous dependencies attacks
+
+> An attacker indicates to clients that in order to install the
+> software they wanted, they also need to install unrelated software.
+> This unrelated software can be from a trusted source but may have
+> known vulnerabilities that are exploitable by the attacker.
+
+In the old Tails update system, changing the list of needed files
+could be done by taking control of the Tails website or breaking the
+client/server SSL/TLS connection; in the new Tails update system,
+mounting this attack requires being able to sign a modified
+update-description file with the Tails OpenPGP signing key instead,
+which is most probably harder.
+
+### Mix-and-match attacks
+
+> An attacker presents clients with a view of a repository that
+> includes files that never existed together on the repository at the
+> same time. This can result in, for example, outdated versions of
+> dependencies being installed.
+
+The list of needed target files to perform an update, along with their
+hashes, is available in a single location, that is in an
+update-description file; therefore, we believe the update system
+described on this page to be immune to mix-and-match attacks.
+
+### Wrong software installation
+
+> An attacker provides a client with a trusted file that is not the
+> one the client wanted.
+
+The old Tails update system does not protect against this attack:
+a mirror can replace an ISO file and its detached OpenPGP signature
+with an obsolete pair of files, renamed to match the expected file
+names of the new release. Given some released versions of Tails
+shipped a dysfunctional "security warning if update is available"
+system, many users would probably not notice.
+
+The new Tails update system is as secure, wrt. wrong software
+installation attacks, as the trust-path to update-description files
+are. Breaking this is clearly harder than renaming a pair of files on
+a mirror controlled by an attacker, so the new Tails update system is
+more secure than the old one against wrong software installation.
+
+### Malicious mirrors preventing updates
+
+> An attacker in control of one repository mirror is able to prevent
+> users from obtaining updates from other, good mirrors.
+
+In both the old and new Tails update systems, mirrors are used for
+target files only, as part of a DNS round-robin pool that contains
+more than 6 members, so when retrying a failed download at a later
+time, one is likely to land onto another mirror. We then believe both
+the old and new Tails update system to be relatively safe from this
+class of attacks, as long as failed downloads are tried again later.
+
+### Vulnerability to key compromises
+
+> An attacker who is able to compromise a single key or less than
+> a given threshold of keys can compromise clients. This includes
+> relying on a single online key (such as only being protected by SSL)
+> or a single offline key (such as most software update systems use to
+> sign files).
+
+Both the old and new Tails update systems are vulnerable to this class
+of attacks, due to the reliance on the Tails OpenPGP signing key.
+The future move to a secure update system such as TUF or Thandy will
+fix this.
+
+## Privilege separation
+
+The default Live user (`amnesia`) runs the update frontend and:
+
+* is allowed to run a `/usr/local/sbin/network-shutdown` script, using
+ passwordless sudo, as root.
+* is allowed to run the `tails-install-iuk` program, with any
+ arguments, using passwordless sudo, as the `tails-install-iuk` user.
+* is allowed to run the `tails-iuk-get-target-file` program, with any
+ argument, using passwordless sudo, as the
+ `tails-iuk-get-target-file` user.
+* is allowed to run `tails-iuk-mktemp-get-target-file`, using
+ passwordless sudo, as the `tails-iuk-get-target-file` user.
+
+The `tails-install-iuk` user is allowed to run, using passwordless
+sudo, every command required by its task (currently: `chmod`, `cp`,
+`mkdir`, `mktemp`, `mount`, `rm` and `tar`). It is a member of the
+`tails-iuk-get-target-file` group, which allows it to read the files
+downloaded by the `tails-iuk-get-target-file` program.
+
+# Research
+
+## Secure update
+
+* [TUF: The Update Framework](https://www.updateframework.com/)
+* [Thandy specification](https://gitweb.torproject.org/thandy.git/blob_plain/HEAD:/specs/thandy-spec.txt)
+
+## Stacking squashfs images
+
+Tails filesystem is already using `aufs` to provide a read-write filesystem on
+top of the read-only `squashfs` image.
+
+This system could probably be extended to support mounting multiple `squashfs`
+filesystems on top of each others. Upgrades would be `squashfs` images with only
+the files that have been modified since the previous releases. This handles file
+deletions.
+
+Shipping upgrades could be as simple as shipping those extra `squashfs` images.
+
+Debian live supports such stacking already: see in `live-boot(7)` the
+part about `/live/filesystem.module`.
+
+Stacking squashfs images like this would still lack a way of upgrading the
+kernel and the syslinux. This should also be handled by the automated upgrade
+process.
+
+### Initial test
+
+Here is a test. First the procedure to create the *delta* squashfs image, to be
+done as `root`:
+
+ mkdir /mnt/tails-0.7.1
+ mkdir /mnt/tails-0.7.2
+ mount -o loop tails-i386-0.7.1.iso /mnt/tails-0.7.1
+ mount -o loop tails-i386-0.7.2.iso /mnt/tails-0.7.2
+ mkdir /mnt/tails-0.7.1-root
+ mkdir /mnt/tails-0.7.2-root
+ mount -o loop /mnt/tails-0.7.1/live/filesystem.squashfs /mnt/tails-0.7.1-root
+ mount -o loop /mnt/tails-0.7.2/live/filesystem.squashfs /mnt/tails-0.7.2-root
+
+ mkdir /mnt/upgrade-0.7.1-to-0.7.2
+ mount -t tmpfs tmpfs /mnt/upgrade-0.7.1-to-0.7.2
+
+ mkdir /mnt/union
+ mount -t aufs -o br=/mnt/upgrade-0.7.1-to-0.7.2=rw:/mnt/tails-0.7.1-root=ro none /mnt/union
+ rsync -avP --delete-after /mnt/tails-0.7.2-root/ /mnt/union/
+
+ mksquashfs /mnt/upgrade-0.7.1-to-0.7.2 upgrade-0.7.1-to-0.7.2.squashfs
+
+Compressed size (using default gzip compression) is 82 MB.
+
+Not bad, and the new kernel is included, which can probably be avoided.
+
+Now, let's upgrade an USB stick:
+
+ mkdir /media/disk/live
+ cp /mnt/tails-0.7.1/live/filesystem.squashfs \
+ upgrade-0.7.1-to-0.7.2.squashfs \
+ /mnt/tails/0.7.2/live/vmlinuz \
+ /mnt/tails/0.7.2/live/initrd.img \
+ /media/disk/live
+
+Then fiddle with GRUB or EXTLINUX.
+
+On boot, the new squashfs gets properly integrated. *Whiteouts* are not
+working. It looks like the `live-boot` 2.x mount options miss the `wh` attribute.
+But wait, booting with `break=top` and modifying `/scripts/live` to replace
+`roopt=rr` by `roopt=rr+wh` is enough to do the trick! Therefore,
+we've added the `wh` attribute to `live-boot` 3.x.
+
+Initial test is pretty conclusive!
+
+## Discarded options
+
+See the [[page about discarded options|todo/incremental_upgrades/archive]].
+
+# Random ideas for future improvements
+
+These are not worth creating tickets yet, as it's not even clear these
+changes are useful enough to put time in it.
+
+### Packaging could be more self-contained
+
+Move `/etc/sudoers.d/zzz_update` and IUK-related user creation from
+the Tails main Git repository to the `tails-iuk` Debian package, so
+that it's more self-contained and easier to test.
+
+### Button for aborting upgrade cleanly
+
+### Compute and display ETA
+
+### Multi-step incremental upgrade
+
+E.g. 0.11 boots after 0.11.1 and 0.11.2 are out. Tails fetches
+https://tails.boum.org/update/v1/Tails/0.11/i386/stable/updates.yml,
+that shall contain an incremental upgrade path with two target files:
+the 0.11 to 0.11.1 IUK, and the 0.11.1 to 0.11.2 IUK. The updater
+would download these two files and install the two IUKs in the
+correct order.
+
+### sharing update material
+
+Once the incremental update has been applied, I may be proposed to
+save a copy of the target files to a location of my choosing.
+
+### allow one to download target files in the clear
+
+The downloader program could provide an opt-in way to have the
+download happen in the clear, that is without going through the Tor
+network. It looks doable given it's a separate process: we may run it
+as a dedicated user, and reuse the `clearnet` infrastructure
+implemented for the Unsafe Browser.
+
+### "Retry with new circuit" button
+
+Circuit throughput varies wildly, and since this is a large download,
+it'll quickly wear out users' patience if a bad circuit is picked.
+Or maybe this can happen behind the scenes, e.g.: Automatically
+switch circuit every X minutes or Y% progress? That could even make
+fingerprinting the download on the Tor client <-> Entry Node side of
+the pipe a bit more difficult, for whatever that's worth.
+
+[[!tag priority/elevated]]
diff --git a/wiki/src/blueprint/macchanger.mdwn b/wiki/src/blueprint/macchanger.mdwn
new file mode 100644
index 0000000..94ac277
--- /dev/null
+++ b/wiki/src/blueprint/macchanger.mdwn
@@ -0,0 +1,271 @@
+[[!toc levels=2]]
+
+Rationale
+=========
+
+All network interfaces, both wired or wireless, have a unique
+[[!wikipedia MAC address]] which is broadcasted on any local network
+it is connected to (for wireless interfaces that also means that any
+radio receiver in the vicinity sees it). The uniqueness of this
+address is problematic, as it can:
+
+* be used a to tie a computer and its owner to a time and place for
+ observers with a list of device MAC addresses and their owners,
+* or at least track the location history of a specific device, which
+ can tell a great deal about its owner.
+
+While broadcasting the MAC addres in one's home *only* is not problem,
+broadcasting the MAC address in public is, so we need to devise a
+simple user interface which gives the option to obfuscate this address
+when using Tails in public.
+
+
+Use cases
+=========
+
+Wired networking
+----------------
+
+We could distinguish two main use-cases:
+
+* using a public computer (e.g. in a library, Internet-cafe) => the mac
+ address should not be changed, as it may bring undesired admin
+ attention and/or simply forbid access to the Internet
+* using a personal computer (e.g. a laptop, wherever it happens) =>
+ the mac address should be changed
+
+A way to integrate this analysis UI-wise could then be to allow, in a
+[[todo/boot_menu]], to choose between the default case (that
+has to be decided) and the other one, using simple words such as "I am using a
+public computer" instead of speaking geek-language about mac addresses or
+whatever.
+
+As a bonus, other unrelated settings could also be automatically
+changed at runtime depending on the answer to this question.
+
+Enabling the "public computer" mode could setup the needed bits so
+that every network interface has its mac address changed before
+attempting to access the network.
+
+Wireless networking
+-------------------
+
+The Wi-Fi usecase is a bit different: the public / private computer
+distinction does not make sense, but there are two main situations:
+
+1. Some Wi-Fi networks restrict access to a list of known
+ MAC addresses, so in this case, the user of a known computer
+ wants to use their real MAC address.
+2. In most (all?) other cases, we want to anonymize the MAC address.
+
+So, as suggested by <tailshelper@tormail.org> on the tails-dev
+mailing-list (January 2013), Wi-Fi adapters' MAC address should be
+randomized by default, with an option in tails-greeter to set the
+original address back.
+
+Whonix' use cases overview
+--------------------------
+
+See <https://sourceforge.net/p/whonix/wiki/MAC/>.
+
+Caveats
+=======
+
+Randomizing mac adresses has several cons:
+
+* may trigger attention of admins of the network.
+* may break in some network configuration were static addresses are
+ assigned by a DHCP server based on the interface mac address, and/or
+ ARP tables are fixed to avoid spoofing.
+
+According to chapter 3.4.7 of the [Incognito's
+documentation](http://www.browseanonymouslyanywhere.com/incognito/uploadfiles/docs.html),
+Incognito does have an option in the boot menu and an [initrd
+script](https://tor-svn.freehaven.net/svn/incognito/trunk/root_overlay/etc/init.d/macchanger),
+and the randomization is done on a small part of the mac address.
+It does not really solve both issues, it's still not working for
+static DHCP, and if mac adresses are watched, even modifying only it's
+end would probably trigger an alert (admins willing to see if mac
+addresses are changing may have installed an automated way to do it,
+like arpwatch).
+
+However, as Tails is based on debian live and using network-manager
+for its network configuration, it introduces new questions: what if an
+USB wireless dongle is inserted in Tails after it has booted?
+Network manager will automatically begin to scan the network with a
+non-fake mac address. Is it a problem?
+
+User interface
+==============
+
+Tails Greeter option
+--------------------
+
+As has been proved many times on our forum, MAC addresses is a big
+source of user confusion. To help users make a good choice we probably
+want to avoid a wording that contains the word "MAC address", both to
+accomodate users that don't know what that is, and users whose
+misconseptions may lead them to pick a sub-optimal option. Wordings
+like "I am using a public network" or "I am using a public computer"
+are preferred for these reasons.
+
+Ideally we'd like a single, binary option (e.g. a check box) whose
+state then determines what to do with each network interface, but
+depending on the use cases we want to support (see dedicated section
+above), that may be too limiting. For instance "public vs home/trusted
+network" and "public vs owned/trusted computer" result in four
+different combinations. However, having two binary options for the
+above could prove interesting for other features than MAC changer, so
+it may be worthwhile (note, this list is not a list of TODOs; just a
+list of examples that may motivate adding the above *two* options):
+
+* On a public/untrusted computer we may want to completely disable
+ certain hardware to
+ [[todo/protect_against_external_bus_memory_forensics]].
+* On a public/untrusted computer we may want to disable keyboard input
+ for the [[doc/first_steps/persistence]] passphrase and
+ [[doc/first_steps/startup_options/administration_password]] (due to
+ the threat of hardware key loggers), forcing usage of a
+ [[virtual keyboard|todo/Add_a_virtual_keyboard_in_Tails_Greeter]].
+* On a public/untrused network we may want to disable network
+ printers.
+
+Post-login
+----------
+
+Since MAC changing can cause network problems (see "Caveats" section
+above) we may want to try to detect such errors after we've logged in.
+Upon detection we could show a notification linking to some
+appropriate documentation, and offer the option to reset the MAC
+address of the device to the default and re-connect.
+
+Implementation
+==============
+
+ifupdown
+--------
+
+An [ifupdown script](https://help.ubuntu.com/community/AnonymizingNetworkMACAddresses),
+put in `/etc/network/if-pre-up.d/` can do the job, but this solution is
+permanent and not easy to disable, as each time an interface will be
+reconfigured it's mac address will be automatically changed. This
+solution does not help really if we want users to be able to choose to
+enable/disable it (at boot time or on a running Tails). At least it
+integrates nicely in an environement where NetworkManager is in charge
+of the network configuration, but still that doesn't solve the user's
+choice problem.
+
+> My take on this is that this place is the one where we can ensure
+> the mac address is changed (or not) when needed; at least it works
+> when network configuration is done through `ifupdown` or Network
+> Manager (but not when using `ip` or `ifconfig` by hand; if we really
+> want to support these, I guess that only udev rules can do the job
+> properly).
+>
+> Anyway: IMHO, using this `.d` directory or not is pretty unrelated
+> to the method used to get the user's choice. Enabling/disabling such
+> a ifupdown script is quite feasible:
+>
+> * if chosen at boot time: a `live-initramfs` hook will do the job,
+> based on `grep /proc/cmdline`
+> * if chosen by any nice-random-desktop-UI: a suid wrapper could
+> toggle this script on/off, restore the original mac address and
+> restart Network Manager as needed.
+
+Network Manager
+---------------
+
+Network Manager does actually support plugins, that could be a way to
+interface it with macchanger, and have the user prompted before
+configuring the network to ask if the interface have to be randomized
+or not. A button could also be added to enable/disable this feature.
+Attention have to be taken on the way it would be done at boot
+time too.
+
+An easy interface to propose to get the original mac address back, in
+case Network Manager fails to get a working networking setup, would be
+a nice bonus.
+
+macchanger-gtk
+--------------
+
+A GTK interface to macchanger does exist:
+[macchanger-gtk](http://www.mogaal.com/macchanger-gtk). Might be
+usable as the button to let people use macchanger on a running
+Tails, but it lacks a way to restore genuine hardware address. It's
+packaged in Debian ([[!debpkg macchanger-gtk]]).
+
+macchiato
+---------
+
+Our [[MAC address design document|contribute/design/MAC_address]]
+explains the way we've chosen until now to generate partially random
+MAC addresses.
+
+It's mostly implemented by
+[macchiato](https://github.com/EtiennePerot/macchiato): a Bash
+script, released under the 3-clauses BSD license, that assigns
+a random MAC address to specified network interfaces, using lists of
+per-device-type common vendor OUI. It can be configured per-device,
+has code to generate udev rules, and has some systemd integration.
+It's been described in more details [in a blog
+post](https://perot.me/mac-spoofing-what-why-how-and-something-about-coffee).
+
+However, there are issues with this approach:
+
+* as of February 2013, macchiato's lists are very short; the author is
+ open to adding to them, but it does not come for free
+* There are web interfaces out there to query the ieee.org OUI database,
+ like [this one](https://db.uga.edu/network/public/vendorcode.cgi).
+* A list of the biggest ethernet vendors is quite harder to find, but
+ [wikipedia](https://secure.wikimedia.org/wikipedia/en/wiki/List_of_PC_hardware_manufacturers#Network_cards)
+ can help, as some other sites
+ [here](http://www.mcgelec.com/Support/mfglinks/nics-wired.aspx) or
+ [here](http://www.charydent.com/network-adapter.asp)
+
+So, the path we've chosen (choose 20 most common vendors) seems to be
+harder than expected, and maybe rather choosing to randomize only the
+last part of the MAC address while keeping the original vendor prefix
+would be easier.
+
+Improving macchanger
+====================
+
+Some of our goals would be easier to achieve by patching macchanger
+itself. Since it's been unmaintained upstream for a while, we've been
+discussing and working with someone who has taken its maintenance over
+and has already started patching it to better suit our needs:
+
+* [Redmine project](https://labs.riseup.net/code/projects/show/macchanger)
+* Git repository: `git://labs.riseup.net/backupninja.git`
+* Debian packages: the maintainer of the macchanger package in
+ Debian has already integrated some of these patches (uploaded to
+ sid: 1.5.0-8) and is likely to go on this way. Tails has been
+ using this improved version for a while.
+
+Inspiration sources
+===================
+
+Haven
+-----
+
+Haven does not automatically start network-manager at boot time.
+It provides shortcuts in the application menu to run macchanger-gtk
+and start the network if desired.
+
+Liberte Linux
+-------------
+
+Liberte Linux randomizes wireless MAC addresses at boot time and
+allows changing wired interfaces' MAC addresses after boot, see their
+`src/usr/local/sbin/mac-randomize` that uses `ifconfig IFACE hw ether`
+rather than macchanger.
+
+Documentation
+=============
+
+Investigate and possibly document the kind of information that could
+still be seen on the LAN about the system. Such as the manufacturer (ex:
+Sony), model number, BIOS and version, etc.?
+
+[[!tag release/1.0]]
diff --git a/wiki/src/blueprint/protect_against_external_bus_memory_forensics.mdwn b/wiki/src/blueprint/protect_against_external_bus_memory_forensics.mdwn
new file mode 100644
index 0000000..bb0403c
--- /dev/null
+++ b/wiki/src/blueprint/protect_against_external_bus_memory_forensics.mdwn
@@ -0,0 +1,26 @@
+[[!toc levels=2]]
+
+Rationale
+=========
+
+It should not be that easy, for an attacker with physical access, to
+retrieve Tails memory. (Note that this will especially be the case for
+a [[Tails server|todo/server_edition]] instance left unattended.
+
+Archive
+=======
+
+## other implementation ideas
+
+* If a firewire card was inserted into the slot and the bus is active,
+ pop up a dialog and ask "hey, you want to use firewire/etc.?"
+* disable these buses by default, allow opt-in through tails-greeter
+ to enable
+* ask that users assert they want to use this or that bus, and make
+ the assertion bind to a single device, rather than all devices
+ blindly
+* de-activate PCMCIA and ExpressCard on systems that don't have any
+ PCMCIA or ExpressCard devices after running for 5 minutes. This is
+ going to byte some users, but probably only the first time.
+
+[[!tag release/3.0]]
diff --git a/wiki/src/blueprint/remember_installed_packages.mdwn b/wiki/src/blueprint/remember_installed_packages.mdwn
new file mode 100644
index 0000000..da51a9e
--- /dev/null
+++ b/wiki/src/blueprint/remember_installed_packages.mdwn
@@ -0,0 +1,98 @@
+When user have enabled persistence, it could be nice to remember which
+extra packages they have installed.
+
+We propose to use the term "your additional software" to mention to the
+user those packages in the GUI, notifications, etc.
+
+This feature will be implemented in several steps.
+
+[[!tag release/2.0]]
+
+Past research
+=============
+
+Possible interfaces
+-------------------
+
+### 1
+
+Either in the greeter or upon login, an
+interface could appear offering the user to select which packages should be
+reinstalled (all unselected by default).
+
+Having this choice in the greeter could allow users to install their preferred
+software without having an administrative password set.
+
+> This interface would quickly become messy, as soon as a desired
+> additional package pulls dozens (if not hundreds) of dependencies.
+
+### 2
+
+Alternative idea: in tails-persistence-setup, allow selecting
+packages (among the ones additionally installed during the current
+session, and/or offer a "All installed additional packages"
+option) to be automatically re-installed next time. Then, at boot
+time, when persistence is enabled, our live-persistence script (or
+something else started from tails-greeter) would (unconditionally?)
+read this packages list from the persistent volume and install them.
+
+Things to think about
+---------------------
+
+- security implications of this whole idea needs to be researched before
+ diving in the code.
+
+> since the cached APT packages are
+> hand picked by the user, security will depend on these packages and
+> security of the persistent volume where the *.deb are going to be
+> stored. Am I missing something here?
+
+- how to answer pontential apt/dpkg/debconf questions? record answers? force yes?
+
+- re-install these packages from cache only, or prefer fetching more up-to-date
+ versions from online mirrors if available? If we want to fetch updates, when
+ should the install start? Think about offline usage and about network
+ fingerprint.
+
+- should the packages been installed before starting the session (required for
+ packages related to session modification e.g. `msva-perl`) or after (e.g.
+ requiring network, like firmware downloader)
+
+Possible implementation tricks
+------------------------------
+
+### Installing at startup, then upgrading
+
+One solution to the upgrad/offline use problem might be to install the packages
+at from cache at startup, then to try to fetch upgrades and install them if
+network appears.
+
+### Creating a list of user-installed packages
+
+A configuration snippet can be add in `/etc/apt/apt.conf.d` with a
+`Dpkg::Post-Invoke` option. This allows to trigger a script each time
+APT is run.
+
+This script should query APT database and record all packages that are
+not in `autoinstall` state.
+
+On boot time, that list should be filtered with packages that are already
+shipped with Tails.
+
+> Here's an example script which filters shipped packages on runtime instead:
+>
+ comm -23 <(list-manually-installed-packages) <default-packages.txt >session-packages.txt
+ comm -23 <(cat session-packages.txt|sort) <(cat saved-packages.txt|sort) >> saved-packages.txt
+>
+> It mantains a list of packages manually installed by the user in saved-packages.txt. This file should be placed in its own directory so it can be made persistent.
+>
+> list-manually-installed-packages is another script which does what its name says. In squeeze it can be done with:
+>
+ comm -3 <(dpkg -l | grep '^ii' | cut -d\ -f 3|sort) <(apt-mark showauto|sort)
+>
+> When we move to wheezy it may simply become 'apt-mark showmanual', if it proves to be equivalent.
+>
+> default-packages.txt is the list of packages shipped with Tails, generated at ISO creation time with list-manually-installed-packages
+>
+> session-packages.txt is a temporary file, can be placed in /tmp
+
diff --git a/wiki/src/blueprint/replace_truecrypt.mdwn b/wiki/src/blueprint/replace_truecrypt.mdwn
new file mode 100644
index 0000000..3d91fe5
--- /dev/null
+++ b/wiki/src/blueprint/replace_truecrypt.mdwn
@@ -0,0 +1,27 @@
+Due to various concerns, Trecrypt is about to be replaced in Tails,
+either by tcplay or cryptsetup.
+
+# Candidate alternatives
+
+## Tc-play
+
+[tc-play](https://github.com/bwalex/tc-play) is a Free implementation
+of TrueCrypt based on dm-crypt, licensed under the 2-clause BSD license.
+It is in Debian sid ([[!debpts tcplay]]), and would serve as a full
+replacement of TrueCrypt... once a proper GUI available.
+
+## Cryptsetup
+
+[Cryptsetup 1.6 supports reading the TrueCrypt
+on-disk format](https://code.google.com/p/cryptsetup/wiki/Cryptsetup160),
+so if/when udisks and friends are adapted (if needed), then we could
+as well avoid shipping any additional software at all. It is part of
+Debian unstable.
+
+## Zulucrypt
+
+[zuluCrypt](https://code.google.com/p/zulucrypt) is a front end to cryptsetup
+and tcplay, it make easy to manage Truecrypt
+volumes through a GUI, but it's not packaged in Debian.
+
+[[!tag release/2.0]]
diff --git a/wiki/src/blueprint/server_edition.mdwn b/wiki/src/blueprint/server_edition.mdwn
new file mode 100644
index 0000000..b1f6ca4
--- /dev/null
+++ b/wiki/src/blueprint/server_edition.mdwn
@@ -0,0 +1,410 @@
+[[!meta title="Tails server: Self-hosted services behind Tails-powered Tor hidden services"]]
+
+[[!toc levels=3]]
+
+Use cases
+=========
+
+Secretly work on a document
+---------------------------
+
+John, Jane and Miranda would like to secretly work on a
+document.
+
+Possible solutions follow.
+
+### 1. Centrally hosted Etherpad
+
+Tails can be used to access a centrally hosted Etherpad.
+
+Their physical location and identities should be properly concealed
+but the document itself can be intercepted by the server operators.
+
+They would like to have other means than blind trust to keep the
+secrecy.
+
+### 2. OpenPGP-encrypted messages in a shared mailbox or a drop.io space
+
+Tails can be used to pass GnuPG-encrypted messages through a shared
+mailbox or a drop.io space.
+
+This sounds like a pretty good answer but they are under a lot of
+pressure and are likely to make mistakes. Leaking a clear-text version
+to the service provider would be fairly easy under stress.
+
+### 3. Gobby and SFTP servers behind a Tails-powered Tor hidden service
+
+Anyone amongst John, Jane and Miranda could use Tails to host Gobby
+and SFTP servers behind a Tor hidden service. Others would also use
+Tails to reach them.
+
+Keeping such servers at hand, on a live system, behind an hidden
+service is likely to prevent erroneous disclosure.
+
+The vision
+==========
+
+Let's talk about group collaboration, communication and data sharing
+infrastructure, such as chat servers, wikis, or file repositories.
+
+Hosting such data and infrastructure *in the cloud* generally implies
+to trust the service providers not to disclose content, usage or users
+location information to third-parties. Hence, there are many threat
+models in which cloud hosting is not suitable.
+
+Tor partly answers the *users location* part; this is great, but
+*content* is left unprotected.
+
+There are two main ways to protect such content: either to encrypt it
+client-side (*security by design*), or to avoid putting it into
+untrusted hands in the first place.
+
+Cloud solutions that offer security by design are rare and generally
+not mature yet. The *Tails server* project is about exploring the
+other side of the alternative: avoiding to put private data into
+untrusted hands in the first place.
+
+This is made possible thanks to Tor hidden services, that allow users
+to offer location-hidden services, and make self-hosting possible in
+many threat models. Self-hosting has its own lot of problems, however,
+particularly in contexts where the physical security of the hosting
+place is not assured. Combining Tor hidden services with Tails'
+amnesia property and limited support for persistent encrypted data
+allows to protect content, to a great degree, even in such contexts.
+
+This vision aims at making it easy for end-users to implement
+solutions described above and based on Tor hidden services hosted on a
+Tails system.
+
+Tails server should be able to run common services like a web
+server, a Jabber daemon, wiki, file repository, etc.
+
+Data and configuration for services would be stored on an encrypted
+flash media. Targeted hardware to run "Tails server" would be an
+old laptop with broken hard-disk, battery, screen or keyboard;
+something quite common these days.
+
+In short, setting up a new Tails server would be done by:
+
+1. Alice plugs a USB stick into a running desktop Tails system.
+2. Alice uses a GUI to easily configure the needed services.
+3. Alice unplugs the USB stick, that now contains encrypted services
+ configuration and data storage space.
+4. Alice plugs that USB stick (and possibly a Tails Live CD) into the
+ old laptop that was dedicated to run Tails server.
+5. Once booted, Alice enters the encryption passphrase either directly
+ using the keyboard or through a web interface listening on the
+ local network.
+6. Then, Bob can use the configured services once he gets a hold on
+ the hidden service address. (The *petname system for Tor hidden
+ services* project would be very complementary to this one, by
+ the way.)
+
+Tails server should content itself with hardware that is a bit old
+(such as a PIII-450 laptop with 256MB of RAM) and/or half broken (e.g.
+non-functional hard-disk, screen or keyboard).
+
+Roadmap
+=======
+
+This project [was accepted](https://www.torproject.org/getinvolved/volunteer.html.en#tailsServer)
+for GSoC 2012, and worked a bit before the student dropped the ball.
+You can check the proposal [here](https://dustri.org/pub/tails_server.pdf)
+
+The challenges behind this project are:
+ * Design and write the services configuration GUI [keywords: edit configuration files, upgrade between major Debian versions, debconf, Config::Model, augeas].
+ * How to create the hidden service key? [keywords: Vidalia, control protocol].
+ * Adapt the Tails boot process to allow switching to "server mode" when appropriate.
+ * Add support, to the Tails persistence setup process, for asking an encryption passphrase without X, and possibly with a broken keyboard and/or screen [keywords: local network, SSL/TLS?, certificate?].
+
+Timeline
+========
+
+Turn an USB stick into an USB Tails server stick
+------------------------------------------------
+The user should be able to create a Tails server USB stick, which should boot in Tails server mode by default, and no more to Tails. During this milestone, there are no or only small differences between Tails and Tails server except that the system is aware that he is booting into Tails server.
+
+Unlocking persistence without a GUI
+---------------------------------------
+The end user should be able to unlock and boot a Tails server USB stick without any GUI.
+
+Remote administration
+---------------------
+The user should be able to have a secure shell (SSH) on the machine, to do administration tasks without a physical access to the Tails server, or a GUI. Please note that this shell is not a Tor hidden service for now.
+
+Remove unnecessary/irrelevant things from boot process
+------------------------------------------------------
+Tails server should not spawn a full-featured desktop anymore: the goal of this iteration is to remove as much irrelevant services as possible (e.g GNOME, Xorg, ...) in order to reduce boot-time and system resources. The only way the user have to do administration's related tasks is to use SSH.
+
+Setup Tor hidden services
+-------------------------
+This part is a little bit unclear for now.
+
+Setup and start a gobby service
+-------------------------------
+This is the first Tor hidden service implementation and it will allow the user to run a Gobby service from the Tails server. This step does not involve any configuration of the service, only the setup; no user interactions are involved during this milestone, since there is no configuration involved.
+
+Basic configuration management
+------------------------------
+The user should be able to edit the configuration of the Gobby service during the creation of the Tails server USB stick; like using a password, changing the service's name,
+
+
+Requirement/Deliverable
+=======================
+ * Clean design and documentation
+ * Everything hosted through Tor hidden services
+ * Amnesic system
+ * Switch to Tails server on boot
+ * Support for persistence to save preferences/configurations.
+ * GUI configuration tool
+
+
+Implementation
+==============
+
+Switch to "server mode" at boot time
+------------------------------------
+
+What follows is a preliminary implementation plan that allows us to
+ship ISO images that are able to boot in "server mode" or in "desktop
+mode".
+
+This should be refined to integrate better into the standard Debian
+Live boot process. E.g. the standard persistence support should be
+used to iterate over block devices, find the one that contains the
+server configuration and decrypt it.
+
+When starting a server we *must* have the server configuration present
+on a USB drive during boot, so we can simply check for its presence
+with a hook in early init. If present, then we enter server mode and
+don't start X, network manager, etc., otherwise we just boot Tails
+in the normal fashion.
+
+Elaborating on my suggestion above, what I describe below will have the
+server mode init sequence logic happily contained in two init scripts
+that are specifically made for this purpose, so no other init scripts
+will be bloated with conditionals or altered in any way:
+
+As I said, we introduce two new init scripts:
+
+1. `server-check`, which is run as early as possible (i.e. as
+ soon as the filesystem is up and we can mount USB drives)
+2. `server-mode`, which is run once the network is up
+
+`server-check` will loop through all USB drives (even the one Tails
+is running from if running from USB) and for each `$X` of them, in
+turn:
+
+1. check for the presence of a storage media containing a Tails-server configuration,
+using GPT partition's label.
+2. if the check failed continue to loop
+3. if the check succeeds, ask the passphrase and activate persistance storage (see below)
+
+So, if no drive contained a server configuration `server-check` exits and boot continues as usual. If a Tails-server configuration was encountered, the file `/var/lib/live/tails-server-mode` is created.
+
+`server-mode` will check if the server state file exists and contains
+a valid path to a file, namely the server configuration. If the check
+fails, boot continues as usual, otherwise the server-mode service
+will, in chronological order, take care of:
+
+1. receiving the configuration encryption password some how
+2. decrypting $(cat /var/lib/live/tails-server-mode)
+3. starting the ssh daemon, http server, wiki software, etc.
+ using their decrypted configuration files
+4. updating torrc with the decrypted configuration
+5. sending tor a SIGHUP so it will reload its configuration and
+ finally start the hidden service(s)
+
+If any of the above fails an appropriate error message should be shown
+to the user. Possibly we could start X and network manager (i.e. like
+in a normal boot) show the error there and then let the user try to
+sort out the error, e.g. by mounting the server configuration and
+editing the faulty config file, or by using the GUI you talked about
+to create a completely new server configuration.
+
+Boot process
+------------
+The default for a given Tails server installation is to boot in Tails server
+mode.
+
+### Check configuration presence
+When Tails boots, it will at some point
+check for the presence of a storage media containing a Tails server
+configuration, using GPT partition's label. So, the boot continues in
+Tails server mode, if not, boot continues for normal Tails, the user
+warned, and prompted about what should be done, either reboot in
+Tails, or recheck for a preference USB stick.
+
+### Asking the passphrase and activating persistence storage
+(this part is not chronological)
+
+#### Advertising on the LAN
+Tails-server needs to advertise his presence and location on the LAN.
+The less worth manner is to use avahi/zeroconf. Since they can be more than on Tails-server on
+the same LAN, I think that the user may choose the named advertised by avahi for his server; since the LAN is an untrusted network, using the .onion hidden service name for this purpose is not an option.
+
+#### LAN
+Since the most common setup is a LAN with a modem/router
+provided by the ISP, they contains at least one untrusted machine. So MITM attacks are likely to happen; this is why we need to be able to authenticate the server. Doing so require that the client carry some informations about the server (certificates, and/or ssh keys).
+
+#### Dropbear
+A possible solution would be to take advantage of the cryptsetup/dropbear integration in debian to boot encrypted (but /boot) system. The client would log using ssh into Tails-
+server, and enter the passphrase using a custom shell which is
+roughly a passphrase-prompt. To make this solution more user
+friendly, a lightweight GUI on the client side that would basically launch avahi, scan the network, show available Tails-server (since they can be many), ask for a passphrase for the selected
+Tails-server and finally stop avahi could be easily developed.
+
+#### Webpage
+Another way would be to use a simple webpage (php/apache are overkill : a simple CGI would be fine) to get the passphrase. This approach allows a simple client-side GUI in that starts/stops
+avahi, and scans and lists Tails-servers (they can be severals).
+When clicked, iceweasel simply opens the selected server's webpage. This should even be doable in fairly small shell script using zenity. this solution has the advantage of being platform-
+independent.
+
+#### Authentication
+Self signed certificates do more harms than good, since they scare the user because of the browser warning. But, because Tails-server can only be created from Tails, generated
+certificates fingerprint could be stored in a ~/.Tails-server folder
+on the client : Any certificates found there would be added to
+iceweasel on as soon as Tails has opened the persistent volume
+and found this preset. Client's Ssh public key must be stored too,
+and written in the /.ssh/known hoss of the server.
+
+### ervices configuration with preseed
+Once Tails server is booted, it will preseed the Debian system's debconf database with the settings
+obtained from the Tails server configuration files.
+
+### Services installation
+Service's packages will be installed by APT (to
+take advantage of dependencies resolutions, upgrades, ..). Since the
+persistence code bind-mounting the cache directory onto the location
+where APT normally looks, there's nothing more to tell APT about.
+
+
+### Services configuration patches
+As previously said, not every packages
+will be configurable in a suitable manner. We will have to patch some
+software's configurations after their setup.
+
+### Services startup
+Since not every services supports autostart, this is the step during which
+they will be started. Moreover, some service configurations where patch
+
+
+Installation process of services softwares
+------------------------------------------
+Two solutions are available: either install all server softwares in the
+default Tails, or install them dynamically from the USB stick during
+the boot of Tails server. Even if the second solution is better (because
+it will not unnecessary bloat Tails), the first one is much more simpler to
+implement, and since it's not a critical (or even important) feature, it can
+be implemented later, outside the scope of the GSoC.
+
+Configuration management
+------------------------
+Tails-server will often require custom "default" configuration for a bunch
+of softwares due to its nature. Service configuration requires a nice way to
+handle the configuration files in order to avoid a complete disparate mess.
+In an ideal world, every services configurations should be handled by deb-
+conf (and not by some ugly monkey patching). Doing so will keep Tails-
+server upgrade-proof, since configuration file's format are not frozen, and
+may evolve between updates, using debconf will make this transparent.
+### Upstream (Debian)
+The best way is to ask to the related package maintainers to
+add in debconf options that we want to access from debconf to configure
+the package if they are not already present. Since the freeze of Wheezy (the
+next Debian stable) is planed for June, I don't think there will be time for
+this to happen any time soon. Most likely the debconf approach way will
+be postponed to the Wheezy + 1 Debian release(probably in 3 years).
+
+### Patch on boot
+If we can't get the options we want from the package maintainers, the
+most appropriate solution is to patch configurations files on bootime. Such
+patches can be augeas scripts, Config::Model somethings, or whatever seems
+robust enough.
+
+### Other options
+Some cases don't fit well into the "debconf or patch on boot" alternative.
+These situations would have to solved on a case-per-case basis.
+
+On Tails update
+---------------
+When a new version of Tails is available, the server admin should be warned
+about this. Tails already implements this mechanism in it's GUI, but as Tails
+server cannot rely on GUI in its normal operation, this must be redesigned.
+As a placeholder, the admin should be invited to subscribe to the amnesia-
+news mailing-list.
+
+Tails server configuration GUI
+------------------------------
+The purpose of this GUI would
+be to properly setup a persistence USB key for tail-server, with services
+configuration, authentication means, ...
+
+Time synchronization
+--------------------
+
+As contributed by adrelanos on tails-dev
+(<50293C63.2040807@riseup.net>), servers are supposed to run over
+longer periods without rebooting, days or weeks so Tails's current
+implementation with tails_htp is not sufficient for Tails Server.
+
+adrelanos suggests:
+
+> My recommendation is to run htpdate periodically, perhaps every
+> hour. Time exact minute should be randomized to avoid creating
+> a network fingerprint.
+>
+> Given what you already implemented with `tails_htp`, running
+> `tails_htp` frequently probable won't be hard. As I need it for aos,
+> I am planing to add a script to /etc/cron.daily, it will run another
+> script in background to avoid blocking anachron during the sleep
+> delay. The other script will simply pick a number between 0 and 3600
+> from /dev/random, sleep for the delay and then restart the
+> htpdate service.
+
+Resources
+---------
+
+### pairing
+
+* [git-annex' pairing design](http://git-annex.branchable.com/design/assistant/pairing/)
+
+### Vidalia's hidden services support
+
+In 0.3.x: was removed, should become a plugin someday: it's a [GSoC
+project](https://github.com/feroze/vidalia-plugins/tree/hiddenservice)
+by Feroze Naina <ferozenaina@gmail.com>; early in August 2012, is
+"awaiting being merged into the vidalia-plugins repo".
+
+In 0.2.x: works mostly well but we need to wait for
+[[!tor_bug 2579]] to be fixed.
+
+### The Incognito implementation
+
+The old Incognito actually has a very rudimentary support for hidden
+services which was setup in a similar way. However, it is limited to
+hosting static html pages using lighthttpd, but the script used might
+be worth looking at:
+
+- http://www.browseanonymouslyanywhere.com/incognito/uploadfiles/docs.html#hidden
+- https://svn.torproject.org/svn/incognito/trunk/root_overlay/etc/init.d/hidden-service
+
+### Anonymous Web Application Framework
+
+https://piratenpad.de/p/AnonymousWebApplicationFramework
+
+
+Simplified edition of this project
+=========
+
+### Would it be easier to implement a simpler version of this project?
+
+Would a simplified version of this project be easier to implement, and could it act as a precursor to the full blown implementation?
+
+* No remote administration. Less remote access is usually more secure. Many users will not want to use their desktop machines SSH client for administration because it is not amnesic
+* No zeroconf, zeroconf is insecure and advertises too many details on the local LAN
+* The basics of this project is to tell the tor configuraiton file there is a hidden service listening on a certain local port (e.g. apache) and to run that server software inside tails. Vidalia has a GUI for this too. This is a simpler version of the project, and would work to provide a hidden service from within a tails livecd
+* Would it be preferred to have the screenlock software installed as well so the server can run with a locked screen. Would need to have the ALT+F1,F2 etc gettys disabled or password protected.
+* A simpler version that does provide a hidden service, but only the bare minimum other features, would not prevent all the other useful features specified in this document from being implemented at a later date, and may get more people interested in using it
+* Some of the features in this document make more work to get them running, but would actually decrease security and anonymity (advertising on LAN, administering from a LAN PC)
+
+[[!tag priority/low]]
diff --git a/wiki/src/blueprint/tails-greeter:_revamp_UI.mdwn b/wiki/src/blueprint/tails-greeter:_revamp_UI.mdwn
new file mode 100644
index 0000000..4da9576
--- /dev/null
+++ b/wiki/src/blueprint/tails-greeter:_revamp_UI.mdwn
@@ -0,0 +1,281 @@
+[[!toc levels=2]]
+[[!tag category/greeter]]
+[[!tag release/2.0]]
+
+Rationale
+=========
+
+tails-greeter works fine, and its code in not that bad anymore, so on
+this side it's now feasible to add features (e.g. [[todo/macchanger]],
+[[todo/bridge support]]).
+
+However, the greeter UI is difficult to use, and adding more options
+in the current state of things would only make things worse
+usability-wise.
+
+So, we have to improve the greeter UI to make it more ergonomic and
+easier to use.
+
+Design
+======
+
+Clarify specification
+---------------------
+
+It would help a lot to clarify some areas of the greeter
+specification. This may involve revisiting a few past decisions:
+
+* Do we still want the first screen to look like a Windows (NT4)
+ login screen?
+* Do we still want a second screen for options? Or another way to
+ show it?
+* Do we want the look to depend on whether the Windows theme was
+ opted-in?
+* How much do we want to optimize for first-time users?
+
+Usability study
+---------------
+
+* Draft several User eXperience (and layout) options
+* Make them testable
+* Make an usability study:
+ - catch testers (Tails users and/or newbies)
+ - make them test, see what they do and ask them what they think
+
+We may want to ask input from UX experts, and/or pay one to run the
+usability study.
+
+Prototypes
+==========
+
+Some proposals to test!
+
+## Goals
+
+My goals for the interface was:
+
+- read in "natural" order: top to bottom
+- no hidden windows/options
+- easy to adapt to right-to-left languages RTL
+- inspired/similar to GNOME3 "system preferences"
+
+## Screenshots
+
+Please test the script below, which lets you try the user experience!
+
+The greeter started from DVD:
+
+[[!img greeter.png align="right" size="" alt=""]]
+
+The greeter started from USB with persistence:
+
+[[!img greeter+persistence.png align="right" size="" alt=""]]
+
+The greeter started from USB with persistence once language selected:
+
+[[!img greeter+persistence+kbd.png align="right" size="" alt=""]]
+
+The greeter once the administration password option clicked:
+
+[[!img greeter-opt-adm.png align="right" size="" alt=""]]
+
+The greeter once the keyboard option clicked:
+
+[[!img greeter-opt-locale.png align="right" size="" alt=""]]
+
+The greeter once the windows camouflage option clicked:
+
+[[!img greeter-opt-persistence.png align="right" size="" alt=""]]
+
+## How to test
+
+Download everything in [[tails-greeter: revamp UI/mockups]], or better clone the git, go to the
+directory and:
+
+ $ ./mockup.py [-v <variant>] [-p]
+
+Dependencies: gtk3, python gobject introspection (basically debian wheezy)
+
+## Questions
+
+I'd like to hear about:
+
+- your overall impression?
+- should keyboard selectable independently from locale in one click?
+- your navigation experience?
+- where should the locales box be?
+
+(Note that some answers were sent on tails-dev already.)
+
+## Remarks (add yours!)
+
+- add a symbol if option was visited/activated
+- activation of presets in persistence: when?
+
+Resources
+=========
+
+Related tickets
+---------------
+
+* Moving stuff *out of* the greeter:
+ [[todo/allow_choosing_language_at_installation_time]]
+
+Past discussions
+----------------
+
+* <https://mailman.boum.org/pipermail/tails-dev/2012-March/000936.html>
+* thread starting at
+ <https://mailman.boum.org/pipermail/tails-dev/2012-March/000972.html>
+
+Past work
+---------
+
+* `feature/single_toggle_button` branch in tails-greeter repo
+
+UI / UX documentation
+---------------------
+
+* [GNOME's studies](http://live.gnome.org) on the subject
+
+Feedback
+========
+
+This is feedback about the *current* greeter.
+
+Report #1
+---------
+
+User interface is confusing.
+
+The combination of "green/red icons + the check mark + pushed button" is
+really hard to grasp.
+
+How about a big push button labeled "Persistence", maybe with an icon?
+
+The current behaviour for "More options?" is also problematic... How about
+having a "More options" button at the bottom, near the "Login" button?
+Ideally, this would require a "Back" button on the "Administration
+password" scren, but even without it, I think the result will be easier
+to understand/use.
+
+> How about using checkmark boxes or Yes/No radial dials, or not use
+> them at all? Entering a password into a box means it's enabled, and
+> leaving it empty implies you don't wish to use the feature. The text
+> in my example here is a bit big though:
+
+[[!img menu.png align="right" size="" alt=""]]
+
+Report #2
+---------
+
+A few impressions after the publication of the screenshots. Great job
+by the way!
+
+The buttons ON/OFF are sometime confusing, as it's hard to know if it
+reflects the actual configuration, or the ability to modify this
+configuration, i.e. if the option is *actually* activated or if
+clicking on this button will toggle this option ON. I hope I'm clear
+enough :)
+
+Please also keep in mind that some use small screens, and can get
+blocked if the cannot see the validation button.
+
+Last point, as I will have to use Tails-greeter *at each boot*,
+I would like to be able to handle it easily with the keyboard, to save
+a lot of time.
+
+That said, thanks a lot for the great job!
+
+Report #3
+---------
+
+Indeed, this is a great polishing of the user interface, at least in
+terms of appearance. I failed to download anything from the mockups
+page though so be aware that this opinion is based on the screenshots
+only
+
+I do have some corrections and suggestions though, from the screenshot
+it is apparent that it allows to choose "Portugues" (with a eacute) as
+a region/locale, which is not! It is a river and neighborhood in Porto
+Rico. "Portugues" (with a ecirc) is the correct word for Portuguese in Portuguese.
+
+Now as for if "Should keyboard selectable independently from locale in
+one click?", I would say yes as I use it in the current greeter. I do
+this for two reason: First in case my tails session gets owned the
+attacker will perhaps not know from which country I am though I am
+aware in that situation I probably have far worse problems as far as
+de-anonimization goes. And second, I am fluent in English, and
+I prefer to see the menus and the documentation in English (as are
+more complete). Having to scroll down to get the Portugal keyboard in
+the current greeter is quite annoying though and I often wonder why
+are the other languages more obscure keyboards (like without dead keys
+and etc) before the more default options. Perhaps ordering
+alphabetically by languages and after all the defaults keyboards then
+again the lesser keyboards in this new greeter? (btw why is Portuguese
+absent from the locales screenshots?)
+
+A last, but most important imho suggestion: no matter how ergonomic
+you can make the greeter it will always have some usability problems,
+but there is a way to minimize this! There is already a todo ticket
+for choosing language at installation time ( see:
+https://tails.boum.org/todo/allow_choosing_language_at_installation_time/ )
+but then if someone got hold of your tails she/he could see from where
+you are and what language you speak. Now, if a new feature in the
+greeter was implemented - "Greeter Password" (pass-phrase would be
+overkill in this case as usability is preferred) - language, locale,
+but also camouflage, read only options for persistence, keyboards and
+other options to come in the greeter, could be defined at installation
+time and accessed at boot time with a few keystrokes from universal
+keys in keyboards. Or perhaps you have two greeter configurations and
+could setup two passwords.. If you think this feature could be useful
+perhaps you could revamp the greeter with this in mind for a future
+version? ;)
+
+Okay that's its :) the overall opinion of the greeter from the
+screenshots is that you made an amazing job :-) congratulations and
+thanks :-)
+
+Possible roadmaps
+=================
+
+0. [[Decide what DM and language / UI toolkit we will use for the
+ greeter in Wheezy|todo/tails-greeter vs. Wheezy]]
+0. Adapt following plans accordingly
+0. Gather more input from people who have strong opinions about the
+ t-g UX: the idea is to encourage work on the greeter by bringing
+ early positive input rather than late negative feedback.
+ This should happen in [the dedicated
+ thread](https://mailman.boum.org/pipermail/tails-dev/2012-October/001781.html).
+0. Clarify specifications (see the *Design* section above)
+ 0. research a bit the pending questions
+ 0. raise these topics for discussion among Tails developers
+0. Implement plan A or plan B
+0. Update documentation
+0. Send software and documentation for translation on tails-l10n
+
+Plan A - incremental UI changes
+-------------------------------
+
+The idea is to draft a new possible version first, and then we can
+decide whether we want to ship it right away, or create other options
+and benchmark them through a full-blown usability study.
+Alan committed to lots of things in this plan, but not to
+any deadline.
+
+0. Ask for ideas
+0. Propose one or several prototypes
+0. **Next thing to do**: make some testing happen by various kinds of
+ users
+0. Extract something useful from the result
+0. Implement the chosen proposal in a dedicated branch of the greeter
+ repo
+
+Plan B - full UI rewrite with usability study
+---------------------------------------------
+
+0. Design and sketch prototypes
+0. Organize a usability study
+0. Implement the winner idea
+
+[[!tag priority/high]]
diff --git a/wiki/src/blueprint/vpn_support.mdwn b/wiki/src/blueprint/vpn_support.mdwn
new file mode 100644
index 0000000..04519a5
--- /dev/null
+++ b/wiki/src/blueprint/vpn_support.mdwn
@@ -0,0 +1,60 @@
+[[!toc levels=2]]
+
+# What we don't want
+
+Some users have requested support for VPNs in Tails to "improve" Tor's
+anonymity. You know, more hops must be better, right?. That's just
+incorrect -- if anything VPNs make the situation worse since they
+basically introduce either a permanent entry guard (if the VPN is set
+up before Tor) or a permanent exit node (if the VPN is accessed
+through Tor).
+
+Similarly, we don't want to support VPNs as a replacement for Tor
+since that provides terrible anonymity and hence isn't compatible with
+Tails' goal.
+
+# What we want
+
+## Tails -> Tor -> VPN
+
+### Use cases
+
+1. Access services that blocks Tor.
+2. Reach a local resource on a VPN that is not accessible in any other
+ way.
+3. Reach a VPN non-anonymously (e.g. your account is tied to you IRL)
+ while only hiding your geo-location, which may be the only thing
+ you need in some situations. (Maybe invalid since this is not part
+ of the PELD spec (yet?) AFAIK.)
+
+### Solution
+
+The easiest way to solve use case 1 (which we feel is the most
+important one for this Tor/VPN setup) is to use a SSH connection with
+the `DynamicForward` option. The newly created SOCKS port can be used to
+have a fixed outgoing IP address. We could write on how to use that in
+an "unsupported, advanced users only, may kill kittens" part of the
+documentation.
+
+Note that this setup isn't relevant for I2P for the same reason that
+it's irrelevant for Tor hidden services.
+
+## Tails -> VPN -> Tor/I2P
+
+### Use cases
+
+1. Make it possible to use Tails at airports and other pay-for-use
+ ISPs via iodine (IP-over-DNS).
+2. Access Tor on networks where it's censored.
+3. Some ISPs require their customers to connect to them through VPNs,
+ especially PPTP. Tails is currently unusable for them out of the
+ box.
+
+### Solution
+
+Use cases 1 and 3 are worthwhile to support, and should be rather easy
+to implement. See tickets on [[Redmine|todo/vpn_support]].
+
+For all other uses of this setup (e.g. 2) we already promote bridges
+instead. Now that [[todo/obfsproxy]] is included, it should cover all
+our needs.