And not just what, but why, how, and how long?
In our previous posts about why teams should use secure messaging, secure messaging metadata, and server locations, we talked about some of the mechanics of sending secure messages. Now we’re going to talk about the last piece of the puzzle—what’s stored on servers, how long it stays there, and why it’s there in the first place. The best practice for secure messaging, and the easiest answer, is not to store anything on the server at all. However, the reality is that some data must be stored on servers—at least temporarily—for the service to work. It’s a trade-off that the Electronic Frontier Foundation (EFF) covered in their Building A Secure Messenger post and we talked about in the metadata post. As the EFF says in their post:
Hiding the network metadata is a feature we’d like to see grow past the experimental phase. Until then, we expect to see services retain only the metadata absolutely necessary to make the service function, and for the minimum possible time.
Which brings us to what gets stored on a server—why it’s stored, how it’s stored works, and for how long.
Getting the message delivered
One of the more important parts of a messaging app is making sure the right message gets to the right person and the messages are delivered in the right order. Imagine how confusing a conversation would be if the messages arrived in random order. To keep messages straight, messaging servers need to know who is talking with whom and when—Bill sent a message to Jane at 07:31, Jane sent a message to Bill at 07:35. This gives the server enough information to keep things straight, especially for group messages. These data can be carried in the encrypted message itself and once messages get to the recipient and decrypted, the rest gets sorted out. All that’s really needed is some identifier for the user and a timestamp. You don’t need the IP address of either side of the conversation. You don’t need a nickname or phone number. You certainly don’t need to have to store message—not even an encrypted version. Well, except for one case, and we’ll talk about that in a moment.
As we talked about in the metadata post, the meta information stored on a server can be a goldmine of information about users. To protect users’ privacy and limit the amount of information that a company could be forced to share with law enforcement (or potentially exposed to hackers), many services only keep data for a few minutes or hours. SKY ECC, for example, keeps no records of messages once they are delivered. If you want a look at the message logs from an hour, a day, a week, a month ago—we can’t help you. There is no doubt this makes things challenging for our developers to keep straight in our app, but we think this trade-off is worth the inconvenience (to us) to better protect our users, their privacy, and their security.
The only time messages need to be stored
There is one time when all E2EE apps need to store a message on the server for at least a little while—when one or more people receiving the message are offline. There isn’t much of a way to get around this, unless you want an app that only works when everyone is online or only send messages when everyone is online—and those aren’t convenient options for most people. To handle the “one person is offline” situation, encrypted messages are stored on the server until the offline person comes back online. Once the person is online, the message is sent and removed from the server. The next question is, “Okay, you keep the message on the server while someone is offline, how long do you wait for the person to come back?” This is important since while still on the server the sender, receiver, timestamp, and message are all there together in the encrypted message. Digging deeper into the question, you have to balance how long you expect a person to be offline with how much risk is there keeping the message on the server. For SKY ECC we think 48 hours is the right balance. If you haven’t logged into SKY ECC for more than 48 hours, any messages that might be waiting for you are gone. If you’re chatting with someone and they lose their connection—like in a tunnel or underground parking—they will be able to catch up when they are connected again. For people who travel on long flights and might be offline (airplane mode) for an extended period of time, it’s unlikely you will exceed the 48-hour threshold.
If you send a file…
There is one more case where file storage might come into play—sending photos and files attached to messages. Just like messages, files need to be encrypted. Technically you’re not encrypting the contents of the file, just putting it in the digital equivalent of a locked box while in transit. Best practice—the only practice really—is not to store the files on the server (except in the case above while waiting for people to come online), but what about after you receive a file? For true privacy and security, the file (like a picture) should self-destruct or be stored securely on the device encrypted with your password (and not stored in the photo gallery of your device or other storage drives in the cloud). The file shouldn’t be available outside the secure messaging app. It might be less convenient to have images and files locked in the app, but it’s more secure if you want to keep those files confidential.
Most E2EE apps handle files this way—keep files locked and protected within a secure vault within the app—except WhatsApp. WhatsApp, by default copies any pictures or videos you receive to your device’s photos app. You have to go into the settings and turn this setting off to stop filling up your device with pictures or leaking sensitive information on your device. Remember, once your device is unlocked all the media WhatsApp has transferred to your photos app is right there for anyone to see. For security and privacy, this isn’t safe or confidential, and we’re not alone in thinking this either. WhatsApp sacrificed security for convenience by allowing people to save photos they receive into their photos app or gallery one by one. Everything in security is a balance between security, privacy, and convenience. We believe we’ve struck a good balance in SKY ECC where it’s very secure, very private, but also easy to use and adopt into your work.
Save only what you need to for only as long as you need to
Beyond making sure your messages are fully end-to-end encrypted, understanding how your data is handled and where the data sits in the world is an important part of privacy and security. If data—messages, metadata, or files—sits on a server it is vulnerable to being released. The ultimate goal for all E2EE apps is to keep only as much data on the server as is absolutely necessary and then keep it only as long as absolutely necessary. The less information you keep, the less information you could accidentally or intentionally share with others or leak to unintended parties. If you don’t approach privacy, security, and messaging from this standpoint—then we think you aren’t fully protecting your customers and their data.