Privacy isn’t about having something to hide. It’s about maintaining agency over your own information in a world where the default is to collect everything, store it forever, and monetize it later. Every data point you hand over is a bet that the company holding it will never be breached, acquired, or compelled to share.

The practical toolkit: [[Email Masking|email masking services]], [[Encryption]], strong [[Password Management]], and a healthy skepticism about “free” services that fund themselves through surveillance.

I support either Bitwarden or 1Password as great options for most people. Apple Passwords is okay, but vendor and ecosystem locked, and doesn’t have all the standard features; but it is better than nothing.

I would avoid using Google Chrome’s password manager (or any browsers).

I do not recommend LastPass at all.

End-to-end encryption means only the sender and recipient can read the message; not the service provider, not the government, not an attacker who compromises the server.

Right now there is an ongoing development of the Tea App having multiple data exposures. I don’t think I can give the details justice, so please look to 404media.co as they have been covering it quite well!

The long and short, this app was purported to be a safe and private space for women to discuss dating. However, because they wanted to ensure it was only women they had a problem, verifying that fact.

They decided to use a selfie-with-id method, and ended up failing to secure that data both in storage and in deletion. Now, there are other issues with this app, but I want to focus on this particular problem they were trying to solve. How do you verify someone is who they say they are, with minimal compromise to their privacy?

Let’s look at what they ended up doing and where that failed.

To verify if someone was a woman, Tea would request the user to send them an iID document (License, Passport, etc) with a selfie of user in the photo. This is an effective way to verify someone, I will grant them that. However, it completely breaks any privacy expectations.

Because they chose to accept Personal Identifiable Information (PII) data the Tea app then needed to consider how they handle the data. How should it be transferred to the verification system? Who or what is verifying the data; is it automated or human based? Are you encrypting the data throughout this process? If so, you will need to decrypt it to verify, will that have any caching, logging or other artifact concerns? If there is a human involved, will they be able to exfiltrate the data by saving it, taking a photo with their phone, or otherwise? Once the data is reviewed how do you ensure it is deleted from the system properly?

As you can see, there are already a lot of questions, which will lead to more questions. In the end there was at least one point where the data was not encrypted and stored on a firebase storage bucket and that bucket was not protected.

So, in all honesty, it was a bad idea.

Looking back at the original problem, what is another way we could solve this problem that could have avoided these potential problems and resulting outcome?

A Trust Ring

Rather than having the App take the responsibility of verifying the user’s identity, they could let the users do it amongst themselves.

Setting up a system where the trust is created and developed between the users could allow for a more private and secure system. A hypothetical way this could work is:

1. Make the sign-up invite only from other members
2. Accepting an invite creates a trust between the two users
3. Users can also sign-off on others to create additional trusted links and networks of trust

This is a basic idea, you could add more layers like having to only send the invite over bluetooth (forcing a more localized requirement). Or adding in different levels of trust (invited, in real life confirmation, etc).

The trust ring would be able to rely on its core principles of:

1. Direct trust established between users
2. Transitive Trust: If User A and B trust each other, and B trust’s C, then A is one degree away from trusting that user.
3. Leveraging the Degrees you can weigh how much someone could be trusted to discuss sensitive issues with.
4. Someone that has many direct and reciprocated trusts could help establish them as trusted even at a distance.

How could this look for the user?

Suppose you hear about the app from a friend, they would give you their invite code and you can sign up. That creates an initial trust between you and that person. From there you might be able to see their first level trusted friends on the app, you could then ask your friend that invited you to verify if they know those users and also trust them, maybe at a lower level of trust, but you trust your friend and they trust these users. Over time this could create a network effect, where you have a strong set of trusted people to talk to. Since this app was designed around dating, and most of that is fairly localized, that can also help determine who is actually in your area or who might not be. Additionally, suppose a new user reaches out, you can see how you might know them through the trusted network you have, or maybe see that they don’t have much of a network at a time and work to confirm things first.

Now this wouldn’t be the final solution, but it would be a good start to keeping the users a lot more safe and private; rather than handing over their ID and everyone needing to trust the Application’s Owners and Moderators.

Additionally, this isn’t a perfect system, this can still be abused through manipulation of the trust network and it doesn’t directly prevent non-welcomed users (men in this case) from signing up and trying to pose as a legitimate user. But fake IDs and AI exist well enough to make a convincing selfie-with-ID - so I’d call it even there.

You could also extend this using other attribute based methods. As mentioned with using local proximity to verify or send invites, you could also use user general locations to help verify the legitimacy of trusts being created. I am sure there is some math to help determine what the average expected trusts would be between people and if it exceeds that or looks abnormal it could flag a user. I remember during COVID there were apps that would be able to share exposure proximity via BLE, that could potentially be adapted too. Anyway I am digressing a bit here.

Final Thoughts

The long and short here is, if an App or service states it is privacy focused and asks for very sensitive information to be able to access it, maybe think twice before handing that over. And from the design perspective, sometimes the simplest choice initially, will be the more complicated and riskier process.

Unfortunately, it’s highly likely that your information will be exposed at some point. This has become a common enough occurrence that instead of asking, “If it happens, what do I do?” it’s more prudent to ask, “When it happens, have I prepared enough to minimize the impact?”

I’ve considered this from various angles, but one method of protection worth discussing is “Hide My Email Services” like Apple’s service with iCloud, or Proton’s service and how these services can be used to protect your privacy.

Keep in mind though, that whenever you plan to increase your security or privacy you will, in most cases, lose some convenience or ease of use.

What Are Hide My Email Services?

To start, these services create an alias that will relay any emails sent to it directly to your main email address. These aliases are often a randomly generated name with one or several domains. So, if your email is jdoe@gmail.com and you use Apple’s Service, it will generate an email like Jade.0a.Kiwi@icloud.com. You can then use this email for a website, and even generate multiple aliases that point back to jdoe@gmail.com

Think of it as having an unlimited number forwarding addresses for your main email.

Website --Sends Email--> Alias Email --Forwards--> Main Email

Aliases Alternatives

Some email services also offer a similar feature by allowing you to append a + to your email address. So jdoe@gmail.com can use something like jdoe+facebook@gmail.com as an email for Facebook. This would allow them to know that, in theory, only emails from Facebook should be going to that email, and if they get something from somewhere else they may be able to assume that the email was sold, exposed, or otherwise leaked.

Now, the issue with this from a privacy perspective is that the root email is clearly exposed. Instead, the goal is to make it difficult to guess your main email address and to ensure your provided email is as unlinkable to you as possible.

When to Use Hide My Email Services

Now that we know, in general, that these services offer an ability to create unique, random emails that can be used to protect your main email, let’s discuss when it might be appropriate to use these services, and the drawbacks in each case. I will order these in what I think are the best way to start as a path to more “advanced” usage.

Level 1: This is just temporary

If you run into a site or service that needs an email, but you don’t ever plan to really manage the account (I will come back to this point though) then this is a perfect service for that.

Suppose you’re at a restaurant and want to place an order through their website, which requires an email address. You can use these services to generate a temporary email, complete your order, and then delete that email to prevent any future spam.

And that’s really it! Use the service as a temporary email, you can make just one for all use cases or generate a new one every time. I would suggest making a unique one for each, if possible, because that let’s you get used to managing multiple ones at ones and move on to the next level.

Level 2: Why do I Have to Make an Account?!

Okay, so same as before, you’re in a situation where you have to not only provide an email, but also make an account. Rather than using your main email, use a Hidden email instead! Additionally, make sure to use your password manager to generate a random password.

This site will now send spam only to your randomly generated email. And since the site now has associated login credentials, it could potentially be a source for email and password leaks. However, since they are both random, it is basically just junk. Sure you do need to make sure to secure that account the best you can, remove any other information, credit cards, etc.

But now this data cannot be used to comprise your accounts on other sites.

Level 3: Change My Email

At this point, I hope you see where we are going. Taking this a step further, we can start changing our non-critical accounts to use Hide My Email services. Randomly generate a new email, log in to your site still using your root email, and then change it. Oh, and update your password while you are there to make sure it is fully randomized while you are there; and set up MFA.

Remember, this is only protecting you when it comes to linking the email to you directly and cross referencing/attacking to other sites.

I will want to also add a note here that you should take care on which sites you do this with. For social media, video game accounts, shopping accounts, there shouldn’t be too much of a risk using these emails. However, financial sites, government accounts, and other “Identity based sites” you may want to use your root email or other softer alias techniques like the + appending technique. Why? Well, it could be more frustrating to maintain or get support with a randomly generated email. Also, these sites tend to, but not always, have a stronger security posture. Remember, we are looking at minimizing impact here, not remove it entirely!

Is it worth the effort?

To summarize what we can do here is:

1. Get a new service, and yet another subscription.
2. Give spammers meaningless, disposable emails.
3. Use throw-away emails for throw-away accounts.
4. Move existing accounts to these new, randomly generated emails.

This helps isolate sites to a single email, lowering the value of your data provided and protecting you from being identified in a data leak. Additionally, in combination with randomly generated passwords, helps to isolate credential stuffing attacks to just that one site.

But, it isn’t all perfect. There are some negatives to consider!

Negatives

Communication

There are times when you may need to send an email from that randomly generated address, like when reaching out to support. This can be clunky or even impossible, depending on the service, and it’s generally not as simple as using your regular email address.

Also, trying to call support, or provide the email can get you some odd looks. And it is cumbersome to generate one in person, but not a non-stopper.

Authenticity

Another thing to be aware of, some sites have protections around temporary email addresses, particularly ones like 10minutemail. This can lead to issues where your generated email may not be accepted if the domain isn’t well known. For example, Apple’s uses icloud.com as the domain, which is well known and accepted in most cases. However if you use a service that uses less known domains, or you can use your own, that can lead to issues with the email not being accepted.

Service Provider trust

A significant concern with these services is that all emails going to those alias addresses are accessible to the service providers. For example, Apple could, in theory, see what is sent to Jade.0a.Kiwi@icloud.com.

Data breaches

When a breach happens you can go to places like Have I been Pwned and put in your email to see where you were affected. However, now you don’t see all your potential accounts, as most will have a unique email. In these cases, usually the site does send you an email to alert you, so you will want to monitor for those a bit more actively. When you do get one, you can do your normal response like resetting the password, but also reset the email!

All in all

Is this worth it? For you, I don’t know. But for me, it is worth applying some of these items.