encrypt name choices / partnering data?

[williamlief]

How do we change the database so that we can't look up an individuals name selections or partners?

First thought is that we would encrypt the uuid in the users table, and when the user logs in the session cookie stores the key to decrypt the uuid and thus read/write to the partners and selections tables. There'd still be vulnerabilities, e.g. we could correlate log in times with times names were rated at, particularly with a small user base.

This isn't a feature I think we need to have, but it seems like an interesting problem to try and figure out. Also, it'd be a cool selling point.

[bcerjan]

My initial thought is to use their password (which we don't know) to do the secondary encryption. So when a user creates an account (or changes a password), their password is also used to generate a secondary hash in a user -> UUID table. It means that the password is used twice, but I'm not sure how dramatically that changes the attack surface.

This answer has some suggestions about how this might be implemented, but I'm still having a hard time getting my head around how we wouldn't be able to de-anonymize stuff if we really tried to (as the people who own the server).

[williamlief]

I think you're right that its probably impossible (or at least prohibitively difficult) for us to design a system that we, as the server owners, can't break.

The value would be that in the case of a database leak, the user emails wouldnt be linkable to the user data. Also, if we were a large organization, malicious employees would have to do things that we could catch in an audit to de-anonymize user data. While right now user data is internally de-anonymized as a matter of course.

Probably the least painful change to our db schema would be to remove the email from the users table and put it in its own table with the hashed uuid. Everything else could then be left alone. From a larger org standpoint, we could just split off the email address to its own table then set user permissions and restrict who can access it.

[williamlief]

Current thinking is that this will not be feasible to implement due to partner emailing functionality.