
Keybase Exploding Messages - aston
https://keybase.io/blog/keybase-exploding-messages
======
malgorithms
Author here. I'm seeing the same comment in 4 different places on here, worded
with various amounts of hostility. I now wish I had addressed this in the FAQ
on the post.

There's the suggestion that an exploding feature is worthless, given your
partner can just take a screenshot or video of what you sent.

This suggestion is missing (1) that your relationship with a partner is
disproportionately okay at the time you sent something (i.e., you trust them
THEN) and (2) there's a whole different class of adversary who compromises
your or your partners' devices in the future.

SnapChat, as far as I know, has none of the cryptographic implementation of
Keybase. And yet it has likely protected hundreds of thousands of kids from
severe bullying. Consider the teen girl who sends the goofy sexy pic to her
boyfriend. Before the advent of exploding messages, he might've iMessaged or
emailed that to a friend, just one friend, his best friend, out of pride. And
that friend sent it to a few more, and so on. Not out of malice, but suddenly
the whole school has seen her pic of god knows what and she literally wants to
die. But with Snapchat, taking a screenshot is knowingly violating a social
agreement. It's also violating the trust of his current girlfriend - everyone
knows it's not okay to screenshot that shit. And the number of people who
would do that is much tinier. Second, consider the far worse scenario: she
dumps him a month later and until then he has been NiceGuy. But then he
becomes r/niceguy, the guy who will look through the old pictures and spread
them around.

Finally, let's not forget that your device can be compromised by loss, theft,
or hackers, at any time. Exploding messages are gone when that happens.

People can be tricked, compelled, coerced, blackmailed, and hacked. Or just
turn evil. All in the _future._ Which is what a timed message protects
against. This is why Keybase is doing this. Paired with encryption it's quite
powerful.

~~~
geofft
> _SnapChat, as far as I know, has none of the cryptographic implementation of
> Keybase. And yet it has likely protected hundreds of thousands of kids from
> severe bullying._

Is this true? (Asking with no implication of criticism or being a leading
question - I just genuinely don't know the answer)

I can believe both that these teens were going to sext each other anyway and
Snapchat is keeping them safer, or that they _weren 't_ going to and Snapchat
has convinced them that it can be done more safely than it can actually be
done.

Has anyone done studies on this? (Is it even possible to do studies? I suppose
you'd either need information from Snapchat itself on how often they detect
screenshots, or from high schools on bullying cases over time and whether
Snapchat is involved + hope that bullying cases that get escalated to adults
at high schools is a meaningful proxy for actual bullying.)

I'm inclined to buy your argument that because of the implementation making
stored pictures not the default, and the social pressure not to take
screenshots, _probably_ Snapchat's disappearing messages are better than
iMessage. But this seems like the sort of thing that's dangerous enough (in
either direction! if the technology works and we refuse to deploy it, that's
bad too) that hard data would be useful.

~~~
richdougherty
There's a theory about this:
[https://en.wikipedia.org/wiki/Risk_compensation](https://en.wikipedia.org/wiki/Risk_compensation)

> "Risk compensation is a theory which suggests that people typically adjust
> their behavior in response to the perceived level of risk, becoming more
> careful where they sense greater risk and less careful if they feel more
> protected. Although usually small in comparison to the fundamental benefits
> of safety interventions, it may result in a lower net benefit than
> expected."

There's a book too, with a special emphasis on on financial crises.
[https://www.theguardian.com/books/2015/oct/12/foolproof-
greg...](https://www.theguardian.com/books/2015/oct/12/foolproof-greg-ip-
review-biggest-risk-is-safety)

> "In the run-up to the crash, consumers and even policymakers had come to
> believe that smart regulators and forward-thinking bankers had made the
> world of money a much safer place.

> "The fundamental insight of Ip’s new book, Foolproof, is that this very
> belief was a key factor in the lead up to the crash. When people believe
> they are safe, they take more risks – they drive faster, in motoring terms –
> and “speed makes everything worse”. Or as the economist Hyman Minsky, whose
> work Ip revisits, put it: “Stability is destabilising.”

There are applications in our field too:

\- safety features for users might make them behave less safely (e.g.
exploding messages)

\- better reliability of systems might lead us to put more trust in them,
leading to even bigger outages when they occur (e.g. centralising trust in
cloud providers)

It's interesting to see things like Chaos Engineering
([https://principlesofchaos.org/](https://principlesofchaos.org/)) introducing
intentional "danger" into a system in order to improve system-wide stability.
Of course, maybe Chaos Engineering will give us more trust in our systems
which may lead us to take even bigger risks...

~~~
geofft
Yup, that's basically what I'm getting at, thanks for the links!

So, I'm okay with risk compensation if people are _net_ doing better. I don't
think that "if even one person is hurt by this, that's too much" is a
meaningful basis for decisions, especially when there's a risk that even one
person will be hurt by _not_ doing the thing. So at the risk of reducing
people to numbers, if, say, 100 teenagers send sexts when they otherwise
wouldn't have and get screenshotted, but 1,000 teenagers send sexts when they
otherwise _would_ have sent them to a non-disappearing-by-default client, and
now their photos _don 't_ get copied because of social pressure / high-but-
not-impossible technical barriers, that still seems like a clear win.

That's the sort of data that I think would be very interesting to inform good
engineering decisions, and also pretty impossible to get.

------
456hdsaq234g
I used to be against this style of 'DRM' \-- either analog hole (screenshot or
physical camera) or client subversion (client logs all messages out of band
forever); but I think I misunderstood the use case. This is about changing
behaviours to be more ephemeral; An expectation that your messages are not
there forever. In a world of "unlock your phone or arrest" these features are
very important. Thanks for rolling this out KB

------
loteck
Nice, succinct response in the FAQ to those who don't care about privacy:

 _" I have nothing to hide"

Because no one is trying to hurt you_

~~~
lvs
... currently.

~~~
sulam
... to your knowledge.

------
e1ven
As I understand, Keybase chat is open-source?
([https://github.com/keybase/client](https://github.com/keybase/client))

I don't have time to read through the code right now, but I'd love to hear how
they implemented exploding messages with untrustworthy clients.

I've thought about it a few times before, and it seems one of the few places
that closed software has an advantage - You can't easily force third-party
clients to delete messages.

If they've solved that, I'm really interested to learn how it works!!

~~~
ohazi
It is impossible to implement this feature "safely" even with trusted clients
-- worst case I take a screenshot or even a photograph of the device
displaying the message before it explodes.

If you don't trust the person at the other end, this is never going to work.
It's more useful for "we both agree that we don't want a paper trail" kind of
thing.

~~~
ggg9990
A dead simple way to thwart the “screenshot” attack is to release a tool for
accurately falsifying a screenshot. I’ve never seen this employed in practice
though.

~~~
tedunangst
How is any bitmap editor not such a tool?

~~~
lozaning
I think they're talking more along the lines of those online meme editors. Yea
i could download the lion king and clip the frame with simba and then pull it
into photo shop and then add text and then upload it to imgur. Or I could go
one of those online meme editors in click the photo and enter my text and then
get a link to the meme I made.

The whole point is to totally lower the bar for anyone to make a passable
copy, thus removing all confidence that any screen shot is genuine.

------
eridius
If you haven't done so already, try clicking on any of the text of the blog
post.

~~~
AlphaWeaver
Nice touch.

------
throwaway3189
You might be surprised, but for some people this feature can be life or death.
My team has been actually waiting for Keybase to have this. We work in
countries where some of us are regularly taken aside by the local police or
armed forces and our phones are being checked to see if we have anything
against the current government. We have to constantly make sure our
communication has no traces. We'll be moving to Keybase very soon. Thank you
for this!

~~~
prepend
Why don’t you just use a client that deletes messages? Why would you wait for
keybase to implement this?

~~~
throwaway3189
We've been waiting for Keybase, it doesn't mean we've been waiting with no
solution meanwhile. We want to use Keybase because many of its other features.

------
mnutt
As a security layperson my initial reaction was "how can cryptography help
with expiring messages, once it's decrypted it's decrypted, that doesn't sound
right", but I'm curious if I'm understanding correctly that this is actually
two separate features: 1) clients voluntarily respecting "please delete this
message at X time" and 2) forward secrecy. And Keybase has tied them together
for UX reasons since people tend to not have an intuitive understanding of
when they might want to use forward secrecy, but they always want it in the
case of exploding messages.

~~~
askmike
This is not functionality meant to make sure the other party will not have
access to the massage after X time anymore, it's just convenience opsec: If
you don't want someone to know X after some time, you should never tell him in
the first place (he doesn't need to hijack the keybase client, he can simply
"remember" the message). Instead this makes it easy to limit paper trace using
a nice UX.

------
gepeto42
Of course this is not to address the case where the recipient would take a
screenshot. I still find disappearing messages useful to reduce attack surface
if say, the phone gets taken away and unlocked by someone else, or a backup of
it is found and restored on something else, or if the phone gets compromised
at some point at least not all previous messages are exposed, etc. A useful
feature, not meant to address scenarios or malicious recipients or previous
compromised devices.

------
mholt
I had to stop using Keybase after this issue [1] cropped up: when you re-
install your OS, you lose access to the "device" and have to provision a new
one, even though the machine is the same, and even in possession of an
uncompromised private key.

Apparently this happens a lot [2-7... probably more]. Unfortunately, this
renders Keybase unusable for me because, even though I still have my private
key, I cannot access my laptop's Keybase when I install it.

[1]:
[https://github.com/keybase/client/issues/3460#issuecomment-2...](https://github.com/keybase/client/issues/3460#issuecomment-278486140)

[2]:
[https://github.com/keybase/client/issues/3559](https://github.com/keybase/client/issues/3559)

[3]: [https://github.com/keybase/keybase-
issues/issues/1952](https://github.com/keybase/keybase-issues/issues/1952)

[4]: [https://github.com/keybase/keybase-
issues/issues/1985](https://github.com/keybase/keybase-issues/issues/1985)

[5]:
[https://github.com/keybase/client/issues/4260](https://github.com/keybase/client/issues/4260)

[6]:
[https://github.com/keybase/client/issues/2357](https://github.com/keybase/client/issues/2357)

[7]:
[https://github.com/keybase/client/issues/2675](https://github.com/keybase/client/issues/2675)

~~~
nebulous1
I'm not entirely sure what your issue is here. Why not reprovision (either
with a different provisioned device or your paper key) and give it a new name?

~~~
mholt
Because it's the same device as before. I only have one name for it.

~~~
nebulous1
Just call it device2?

~~~
mholt
That makes it impossible to recover my original device.

~~~
nebulous1
You don't need to reuse the original device name, just append a number to it.
Think of it as device incarnation 2.

------
kolbe
> corporate messages

In this day and age, I do not advise this. Check with your company's
compliance officer or corporate council before doing anything that is designed
to remove evidence of communication.

------
SamuelAdams
Consider this:

    
    
      I send an exploding message, set for 1 day, to Bob.
    
      Bob checks his chat a week from now.
    
      Does Bob get the message? Or has it already exploded?
    

I guess I'm asking when the actual explosion timer starts - when the message
is sent, or when it is read? For group messages, do all parties need to read
it before the timer starts?

~~~
ohazi
From the FAQ:

Does the timer begin when the message is sent or received?

Sent.

This seems like the only sensible answer for group chats. And we can't have a
different answer for 1-on-1 chats and group chats. That would confuse people.
Not the kind of person who reads an FAQ such as yourself, of course.

So our answer is simple: you set a timer and the message is gone after that
time.

~~~
24gttghh
>And we can't have a different answer for 1-on-1 chats and group chats.

What might be the reasoning here that Keybase won't do it yet Signal messenger
does start the timer on the "receive" end?

~~~
wazanator
It narrows the attack window. It's not hard to imagine a scenario where
something happens to the receiver and as the sender you didn't realize this
until you sent a few messages but the third party who got the receiver won't
be able to access the device for some time. Hopefully by the time they get in
they have self destroyed.

~~~
24gttghh
A valid point! Thanks for postulating!

------
nebulous1
This is like snapchat, they're offering something that they can't actually
guarantee. Of course keybase users are going to be generally more
knowledgeable than snapchat users and most will understand the limitations.

~~~
21
It's still better to delete the message than to leave it there "because you
can't guarantee it 100% either way". Defense in depth.

~~~
Someone1234
I quote this far too much on security but "Perfect is the enemy of good."
Meaning, people often dismiss improvements because they're technically
imperfect.

And it isn't just random forum discussions, major technologies like secure
DNS, secure email, etc were held back years because nobody could agree on
compromises needed to make improvements.

------
Sir_Cmpwn
This very article shows you the problem with "features" like this.

You see that video demonstrating the feature? Notice how you can read the
content of the message which was supposedly deleted?

~~~
wazanator
If you don't trust the receiver you should not be sending them anything
sensitive to begin with.

This feature just eliminates the messages in case something happens to the
recipent or their device if either become compromised.

Let's say I work IT and user Bob forgot their password again and needs a
temporary reset. I can message him his temporary password that expires in 3
minutes so that they can login and set a new one.

~~~
yarrel
I trust the receiver.

I don't trust future bad actors who get hold of the device, including the
receiver should they turn.

------
amelius
I want _all_ my data on the internet to explode after N days.

I keep asking for this. Google, Facebook, where is that feature?

------
tomp
click on some text in the article, it "explodes" :)

~~~
leddt
Did you see the hidden message? I'm not sure what it means. (Treasure at the
root of esabyeK)

~~~
mrburton
[https://keybase.io/esabyeK](https://keybase.io/esabyeK) which is keybase
backwards

------
mherdeg
Can someone explain the FAQ item around "My team uses Telegram and I'm scared
shitless."? I musta missed the joke

------
ejholmes
How does this differ from the existing "Message deletion/retention" feature
that was present before this? Did the existing feature delete messages, but
not keys? Is the old feature and the new feature combined, or are they still
separate?

------
cascom
anyone care to expand on the practical applications/implications/threat model
where this makes sense?

~~~
arkadiyt
It's for when you trust someone but don't want to risk either your or their
device being compromised in the future. For instance:

\- if your or their phone gets taken at a border crossing

\- if your or their phone gets taken by the FBI (which is how they recovered
encrypted WhatsApp/Signal chats from Michael Cohen's phone)

\- etc

~~~
ProblemFactory
Or in a much simpler and common case: you trust someone right now to run a
non-modified client and not to take screenshots, for example based on a
corporate policy.

Months later the relationship turns sour, and they are fired or denied a
promotion. They can't _then_ go through the archives any more to take the
screenshots.

------
yellowsir
now that their is a exploding feature, can i finally explode this annoying
notification about not providing my full name and description.

------
kough
Heard about this last week from a friend on the keybase team, happy to see it
launch on time :) congrats!

------
shruubi
Seriously, do we need a stupid animation and a silly-looking "ka-boom" image?
It just comes across as trying too hard to be cute and ends up looking
childish and stupid.

~~~
tmalsburg2
Metaphors like this help people understand what's happening. If the message
just vanishes that could be for any number of reasons. But with this animation
it's clear that the message is being erased. Keep in kind not everyone is a
hackernews-reading computer expert.

~~~
zkascak
Though I am not personally a fan of cute stuff like that, if it helps in
making secure messaging usable for everyone from IT experts to their
grandmothers who have never touched a computer I am all for it.

