RomeoPapa:
> Hi there,
Hi, sorry for taking so long to get back to you.
> I'm part of the SilentKeys team and we want to introduce our project
> that will leverage a Tails fork. We talked about it briefly with one of
> you at Numa about a year ago when we attended a UX session. We're based
> in Paris and have been using Tails since at least 0.16. The first SK
> prototype ran Liberte before moving over to Tails 0.21.
>
> We are humbled by and very respectful of the philosophy, the ethics, the
> professionalism, the technicality and the transparency of the Tails
> project. It has come a long way, gaining both technical robustness,
> public exposure and made a lot of crucial user-centered progress.
Thanks for the nice words.
> We know the balance between commercial projects and FLOSS can be both
> tricky to attain and criticized but we won't let that prevent us from
> trying.
It's amazing that you're trying and I really much appreciate you getting
in touch with us this way.
> The homepage is at: https://getsilentkeys.com/ or
> http://hvaudvqty72cxnbo.onion/
>
> If you want to read more about the background of the story here's an
> informal blogpost:
>
> https://preev.io/blog/2016/04/sk-story/
>
> The schematics/files for building a SilentKeys “module” and the source
> code for building the fork (SatyaOS) will both be released around launch
> time.
I bet that many of us will be very interested in looking at your code :)
> We are aware there are no silver bullets in infosec, and that for most
> people reading this SK probably doesn't seem like much. We'll just ask
> you remember that you're uber-geeks, part of the digital 1%.
>
> We're building this for non-technical people (techno-phobic folks, very
> busy pros, grandmas, privacy-inclined and snooping-conscious people that
> still will never come to cryptoparties etc). Folks who just want to
> browse, bank, shop, research or talk in relative (yet way higher than
> WiniOSXid) safety, without having to worry about whether or not there is
> malware snooping on them or if they're leaving crumbs all over.
>
> We believe our technical choices (including using Tails), a familiar yet
> sleek hardware format as well as physical separation and hardware
> “read-only-ness” are novel mainstream propositions and fit our bill.
> You're welcome to disagree of course, and by coming out like this we
> really wish to engage in order to get constructive feedback.
>
> We will post checksums of our releases for those who know how to verify
> and more importantly we will produce bootable ISOs that will certify the
> content of the system and the recovery memories for those who don't know
> how to.
What will the installation process look like concretely? For Tails it's
still a very big pain point but unfortunately we didn't find any easy
way forward...
> We sincerely believe there can be some form of synergy between our
> project and the Tails project. Our visibility will probably increase the
> usercount of Tails as we won't hide SilentKey's debt to the project to
> our users nor in our communications. We will merely join all the other
> open projects such as Tails that help bring *nix, Tor, encryption and
> privacy issues in the spotlight. And unlike iCloak (where's the code??)
> or Anonabox (Tor ain't no wildcard), we're committed to integrity and
> transparency.
That's very much appreciated!
I don't know if you've read our recent statement on creating Tails
derivatives:
http://tails.boum.org/contribute/derivatives
Still, I don't think it can apply to you as you're probably changing too
many things to be able to apply them *on top of* Tails.
> If things go well we will help Tails get more man-hours and code : for
> instance we really want to have AppArmor enabled and properly configured
> as soon as possible and for it to work on our system it has to first
> work on Tails so we'll be joining the effort, as we already have before.
> Same goes for your UX roadmap.
We already have AppArmor in Tails, see:
https://tails.boum.org/contribute/design/application_isolation/
We inherit the work done upstream in Debian, so if maybe you can
contribute to either the profiles in Tails or Debian.
Regarding the UX roadmap, another big challenge pending is to make it
easier to configure and start Tor (and handle persistent Tor state,
captive portals, time sync, etc.). We started something but didn't get
to concrete plans yet:
https://tails.boum.org/blueprint/network_connection/
> All development work we will do in-house will be freely available on our
> Github for all to review, use, improve, you know the deal. Let's talk.
> We're now working hard on the crowdfunding campaign, hoping to raise
> enough to build the first series and move into beta. We won't stop you
> from spreading the word if you like our initiative!
Sure, tell us when the crowdfunding campaign starts, and also if you
have any development channel we could follow.
> We'd be happy to answer any questions you have. You can find me,
> RomeoPapa on OFTC. I've committed to stick around in #tails and you're
> welcome in #silentkeys anytime.
>
> Thanks!
>
> Just a few more details:
>
> The system's memory is physically read-only by default, mostly as a
> last-resort safety against users mistakes. We're talking about the type
> of users that when they see a web popup telling them to download a "free
> antivirus" because "an infection has been detected" will ignore the
> warnings that the system might be showing them and actually follow the
> popup's instructions and are then left wondering how a virus got into
> their system. Also this last line of defense can be useful against
> attacks or malware that target 0-day vulnerabilities with privilege
> escalation in one of the bundled applications: it's going to be hard for
> malware to install itself on a write-protected system disk*.
>
> When the system has to be upgraded, the wizard process will ask for the
> user to activate the 'special' write-enable switch, that will physically
> enable writing capabilities on the system memory. Once the system has
> been upgraded, the wizard asks for the user to deactivate the
> write-enable switch. We perform checks at boot-time and during run-time
> to see if the user hasn't activated the write-enable switch by mistake
> and warn him of the fact**.
In Tails we have automatic (incremental) upgrades but these only work
for some time, after which people have to do a manual upgrade.
See #7499.
How do you deal with upgrades on the long-run?
> * Of course, such type of malware with privilege escalation could come
> and read/modify the content of the SD card and could read and modify the
> host's hard-disk or could install itself in the bios. But then again do
> you know any personal computing solution able to withstand such attacks?
>
> ** We can indeed imagine a future where specialised attacks in the form
> of web popups might ask for users to activate the write-mode switch. We
> hope that by then that the user might be more conscious of physically
> activating a switch than just discarding an UAC prompt.
