
Please Stop Writing Secure Messaging Tools (2015) - Jtsummers
https://dymaxion.org/essays/pleasestop.html
======
gumby
The essay I wish she had written would have said, "we don't need more 'secure
messaging systems' \-- we should be making all the following tools secure by
design"

For example, (and whether you love them or hate them) Apple takes this
seriously: your fingerprints don't leave the device and are implemented by a
piece of hardware in such a way that even Apple doesn't have access to them.
Compare that to the Android implementations which have fingerprints in the
filesystem. I'm not intending to hold them up as some paragon, simply showing
that securing information is more than just a messaging issue.

~~~
ndesaulniers
I maintain the Fingerprint stack on Google Nexus/Pixel devices.

> your fingerprints don't leave the device and are implemented by a piece of
> hardware in such a way that even Apple doesn't have access to them.

This is true for Google, too.

> Compare that to the Android implementations which have fingerprints in the
> filesystem.

They're not stored in plaintext. They're encrypted with keys that remain in
hardware. You can never read the keys, only encrypt files with them, from
applications running in a separate physical address space, accessible only
through the hypervisor.

This may not be as elegant as doing matching on the sensor, but keep in mind
we have to play within the constraints of 2 difference vendors (SoC,
Fingerprint Sensor).

Implying that Android is somehow less secure in the case of fingerprint is
disingenuous.

~~~
gumby
First of all, I understand your taking offense (though none was intended)
since this is the thing you work on. I feel the same way about stuff I work
on! Second, I simply used that as a straightforward example, not to say "Apple
good, android bad."

Security is always a risk tradeoff. My house uses special Medeco keys
(modified in violation of the Medeco license as it happens) because what I
want to defend against is copying when I lend out one of my numbered keys. The
house is made of glass so someone could just use a brick to get in. For
someone else this is a dumb tradeoff; for me it is appropriate.

And your message includes an example of such a tradeoff:

>This may not be as elegant as doing matching on the sensor, but keep in mind
we have to play within the constraints of 2 difference vendors (SoC,
Fingerprint Sensor).

>Somehow implying that Android is less somehow less secure in the case of
fingerprint is disingenuous.

The channel between the two separate devices is an attack surface (as is the
opportunity for offline attack on the encrypted data in the filesystem). The
Android team has made the determination that that's an acceptable risk. I
won't argue -- perhaps I agree and perhaps I don't, but it is unambiguously
less secure than the single, all-encompassing approach. To claim so is hardly
disingenuous.

Of course, as with my house, this just changes the class of attack. On either
platforms you can consider attacking whatever authentication module _talks_ to
the TEE. Both systems use other mechanisms for that.

Finally, in the Android case a vendor is free to do what they want, especially
if they don't care about access to branding, google services etc. Google
branded devices have a more important brand to defend than, say, Asus (not to
pick on Asus), much less, say, DJI's drones, for which the Android branding is
utterly irrelevant (conceivably that could rebound on Google though personally
I doubt it would even happen. The same obviously can't be said about iOS :-)

~~~
ndesaulniers
Those are all fair points, I don't disagree. Maybe disingenuous was the wrong
word?

~~~
gumby
It is completely the wrong word since it describes me to be, at best,
deceptive. If you don't disagree you can hardly describe claim I was lying!

~~~
matt4077
I think they were trying to deescalate, and your reply is more aggressive than
necessary.

FWIW, "disingenuous" carries the connotation of intentional deception, i. e.
making an argument in bad faith, because one knows that it's wrong.

In this case, I can understand where the defence of Android's implementation
is coming from: the original description amounted to "plain text in the
filesystem, but the name ends in .mp3 so nobody will find it", whereas the
reality seems to be a slightly less elegant solution that can probably be
subverted by a dedicated nation-state, but is unlikely to ever make a
difference in most people's lives.

------
pudo
That list is pure genius. I'm working with reporters mostly in non-OECD
countries, 80% of the stuff on that list are real, largely unmet needs. Signal
isn't perfect, but it works fine, thanks.

A special place in hell should also be reserved for those in the tech world
that mix up security (a real and critical need that people have) and their
software politics. If you don't like Microsoft, Google, Adobe, "the Cloud", or
smart phones, that's fine. There are plenty of reasons. But don't short
circuit security assessments in the interest of promoting technology you find
politically superior.

~~~
yamba789
It's a helpful list, but I don't actually agree... Reporting isn't a high-tech
job, and most of the suggestions to me seemed unnecessary.

Document-sharing with edits being tracked is the big one, though (like the
article raised).

Also, Signal being tied to a phone number is a nightmare.

~~~
pudo
> Reporting isn't a high-tech job

I disagree. Sitting on a phone and sweet-talking sources isn't high-tech, and
neither is bundling up five tweets to make a clickbait.

But as soon as you're talking about doing public records research, tracking
the activities and ownership of a multi-national company, working in a team
with people from 30 countries on a single story, try to manage your
confidential evidence across five years, it becomes quite technical.

------
zeta0134
Looks like this site is being hugged to death, Google's cache works though:

[https://webcache.googleusercontent.com/search?q=cache:pwT4ik...](https://webcache.googleusercontent.com/search?q=cache:pwT4ikbpSd4J:https://dymaxion.org/essays/pleasestop.html+&cd=1&hl=en&ct=clnk&gl=us)

~~~
deckar01
Archive.org cache:
[https://web.archive.org/web/20161019151428/https://dymaxion....](https://web.archive.org/web/20161019151428/https://dymaxion.org/essays/pleasestop.html)

~~~
pdimitar
This link is more recent:
[https://web.archive.org/web/20171015070908/https://dymaxion....](https://web.archive.org/web/20171015070908/https://dymaxion.org/essays/pleasestop.html)

------
pingiun
I think matrix forms a nice basis for a secure chat platform. Only the apps
are not really all that good. The desktop apps are electron based and the
android app is just not up to par with telegram or WhatsApp.

~~~
DiThi
In a lot of regards, the "not up to par" part of riot.im or matrix is the lack
of a contact list (or simulated equivalent with same UX). IMHO it's the
usability problem #1, and the reason for our team not to switch yet. The
issue[0] should receive more attention.

[0] [https://github.com/vector-im/riot-
web/issues/4488](https://github.com/vector-im/riot-web/issues/4488)

------
dokument
Bandwidth and local storage considerations are missing from this. All of those
features are great, but if my decentralized application uses all of my
available bandwidth and disk space, then it is not very great.

This is very relevant because decentralized means that all that centralized
storage and bandwidth needs to split up and amplified to account for offline
users.

------
throwa34943way
> Because we have too many other tools we also need.

Yes, but secure messaging is a well understood domain I suppose so it's the
kind of app that is simple(not easy) to write and most tools compete on UX. A
lot of tools on the list at the end have complex domains that are not that
well understood by stock developers, or they might require a lot of R&D or
actually talking to teams that have a problem to solve.

Furthermore it is extremely difficult to market a lot of these tools to
corporations. IM? it's fairly easy.

The situation with secure messaging apps today isn't so different than social
networks in the 2000's. It's a formula and it's easier to raise capital on
that formula at the moment.

~~~
vxNsr
I would think that at least half of the domains mentioned are being used in
some way by developers. So it's entirely possible to dogfood them.

Some examples I know I've used: PMS, Wiki, Calendar, VFM. I'd love a good
group password vault, so far I've come up empty for something open source...

~~~
kcmastrpc
[https://bitwarden.com](https://bitwarden.com)

self-hosted / free / open-source password vault. extensions for every major
browser out there (edge / ff 57)

~~~
djrogers
> extensions for every major browser out there (edge / ff 57)

Can't really say that if the stock browser on macOS isn't supported...

~~~
kcmastrpc
you're right.
[https://github.com/bitwarden/browser/issues/17](https://github.com/bitwarden/browser/issues/17)

------
t0mbstone
Just use Keybase!

~~~
subway
I can't help but get an embrace, extend, extinguish vibe from keybase. It was
a nifty key discovery service initially, but more and more feels like a closed
platform, and gives me a sense of deja vu akin to XMPP on GTalk.

~~~
dasil003
I get what you're saying, but realistically PGP will never cross the chasm, so
there was not really a viable business there. I like that they have integrated
it, but are moving in a direction that lowers the barrier to entry. There are
risks to be sure, but it feels like the most promising of the secure messaging
platforms.

------
egberts
Sounds like it would have benefited the large state actors to have less
secured messaging tools around...

------
pdimitar
archive.org mirror:

[https://web.archive.org/web/20171015070908/https://dymaxion....](https://web.archive.org/web/20171015070908/https://dymaxion.org/essays/pleasestop.html)

------
phyzome
I love that list of needed tools!

~~~
vfranco
I am hoping for recommendations based on that list to show up

