Live data from Hacker News

Keybase Exploding Messages

keybase.io

141–150 of 155 posts

Re: Keybase Exploding Messages

#141
post #53

Earlier quoted context omitted.

The most important purpose of these exploding message capabilities is destruction of data that doesn’t need to be archived. The primary threat is compromise of a device. Keybase allows you to revoke keys but that assumes you are aware that the device has been compromised. Which is already too late for sensitive messages. The average user doesn’t understand data persistence, or secure destruction of data. Manafort is…

As a user of messaging services, I nearly never want to delete a message. I want to be able to use my digital memory extension (phone) to store messages so that I can easily recall my conversations. Rarely do I want to delete a message. In fact, I would only want to delete it if it's sensitive: I rarely message such sensitive things. Most people fall into this camp. It's rare for someone to never want any message to…

I have never searched my message text history with the exception of trying to find images sent to me. Never content. Most companies I’ve worked at have a similar policy of not archiving text messages from internal chat. No reason to keep content, minimizing the amount of data you archive is a core element of security and risk mitigation for a number of reasons. Plenty of large organizations don’t archive employees Lync/internal chat messages for similar reasons. And from a threat perspective you don’t know ahead of time what information an attacker will find useful.

Re: Keybase Exploding Messages

#142

Earlier quoted context omitted.

I deliberately don't pay for Slack because of this. The 10,000 message limit is perfect for "enough memory to be useful, not enough to be dangerous". I'd love to see it as a feature in other messaging apps (i.e. "permanently erase all messages over 6 months old")

Does Slack actually do that, though? Or just soft-deletes the older messages, hiding them from the UI? (I don't think they make a statement either way)

My understanding is that it just hides them from the UI; if you upgrade your plan, you get access to all your old messages and files that were previously "gone".

Re: Keybase Exploding Messages

#143

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 Keyba…

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

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.

Re: Keybase Exploding Messages

#144

Earlier quoted context omitted.

I love this! And I love the bomb gif. I still miss your original logo, but have come to like the little girl. Anyway, maybe it's just me, but I never communicate anything to anyone that would be hugely problematic if published. That is, for that persona. Which is carefully compartmentalized from other personas. So Mirimir has rather restrictive limits. My meatspace identity has even more restrictive limits. But some…

The assumption being that the personae are not linkable to each other. Is that a realistic assumption?

Well, it has been for me, so far. But then, it's my main hobby these days, and I take extreme care.

If you're interested, I explore that and related issues in one of my series on the IVPN website.[0] There's also an old guide on nesting VPNs and Tor with VMs.[1] And a tribute to Kevin Mitnick, featuring onion SSH hosts for chaining.[2]

The tl;dr is that compartmentalization is the key. At all levels. At physical levels such as hosts and VMs, LANs and vLANs, and uplinks and proxy chains. And at behavioral levels, such as interests, forums and social media, projects, and language and writing style.

Mirimir is my only main persona that writes about privacy issues. He has temporarily had a few secondary personas for particular projects, just for casual deniability. But none of my other personas have written at length in English.

0) https://www.ivpn.net/privacy-guides/online-privacy-through-o...

1) https://www.ivpn.net/privacy-guides/advanced-privacy-and-ano...

2) https://www.ivpn.net/privacy-guides/onion-ssh-hosts-for-logi...

Re: Keybase Exploding Messages

#145

Earlier quoted context omitted.

Does Slack actually do that, though? Or just soft-deletes the older messages, hiding them from the UI? (I don't think they make a statement either way)

My understanding is that it just hides them from the UI; if you upgrade your plan, you get access to all your old messages and files that were previously "gone".

Yes this is correct. In fact even without a paid subscription you can access all files that have been added to a Slack through the web UI (myslack.slack.com/files). You can't see the related messages, but all the files (images, snippets, etc) are available as one big list.

Re: Keybase Exploding Messages

#146

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 se…

I agree that a feature doesn't have to be 100% foolproof to be beneficial. I also agree that leaving sensitive things lying around "by default" is a poor approach to security, and think that software should facilitate automated cleanup. However, I fundamentally object to the subversion of my will by my device or any program running on it. In my opinion, DRM in any form is not a solution - it in inherently evil.

I wouldn't mind messages that were flagged for automatic deletion after some time interval, if I were also provided with controls for when and when not to honor such requests. But currently Signal, SnapChat, Keybase, and others don't provide me with such a choice - they do what the sender requested, regardless of whether or not I approve.

It goes without saying that providing such an easily accessible option would almost certainly result in it being used at times in socially inappropriate or distasteful ways. But consider, do you really want to give up control of how your device behaves in an attempt to prevent others from behaving poorly? Perhaps applications should focus on providing practical security (ie facilitating, not forcing, automated removal), and leave the social aspects up to the humans to sort out.

Re: Keybase Exploding Messages

#147

Earlier quoted context omitted.

I would be hesitant to trust a controversial screenshot of text because I know that can be faked so easily. A lot of people don't have that awareness, though.

Another feature of Keybase's exploding messages is that when they expire, the text is replaced by the md5sum of the message. So a faked screenshot can (potentially; I haven't verified this) be proven to be faked by appealing to the md5sum in its place, crucially, without needing to reveal the contents of the original message.

Sorry, I was wrong. I misread in a chat thread on KB something about md5s. Can't find it now because no searching in KB (yet!).

Exploded messages are just replaced with an image of what people are calling 'ashes'.

Further conversation on KB about this points out that hashing the message would compromise the secrecy. I still think it would be a neat feature.

Re: Keybase Exploding Messages

#148
post #80

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…

A comment in your [1] link points at https://github.com/keybase/keybase-issues/issues/1952#issuec... which explains why device names are immutable.

> The reason of this restriction is pretty important: we want people to be able to think of devices by name - say, when seeing them in a list, or when talking about them - and never have to think about key fingerprints or id's. The only way to achieve this safely is to make a devicename map immutable and global, using the sig chain. Otherwise there are endless caveats and visual explanations needed showing the evolution of a device name over time.

> Consider: if an intruder steals one or more of your keys and starts doing crap to your sig chain, they still can't change the definition of "iphone6s-white". It is set in stone, which is crucial to maintain the abstraction that "iphone6s-white" is a certain key.

I agree that it sucks to have your device name become permanently unusable; I've hit this myself a few times, and it's mildly annoying to find that I have to pick a new device name in Keybase even though my local name for the device hasn't changed. But removing this restriction opens up a security vulnerability.

Re: Keybase Exploding Messages

#149

Earlier quoted context omitted.

My understanding is that it just hides them from the UI; if you upgrade your plan, you get access to all your old messages and files that were previously "gone".

Yes this is correct. In fact even without a paid subscription you can access all files that have been added to a Slack through the web UI (myslack.slack.com/files). You can't see the related messages, but all the files (images, snippets, etc) are available as one big list.

I did not know this. Useful, thanks.

Re: Keybase Exploding Messages

#150

Earlier quoted context omitted.

My issue is with the way they are marketed. I would be cool with just a “don’t retain” flag that does just that. But making a big deal about “exploding” is dangerously incorrect that many users will make incorrect assumptions. I’m not worried about screenshots, I’m worried about my plugin that archvives all text inbound to me that then requires me to respond to subpeona, etc. From a security standpoint, this feature…

I don’t see your point. If you archive all inbound text, this feature is clearly not for you. This is like saying a door lock isn’t useful for anyone because you keep your window open.

The people I chat with do not know that I archive (nor should the) and will have an inaccurate and misleading expectation of behavior.

To use your door analogy, it’s like telling someone that a door lock keeps people out when there’s an invisible teleported that also gets installed with the door lock.

It’s a hard analogy to follow because me retaining information you sent me is different than me breaking into your house. If you send me info, it’s mine. The weird mental model is that you still control what you give to me.

Post reply on HN