summaryrefslogtreecommitdiffstats
path: root/wiki/src/blueprint/veracrypt.mdwn
diff options
context:
space:
mode:
authorsajolida <sajolida@pimienta.org>2017-10-08 11:02:58 +0000
committersajolida <sajolida@pimienta.org>2017-10-08 11:02:58 +0000
commit465c7ef60bddfb7360eba1c01432920a53822a58 (patch)
tree2489589088030a04883fbd06015ab302143b226c /wiki/src/blueprint/veracrypt.mdwn
parentaeb67f4041fa8ce9a0fde7618bfb094d74eb6e34 (diff)
Rename blueprint to a shorter and up-to-date name
Diffstat (limited to 'wiki/src/blueprint/veracrypt.mdwn')
-rw-r--r--wiki/src/blueprint/veracrypt.mdwn46
1 files changed, 46 insertions, 0 deletions
diff --git a/wiki/src/blueprint/veracrypt.mdwn b/wiki/src/blueprint/veracrypt.mdwn
new file mode 100644
index 0000000..451ecfc
--- /dev/null
+++ b/wiki/src/blueprint/veracrypt.mdwn
@@ -0,0 +1,46 @@
+[[!meta title="Add TrueCrypt support to GNOME Disks"]]
+
+ * Selling points++: can benefit Debian, Ubuntu, Qubes OS and Subgraph
+ OS users. Not only Tails.
+ * We only aim to support _unlocking_ TrueCrypt volumes. If there's
+ time left we can add support for _creating_ them, but it's not a
+ hard requirement.
+ * GNOME Disks seems file-backed TC volumes are very commonly used, so
+ it's a use case we probably *must* support. But our user survey
+ (see below) will confirm this hypothesis.
+ * Ideally it should work just the same way it does for LUKS volumes
+ (they appear in Places, and can be unlocked via Files), so no
+ UX/design is required for block-device-backed volumes… but
+ file-backed volumes are different.
+ * GNOME Disks has an "Attach Disk Image" feature, so it definitely
+ has support for loop/file-backed storage devices. Still, it's not
+ 100% clear how hard it will be to add TC unlocking support in
+ there, so we need time to evaluate that, and if it's hard, to
+ evaluate other tools (zulucrypt-gui at least) in terms of
+ functionality & usability, before we can decide which tool we will
+ provide to unlock file-backed TC volumes.
+ * GNOME Disks does not have something equivalent to creating a fresh
+ disk image (not based on an existing disk) so we'd need to add that
+ if we have time to support _creating_ file-backed TC volumes.
+ * It's not 100% clear to us what exact set of features are needed for
+ supporting existing TC volumes in Tails. E.g. do we need to support
+ nested, hidden, file-backed volumes? It might be that some features
+ are very little used, and very hard to implement. So we'll do a
+ need-finding survey and an evaluation of the implementation cost;
+ these two sources of info will allow us to do a cost/benefit
+ analysis and to decide what exactly we will support. (E.g. it's not
+ completely clear how to fit in opening TC hidden volumes in GNOME
+ disks (may need to input *two* passphrases). So it would be easier
+ to focus on getting support for non-nested volumes
+ only... especially if actual Tails+TC users do not use this
+ feature, so we shouldn't spend time on it any way.)
+
+User research
+=============
+
+- Check what security guides are recommending:
+ - Talking to Security-in-a-Box we should focus on file containers and
+ hidden volumes in file containers. Because people are using other
+ tools for disk encryption and file containers also limit a bit the
+ amount of access that other operating systems have to the files
+ (avoids to have the partition full of viruses).