
Please Stop Writing Secure Messaging Tools - zurn
http://dymaxion.org/essays/pleasestop.html
======
glogla
There isn't a working secure messaging now.

GPG+email has UX problems meaning BFU's will never use it.

Signal is bound to Google, and Moxie's views on corporate control and calling
getting applications from somewhere else than Google "going back to the old
broken desktop security model" doesn't exactly inspire confidence.

Telegram has broken crypto, doesn't ecrypt by default and the authors being
arrogant about their broken crypto doesn't exactly inspire confidence.

Whatsapp and iMessage are closed source, so they are completely unverifiable.

There isn't secure messaging tool that can be widely used as of now. I know
not many people are good enough with crypto to be able to reliably write one,
but that doesn't mean we should stop trying. Being able to communicate easily
and securely is very very very important and should be part of basic
infrastructure by now.

~~~
gambiting
In my personal opinion: if you want to communicate securely, with a very low
probability of eavesdropping - use voice chat in any of modern games, on any
platform. On both PS4 and X1, voice chat communication has to be
encrypted(it's a compliance requirement), but at the same time there is no
requirement that you have to implement a server relay - so a lot of games
don't bother doing it, and it's a straight up P2P mesh implementation. You
have encrypted, P2P traffic, not stored anywhere, that you can create an
anonymous account to use.

~~~
random778
[http://ethanheilman.tumblr.com/post/133488739430/is-
playstat...](http://ethanheilman.tumblr.com/post/133488739430/is-
playstation-4-network-traffic-especially)

It seems that PS4 encryption is broken.

~~~
gambiting
Yep, but pretty much all games implement their own voip, in addition to system
chat(Party Chat) - and while system chat can be forced to relay through
MS/Sony servers, custom implementations in games do not have this requirement.
They can also use different encryption to the system one.

------
mempko
We need to make secure p2p messaging easy so we can focus on building the
other software.

I am building yet another secure messaging tool called Firestr
([http://firestr.com](http://firestr.com) and
[https://github.com/mempko/firestr](https://github.com/mempko/firestr)).
Except it is designed to be a platform for building all that other software.
Has a built in application editor and application distribution system.

I have already built file transfer, voice chat, white boarding, and game
examples. I want p2p distributed software to be EASIER to write than
client/server.

The execution might not be ideal and it is a very small project, but I hope
the idea catches on and inspires something better.

~~~
Pharaoh2
[https://xkcd.com/927/](https://xkcd.com/927/)

~~~
mempko
Haha, Yes! I hate competition with a passion. For example, who the hell cares
about my p2p protocol? I don't, which is why I will use GNUnet in a future
version. I wrote my own to learn and don't feel the need to compete with much
better works.

------
robin_reala
Cache:
[https://webcache.googleusercontent.com/search?q=cache:dymaxi...](https://webcache.googleusercontent.com/search?q=cache:dymaxion.org%2Fessays%2Fpleasestop.html)

------
mehrdada
The only tool that's free software and doesn't use shady crypto at the moment
seems to be Signal (TextSecure) which is not a great messaging app UI-wise.
Perhaps a couple more do exist as well, but I don't see a plethora of actually
secure tools around. Remember, Telegram and similar crap do not actually count
as secure tools.

Therefore, I disagree. There is still no tool with iMessage-quality UI that
facilitates messaging and has an explicit key exchange step that a journalist
can easily use, so please carry on with writing usable secure
messaging/encryption tools or contributing to the existing one(s?).

~~~
laen
Why isn't there a tool with iMessage-quality UI? I find it hard to understand
why the demand is not being met. Could it be that a core tenet of a secure app
is being open source and open source is less profitable, thus removing
incentive. The article suggests it is because efforts are fragmented, which
ostensibly is true. Maybe a combination of the two? What am I missing?

~~~
mehrdada
This [ _...is less profitable, thus removing incentive_ ] is probably true,
unfortunately. I personally seriously considered this space and actually wrote
a quite complete prototype with this exact goal more than a year ago, but
eventually decided to not move forward with it at the time. One problem is
that it is really hard for an average user to distinguish BS security claims
from proper crypto. An average user would likely consider Snapchat to be more
secure than an E2E app.

~~~
laen
Mulling on this a bit more - the profitability is further impacted from the
inability to mine customer data on a secure app. Anecdotally, when presented
with a free unsecure app vice a paid secure app, average Joe will go with the
free app. Maybe there isn't a true demand like eps mentions

------
tracker1
In the end, I think that something using WebRTC combined with something like
keybase.io to hold public keys as a lookup system could work.

You load app, which connects into DHT network... you search for a contact via
keybase.io lookup, which then does a query to find the given contact, and all
further communication happens over webrtc against the public key of the target
user. Other key sources could exist, as well as other registries, or side-
loading keys via other channels.

It could be distributed, anonymous and secure. The down side is there isn't
much one can do to fight flooding attacks. Also, peer negotiation of "friends"
might get interesting as well.

It wouldn't be too hard to create an initial client using electron, or
similar.

~~~
MichaelGG
WebRTC as in a browser? How do you verify peers? As far as I've seen and
understood, WebRTC's trust model is the same as the webpage's model - you must
trust the page.

And if not in a browser, why WebRTC of all things? It still uses rather ugly
SDP (which, at least in SIP, still suffers from being originally designed as a
multicast protocol for one direction - the offer/answer stuff is poorly
grafted in and doesn't really work like people expect, though in practise
implementors seem to ignore stuff and code it like they think it should work.
SDP is also bad because it's a text-based protocol, and those are almost never
unambiguously parsed even if the spec is technically OK). WebRTC is probably
more secure due to high-quality teams writing browser-facing code, whereas
even 1000-line SIP programs are laughably terrible.

~~~
tracker1
Each client has a key pair, their public key can be published, such as via
keybase.io, you get the public key, and send the message that only the
corresponding private key can handle.

WebRTC is also a protocol, intended for, but not necessarily tethered to a
browser. I think given the distribution level of browsers, it makes sense as a
communication channel. Not that it's the best protocol option, but it's
relatively easy to interface with at a higher level.

~~~
MichaelGG
But inside the browser, how do you actually verify the media path is secured
properly? You end up trusting the server of the webpage you're on, since
that's what negotiates everything. And if you trust the server, then you can
just offload things to the server in the first place, and going P2P doesn't
really matter.

Outside of the browser, sure you can negotiate your own way and tie the media
to an established key.

~~~
fulafel
Is that different from trusting whatever system delivers your desktop/mobile
apps? Download over HTTPS from an reputable app store or web site. Or embark
upon building and verifying it from source, which you can also do in the web
app case.

The only thing that is missing is the ability to verify the download out of
band on desktop. This might be addressed with a link/bookmarklet w subresource
integrity?

With the client side web app there is still more transparency than a server
side app, because in event of compromise the backdoored code must be served to
your browser instead of staying invisible in the backend servers.

The other big advantage from P2P is operational independence, you no longer
need anybody to bankroll the servers and bandwidth.

------
erikb
Totally supporting this. As always in that kind of thread I feel it should be
mentioned though, that easier to use is never, never, never ever more secure.
Yes, less clutch means more secure. But if you ever think you can just start
any computer and do something secure, without checking, configuring and
understanding your environment, then you live in a dream world. Higher
security means having more control of the environment, and that might very
well mean understanding some physical and mathematical boundaries. "just
starting to do X securely" (with X possibly being communicating with someone
else) is impossible.

In fact security gets harder every year, not easier, because our computers get
more complex and harder to understand. If you have a smartphone it's really
hard to even understand the hardware you have, because 90% of that computer is
in a single chip. You can't look inside just like that anymore.

And besides all these technical issues there is also always the human factor.
The most secure tool is only as secure as you interact with people. You can't
improve that with a better GUI or something either.

------
mbrock
I found this post very inspiring.

She's not _really_ saying "don't work on secure messaging apps," but something
more like "let's not focus entirely on secure internet messaging, but also
help nonprofits and other organizations with a diverse variety of secure
collaboration tools."

The list is fantastic.

~~~
mbrock
By the way, here's a project Saitta is involved in, an app for distributed
secure messaging.

[https://briarproject.org/how-it-works.html](https://briarproject.org/how-it-
works.html)

> _Briar is a messaging app designed for activists, journalists, and anyone
> else who needs a safe, easy and robust way to communicate. Unlike
> traditional messaging tools such as email, Twitter or Telegram, Briar doesn
> 't rely on a central server - messages are synchronized directly between the
> users' devices. If the Internet's down, Briar can sync via Bluetooth or Wi-
> Fi, keeping the information flowing in a crisis. If the Internet's up, Briar
> can sync via the Tor network, protecting users and their relationships from
> surveillance._

------
KnightHawk3
Websites down, heres Google's Cache:
[http://webcache.googleusercontent.com/search?q=cache:UvM4KhY...](http://webcache.googleusercontent.com/search?q=cache:UvM4KhYj6BoJ:dymaxion.org/essays/pleasestop.html+&cd=1&hl=en&ct=clnk&gl=au)

------
KnightHawk3
Website seems to be down, heres a mirror:
[http://webcache.googleusercontent.com/search?q=cache:UvM4KhY...](http://webcache.googleusercontent.com/search?q=cache:UvM4KhYj6BoJ:dymaxion.org/essays/pleasestop.html+&cd=1&hl=en&ct=clnk&gl=au)

------
ahalam
Some one needs to pay attention to Bittorrent Bleep
[https://www.bleep.pm/](https://www.bleep.pm/) It is closed source but it
riding on a big P2P betwork.. the Mainline DHT

~~~
IanCal
I'm not filled with confidence when visiting a secure messaging app site that
fires off warnings when visiting the https url.

~~~
XorNot
Of course HTTPS is not at all secure due to that central source of authority
enabling easy large-organization MITM.

~~~
IanCal
If the problem you're solving is bringing E2E encryption to the masses, then
starting with a site that brings up

"Your connection is not private

Attackers might be trying to steal your information"

as the very first thing I see is not really leaping over the first hurdle.

------
willvarfar
So the argument is "please stop writing secure messaging tools that scratch
_your_ itch, and work on UI stuff that this chap wants instead"?

------
jack9
It's not clear why anyone would care, but a basic concept might be that making
umpteen tools throws them all into the bucket of "wasting time on something
that won't exist in a few years" while hindering the products that will.

------
carlchenet
blablabla show me your code

