Encryption in everyday life
Privacy and security are too complex. One of the more complicated elements is a concept called encryption, which gets tossed around a lot, even in products that implement it quite differently. In a lot of privacy policies, companies will state that they “follow industry standard practices, encrypting data at rest and in transit”. That sounds secure, but what does it mean practically? In what situations does it protect you, and in what situations would your data still be vulnerable? What about end-to-end encryption, another buzzword tossed around in privacy forums and circles? This post seeks to be a high-level guide for what encryption (and the various ways it is implemented) means when applied in a practical context.
What is encryption?
Encryption is the process of turning data into garbaligoop that cannot be read without the presence of a key. If I had the following phrase “Hello, World!”, and I encrypted it, the encrypted version may look like U2FsdGVkX1/b3tBuPMmNFSWKcAfyj5Wl/WBomUbyL2U=[1]. You can get to the original message via two methods, either knowing the key (easiest) or by guessing the key (computers can try billions of combinations a minute). You don’t really need to worry about exactly which algorithm is used, it will either be implemented properly or it won’t be, but as we are not cryptographers we will have to trust experts.
Questions to ask about encryption
When thinking about encryption, we need to think about the answer to a few simple questions. If we don’t know the answer directly, we can ask even simpler followup questions to get to the answer.
What data is encrypted?
This won’t give us as much clarity as we might think, but we have to start here because everything else depends on it. Some examples:
- In simple text messages (SMS), nothing is encrypted.
- When connecting to a web page, the contents of your request will be encrypted, but usually not the domain you are connecting to.
- When using WhatsApp, the contents of your message are encrypted, but not who you are contacting or when.
When and where is the data encrypted?
Here we get into more depth. There are two main places where encryption can take place: your device, or the server (company) that receives the data. We can use the example from the start of this blog to visualize the difference.
Case 1: Data is encrypted by the company before storing in their systems (a.k.a in-transit and at-rest)
This is by far the most common implementation. When interacting with a service, they receive your data in the clear[2], then use their key to encrypt it before storing in their systems. If a process that they run needs to do something with your data (perhaps some analysis for AI or advertising) they can give that key to the server running over the data so that it can read the data for its computations. Additionally, employees (usually under specific circumstances outlined in the companies’ policies, such as a warrant or account recovery) can decrypt the data.

There are numerous reasons why this is the most common implementation, including:
- Computational load can be performed by the companies’ servers as opposed to your machine. When you search through your Gmail inbox, it isn’t your computer doing that work, it’s the machines at Google.
- The service may make recommendations based on your data, or show it to others (a social network for example). In order to do this, they need to see it.
- It makes it easier to combat abuse on the service, because they can monitor and see what data is flowing in their systems.
However, for you, it means you trust the company, any entity that company trusts (third-party customer service reps are prime targets), and the government and laws that company must follow with your data. That’s a big ask!
Case 2: Data is encrypted by you, before sending to the company (a.k.a end-to-end encryption)
In this situation, the only other receipt of the information is yourself in a future time and place (think encrypted storage), or an individual or small group of friends (in the case of a messaging app). The company server acts merely as a custodian, holding your encrypted blob for you or sending it to another person. Outside of these contexts, end-to-end encryption is rarely used. For example, Facebook cannot implement end-to-end encryption because it needs to show the data (your posts) to others. However, the messaging component of the service, can be end-to-end encrypted, the only people that need to see the contents of the message are the other recipients.

When the data is encrypted by you (or rather, your device) you hold the keys. This comes with a lot of power! You can decrypt your garbaligoop when the server sends it back at a later time, so long as you still have those keys. Sometimes this takes the form of a password, sometimes the device itself is required.
Quick questions to identify which of these two models a service follows
Number 1 is probably the easiest and most telling.
- If you can phone or email support and have them reset your password, the service is almost certainly not end-to-end encrypted. The way that they reset the password is using keys they control.
- If the service has any mass social or public features, unlikely end-to-end encrypted.
- If the company needs to know things about your data, such as your bank needing to know how much money you have in your account to approve a loan, then they have to hold the keys. A bank would collapse if they never knew how much money was in their accounts at any given time.[3]
- Does the company mention anything about encryption being done “client-side” or “you control the keys”? If so, likely end-to-end encrypted, but check the exact details in the privacy policy.
Why the type of encryption matters
Ultimately, you are choosing between managing the responsibility of encryption yourself or having the service provider handle it for you. If you use an end-to-end encrypted service and forget your password, there really is nothing the company can do to help you get that data back; math doesn’t allow it. If you instead let a company handle that, you trade individual risk for systemic risk. Companies are incredibly unlikely to lose the key, however they are prone to getting that key hacked for all accounts at once. Governments can also conveniently serve warrants, knowing that everyone’s data will be in one place and that the service provider can provide it in decrypted form.
Encryption shouldn’t be the exception, it should be the rule. Unless you can think of a reason why something cannot be encrypted, it should be. Messaging is the lowest hanging fruit, switching to an end-to-end encrypted messenger like Signal (best) or WhatsApp (tolerable) can make a huge improvement in your privacy and security. Many platforms are implementing end-to-end encryption in the messaging component of their applications (X just announced the feature last week) but pay attention to the details. Go back to question 1; what data is encrypted, and is it end-to-end encrypted? Is it everything, including the metadata (the who and when of a message) or just the contents? What about other things like your location when you send the message? The privacy policy should explain this.
If the data is only for you (photo storage is a great example), then this is also a compelling application of end-to-end encryption. Why should the company have access to that data when they don’t have a valid reason to need it? You can still share with your friends by providing them with the share link and a password so they can decrypt it.
In the event that you want to use end-to-end encryption but don’t want to ditch your favourite provider (that doesn’t offer it), there is nothing stopping you from encrypting the data manually before storing it! You can use something like Cryptomator to encrypt your data on a non end-to-end encrypted service.
However you want to interact with technology, you should feel you have choices around your data and privacy. After this post, I hope you have a better sense of the concept of encryption and how it can be applied in the tools you use everyday.
Other resources
I’m not the first to write about this. If you want a different perspective on the same topic, check out:
If you want to try this yourself, you can use https://tools.markpitblado.me/encryption ↩︎
It is encrypted in transit, so nobody outside of your interaction, such as a network eavesdropper can read it except their server. ↩︎
I’m sure someone will say there are some crypto platforms out there that don’t know your balance, but in environments that are regulated or where credit is extended, they do have to know. ↩︎