@ricardo3 I agree, it has to be something that both parties agree to. In fact the control of the release of the information is essentially at the will of the 1:1 chat member that is not going through recovery. So if I want to recover my conversation with my contact, I must reach out that contact outside of Status and get them to approve the release of the conversation. So the non-restoring party receives a warning; do not release history unless you have confirmed the other user via a second method outside of Status, this will avoid the identity problem, a kind of two factor authentication.
Again based on my recent education from @cammellos this whole process should not be default and default should by PFS. There are people with whom I would want to be able to recover at the cost of security and those that I would accept not being able to recover based on desire for maximum security.
Hey John! This is exactly the reason why we’re holding an in-person meeting later this week to try to nail down what are the principles we want to uphold with Status chat: https://discuss.status.im/t/chat-risk-management-product-principles-meetup-switzerland/163.
Our goal is to update that thread as we go along so that the community can follow and hopefully feed their thoughts/concerns/expectations into the conversation.
@pedro wish I could be there. 
Have a great time and so excited to watch this happen.
Hi all. Apologies for the late follow up on this thread and special thanks to @Chopstick00 for chiming in with observations and insights from his own use. As mentioned multiple times, we’ll have a chance to discuss FS today and tomorrow at the risk management meetup in Basel but wanted to respond re: surveying users about chat history.
@pedro while it is certainly possible to do, this conversation already highlights that there are going to be different motivations for different types of users coming to Status to try and complete different tasks. E.g., there’s quite a difference between the Chinese dissident starting a 1:1 chat with a journalist and me trying to convince my wife to use Status for our 1:1 to chats. We could run surveys to try and get an understanding of how and when it’s most important for users to have chat history in 1:1 vs group chat but those surveys would need to be well crafted and highly precise in terms of who we are surveying and for what contexts before I would trust results. Even then am not sure I would trust those results in isolation for making decisions.
I’m also quite new to most of the technical details outlined here but it seems like the common question(s) we’re returning to is of what modes (or settings) do we set/start by default when a user creates an account? Or can we provide a flexible way for people to decide what mode to use through onboarding or education when they first start to use?
Generally, I would also recommend against inconsistencies in functionalities for chat history. Meaning that it would be pretty confusing for users to have public chat history available and not private chat after recovery and would argue to have one or the other depending on the level of necessary security for a user. I’d also bet that even the most active users of the highly secure mode/settings will forget that their 1:1 chats will be wiped on account recovery. Which might be the right behavior for that type of user but not others.
Again, thanks all for the great discussion.
The Chat Team regrouped today and discussed some of the points raised in Basel along with other areas of importance and agreed to prioritize PFS.
FWIW I’m +1 on most secure by default and let the user ease it up by choice.
Status as an organization and brand could position itself as an ambassador to the general public about good data security hygeine in the modern age.
A lot of people feel creeped out by the current data collection economy, and don’t like the negative affects of their data leaking around all over the place but feel too powerless to do anything about it, which leads to apathy and just giving in. They think only leet hackers could possibly be safe. Many of them would adopt good practices if someone were to just tell them precisely what to do and made it easy for them.
Status has a really good opportunity to reach these people by using the app to guide them into good data hygeine by explaining in simple terms how and why all the things work the way they do.
Then, armed with that knowledge, and the confidence about their control over their own data, they can make an informed decision to give that up for convenience to various degrees.
Once those people are trained in good practices they will convince their friends to do it too. I’ve personally seen how when people start using Signal and understand why, they start to feel unsafe using SMS.
Not convinced about the “lift off phase”.
“Secure by default” and “secure messenger” imply that we’re giving security a priority - implementing a way for users to send non-pfs messages counters this.
It’s hard enough as it is to teach users what “secure” means - effectively, I’d be wary to say we support PFS (or “secure messaging”) until all ways to send actual messages are protected (not even considering metadata leaks here) - “we mostly support PFS except when X, Y and Z” is a pretty weak statement, and is bound to sow confusion. We’re already having trouble ourselves understanding what the properties of our current messaging are (for example, it’s not “secure” by 2018 standards, not even in the context of “normal” messengers)…
How about simply disabling async messaging until we have a proper key exchange / distributed X3DH in place? Having a half-baked solution in seems like a crutch that will delay a proper solution - it still needs to be implemented, tested, deployed, potentially audited and bugfixed, and it will pollute the protocol - can we avoid this with a more simple solution at the cost of some UX?
As discussed in Basel, I like the idea of splitting up the problem into its constituent pieces and attacking these pieces separately. This means Identity/Key Exchange, Ratcheting and Backups/Multi-devices can be attacked completely separate from each other, making sure that each part of the problem receives the attention it deserves. For implementation plan, it means that black-boxing or delaying x3dh, backups and all that for later and focusing on the best ratcheting we can come up with, for example. This way, we start with the clean slate of a PFS-enabled protocol, and enhance it to support the other features, making sure that each step along the way maintains PFS and other security properties we’re interested in.