Concerns about usability and retaining old messages

[burdges]

We should discuss how retaining and archiving old messages works.

At 31c3, Dan Bernstein (djb) suggested that Pond should :

• Allow more variations on retained status (2 days after reading, 1 week, 1 month, permanent)
• Allow message senders to specify the default retained status for a message, although recipients could change that setting naturally.
• Allow users to sort retained message somehow, ala folders, tags, etc. for email, not sure if senders could ever specify this or if intelligent defaults might apply.
• Allow users to search for a given string their inbox, outbox, folders, tags, etc.

Implicit in this is imho the ability to backup Pond messages into external archive files that're encrypted as carefully as the state-file but ideally remain viable even if the main state-file is compromised, corrupted, etc.

I haven't thought about how one should archive messages by topic, maybe some topic tags like gmail. I'd envision initially dong at least some archiving inside the main state-file, but periodically exporting that archive. As a default, export operations would be automated but timed using a chopped off Poisson distribution, which might range between a week and two months.

[burdges]

There is a potentially related topic : Should we provide any form of deniable encryption for either the archive files or Pond itself? At present, I feel the answer is no due to the complexity involved and relative rarity of rubber-hose cryptanalysis compared to "collect it all" sniffing. If one were interested in this, then one might design a more general framework for integrating deniable encryption into protocols like email, xmpp, etc. and make pond the best case scenario.

[gmaxwell]

A related feature I had in a little private chat system in the past was logs that could only be read with the aid of the peer-- when you wanted to access the logs your client would go nag the counter-party for help decrypting, and it would prompt that user for permission; and they could choose to not do so if they thought their peer might have been compromised.

Pond's non-realtimeness might make this more cumbersome, I'm unsure. But "Oh I can recover this message with the far end's help" would potentially diminish pressure users might feel to crank up their retention durations; while the both user threshold would make longer lifetimes for recoverable messages less bad.

[burdges]

Why? Recipiants could always violate that behavior, cut & paste, etc. We should avoid offering any feature that offers a false sense of security.

Worse, any implentation would afaik violate deniability. In other words, you could prove a message senders identity byond any doubt! Axolotl, Pond delivery system, etc. were all designed to prevent creating such proofs! I'd avoid any system that offers that feature unless I looked very carefully first.

[gmaxwell]

@burdges Sure, users can always bypass, thats the same on any retention policy points. Retention policy is there to protect against future compromise not against a user that was bad to begin with.

It can be done without any cryptographic loss of deniability--- but perhaps a further reduction of 'conventional' deniability (e.g. "plausibility" to a non-technical witness) in the same way opening the pond interface and seeing names in the inbox does.

[burdges]

Isn't there a cryptographic loss of deniabiltiy merely from the fact that the sender's computer can contribut information that decrypts the message? Yes, our adversry must sieze both computers, or spy on one, but that's still a cryptographic loss of deniabiltiy.

[gmaxwell]

I don't think that its necessarily so, e.g. say the stored message is computer1.data xor computer2.data. (e.g. split by xoring with a random stream and storing the stream on one system and the result on the other). With knowledge of the message you can adjust your data so that any data the other side returns returns any message. Obviously not a complete system, but why I was saying "it can be done".

[burdges]

Yes, that's true.* :) It still require retaining the metadata on your past correspondentses, potentially quite dangerous. I could imagine a "Do not retain" option that, if you choose to retain, then Pond asks you to edit to minimize and saves with no attibution.

There are ocasional discussions in the Tor community about building a "Boarder Crossing Wizard" that lets you encrypt and upload your data but splits the keys up amongst select friends. A priori, I'd expect such tools could handle use cases around such private messages somewhat better, ala "I've attached a copy of my last will encrypted such that if 5 out of 7 of you agree I'm dead, then you can reconstruct it."

• There are technical risks in similar protocols that do not apply to pond specifically : If you've a system that stores messages in a DHT and plays that xor trick with the addresses and sncryption key, then the servers can potentially confirm the original message date, and the encrpytion is a strong confirmation.