Imagine you're building Facebook, except you don't want to reveal user identity for posts and comments. You still want to verify each user's organization. For example, if the user signs up with [email protected] then you will only let him write posts after he's verified his email. This is my initial setup.

  1. Posts and Comments have authorId field.
  2. There should be an option to become "not anonymous" and reveal your email address when writing a post.

Because of number 2, I hesitate from throwing away email address from a User once it's verified. Right now, I think the best solution is to run a cron job periodically and remove userId field from anonymous posts and comments that are older than a certain amount of time. Then, when the database is compromised, no one will be able to associate an anonymous post with a registered user.

I don't know if it's the best way to do it and wanted to seek help from security experts. Any help will be greatly appreciated!!

  • I think one of the biggest problems you'll run into with this one is that in a social network context, people want to be able to see a history of their posts, or view feedback on things that they've written. If you have some way of associating a user with their posts, any hope of anonymity is gone at that point.
    – Nic Barker
    Commented Aug 23, 2015 at 2:35
  • @NicBarker you're exactly right. The biggest limitation with this approach is that we can keep a post's record for a limited amount of time. Consequently, you won't be able to be notified if someone comments on your post after that period. Users won't be able to see a full history of their posts and comments as well -- they will be able to see "my recent posts." I think this is a trade-off that might be acceptable. I don't think anonymity is lost if there's an association between a post and its author for a limited amount of time. Any ideas?
    – Maximus S
    Commented Aug 23, 2015 at 2:38
  • Yeah, it seems like an acceptable solution if that's what you're going for. It sounds like your implementation is going to be a tricky balance between UX and anonymity. You could also consider just disabling notifications / history for anonymous posts, a la 4chan.
    – Nic Barker
    Commented Aug 23, 2015 at 2:46
  • Will you backup your database? Commented Aug 23, 2015 at 4:50
  • An interesting idea would be to be able to "favorite" comments: i.e. user would favorite their own comments, or someone else's, and by that, be able to see their favorited comments stored somewhere. It could be combined, or another feature that could make the user "watch" the post/comment to notify them of updates/new comments. The user data will contain their favorite/watched comments. Commented Apr 1, 2023 at 12:03

2 Answers 2


If I understand you right than you want to make sure that no user data are compromised even if your site gets hacked. First you should be clear that this only can apply if you detect hacks to your site. If the attacker manages to hack your site and you don't notice this then the attacker can track all activity on this site and probably de-anonymize the users which use the the hacked site.

You should also be clear that users might be de-anonymized by the way they write, i.e. the writing style, the time they write, the topics they know about and the arguments they use. Thus full anonymization will probably not be possible because the information the users inadvertently provide on themselves.

Apart from that you should never ever store any information which might be used to make de-anonymization easier. That is you should forget the e-mail address provided by the user immediately after you've sent the verification mail and should only associate some random token with the account. And you should not associate any posting by the user with the account or with each other because analysis over multiple posts by the same user provides way more information about the user than a single post would do.

Of course these restrictions in the information you store impact the usability of the site. You can also never provide some password recovery since you don't have any information about the user (no e-mail, no secret questions). You can also have nothing like all posts by the user or even recent posts because you don't associate posts with each other. And it might even be hard for a user to edit its own postings, although see this question for possible ways.

At the end you might need to find a balance between anonymization and usability. But to do this you should thoroughly analyze the situation, i.e. do an evaluation of how much anonymization you need to provide and which risks your and your users are willing to take at the cost of better usability. And of course the users must be aware about the risks, so don't claim full anonymity if you cannot provide it.


Requirement 2: Opt-in revealing of name and email

Option 2 can easily be done without your server having to always remember UserId & user's email:

When the user wants to post a non anonymous message, the user supplies his name and email address. If identity sproofing is a problem the user can keep a certificate proving that he owns the given username and attach it to his attributed posts.

Requirement 1: Anonymity

The first option could be implemented via API keys:

  • Once the user's email address is verified provide the user with a bunch of API keys;
  • Have the server forget the user email and other identity data;
  • The user can post one or more messages using the received API key, again the server forgets any information linking one API key to another; and
  • The user can request more API keys when needed.

Nic Barker's requirement: Personal history of posts, receiving feedback

A user can keep track of his own messages by storing ids of posted messages or by storing ids to API keys or to alliasses used to post messages in a datastore controlled by himself (either his own device, or an encrypted store on the server).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .