Hey there,
I am an artist who has been using Tails OS (3.0) for a few months now as
my main OS and have been working around some of the issues I found in
the experience and some solutions that I am prototyping and testing
currently. The works I am currently producing are all in someway related
to Tails. If this is the wrong place to post this, than I am sorry but
hopefully some of what I say will be useful to someone who reads it.
First, I found the issue of installation frustrating, the verification
is needed but for the non-technical seemed to me very tricky and
cumbersome. As a solution to this I devised a project "Tails in a Box"
which is low cost hardware based around non-specialist parts (Pi Zero
and associated setup) that flashes an inserted pen drive (or sd card,
with adapter) with a fresh copy of Tails. I have been trying to get this
to work with the Tails-Installer (which should be possible) but have not
yet, currently it flashes the iso that is available on tails.boum.org.
The idea here being that you move the trust from the users ability to
follow instructions (and presumably not feel apprehensive due to traffic
monitoring) to trust in the maintainer of the device. And would be
placed in an institution, hackspace or some public safe place where
someone with less technological knowledge or stronger digital
surveillance could go and get a copy of tails without having to take
time away from those who may not have the time to clone it for them. The
prototype code is available here
https://github.com/ixt/TailsInABox
Second, in response to watching a talk by ioerror I came over the phrase
"this one you eat" or something along those lines, which is in reference
to the second pen drive he would carry along with the tails on in order
to keep files. To this I adapted my dotfiles to contain a script that
would set up my environment. My dotfiles are here if you are interested
(the script is interesting rest not so much)
https://github.com/ixt/dotfiles
Over the last few weeks I've been working away at thinking this through
as the best modular approach and would like to pass it past you people.
To a user, this should be something that can be automatic. Instead (or
as well as) persistence the user should be able to load a payload
(encrypted container file) that can stored on an external device or
loaded from a hidden service (more on this in point 3). The payload
would contain dpkg files, configurations and identity information,
basically the diff between clean tails and a used one. The payload, in
my vision can be realized in 2 ways through a few different formats. If
the user has a Hidden Service under their control and access to the Tor
network they could mount a drive with sshfs which would keep the files
up to date on the server, this could be done behind the scenes as linked
files in their own dot folder or as a git repo in the home directory
(would probably mess up a few users configurations, but provides
history). The payload could be mounted on the external media too and
linked over for those without Tor network setup (or those who just want
that), this would also allow for much easier backup than current scheme
of persistence. This project has a repo on my github and is named in
spirit "To Eat"
https://github.com/ixt/ToEat it is not currently public
but in a day or so once I have a fully working prototype of the packing
and unpacking I will open it up. Right now it has a bit of a conflicted
goal, including an "Identity File" which contains information about the
user that can be made public if one is using a git repo (this
information should have things like gpg fingerprints and full keys) but
it is unclear if this is wise.
This brings me onto the third point, the one that is ultimately the
reason I'm posting here right now. I notice from time to time mentions
of "Tails server" which I'm still unsure the purpose of, with the
payload roughly talked about above it would be given a purpose for the
user as well as a host. In pairing (or not) with ToEat, I devised
"ToBury" which is a shell script (and eventually modular setup system)
that can quickly install and launch a hidden service on a standard
raspbian-lite system (thats what I am targeting). The aim of this
project is to provide a easy (and non-suspicious) way of getting Tor
Hidden Services up and running on relatively easy to obtain hardware.
The basis is currently that when the Pi is started up (and given
internet access) the user pulls down the setup script (currently,
install git, init in home dir, add my repo as remote, pull it down) then
they would only ever need to follow on screen instructions. Currently
the only option right now is a prototype, it sets up a "base" install
that contains Nginx, SSH and Tor configurations. SSH keys are generated
tarballed up and served by the Nginx instance, the user pulls these down
and then installs them, then upon first connect to the SSH server the Pi
deletes the keys from the service and Pi and is ready to be remotely
used. This is very convoluted for novices but is a proof of concept,
which will be adapted upon.
In long term I would like to try to prevent fingerprinting of the pi on
the network by changing various exposed ports, hostnames, mac addresses
but as it stands with this current script, you can go from still in box
products to fully accessible ssh server in 25-30 minutes with some very
basic linux knowledge with some cleaning up the knowledge requirement
could be taken down a few notches and the process probably sped up a
little. The gitrepo of a working prototype (albeit not always working)
is available here:
https://github.com/ixt/ToBury
The project will continue to be worked on as a modular system, once the
base install is done, the user will be able to install services like
owncloud, a better website, homeassistant etc that can probably be
hardened with such a setup script. And of course this would tie really
well in with ToEat once that is more complete.
I envision if these ideas are adopted by TailsOS the user could, on a
clean install could select an advanced option to choose a hidden service
to pull their payload from (that would be running Tails Server or ToBury
or whatever it is) and an auto discover for luks encrypted pen drives
that could look once decrypted (upon prompt and passphrase) would load
in the payload.
The final point I'd like to bring up is that, over these past months I
have been subscribed to the support lists, and to the r/tails subreddit
where the latter I have been responding to many people. It seems that
those with booting issues who also make it to grub are getting many of
the same issues, would it be a bad idea to have some troubleshooting
documentation that could be added into GRUB itself in order to help
those who don't have access or perhaps can't risk asking/looking up
these questions online? I'm not too familiar with how GRUB works
internally so not sure how feasible this is, but it does bare a mention
and some thinking.
Thank you for reading this and I look forward to any responses I receive
Yours,
Orange
