User Privacy Question
Say i have an app which the premise that it offers a safe place for users to “log” sensitive personal data they might not want the world to know about their commitments to various things.
Over the long run I would want to organise manage and use this data for many purposes, one being to approach individuals who meet whatever criteria i have set up according to the data. Maybe to sell them services or learn from them.
How would one go about user anonymity but still be able to link “logs” to users.
Is this feasible?
I would like to say “your logs are encrypted and cannot be read by just anyone” but at the end of the day an engineer would be able to link the user to their data by decryption.
Is this acceptablet?
12 Replies
This is how google does things - they don't directly sell the sensitive data, they use it to catagorize users and then sell the categories.
Is homomorphic encryption a viable solution?
It has nothing to do with encryption.
Say I log "I love cats so much". you encrypt that, and you never actually read it. But the system logs "user b3nten likes cats" and then you can use that
However you should be clear this is what you're doing with user data
Thats really interesting!
Im now thinking how would i organise this in terms of tables, i would have a user table with all the identifying attributes like user id, email etc
and i would also have a log table, that would identify the user id and the corresponding log as an entry
So when user 1 makes a log entry
Where should it be saved, in the original log table or a new separate table for encrypted logs?
Just trying to create a visual in my headz
What do you mean by "original log table". Are you considering storing the log twice, encrypted and un-encrypted?
I would have to create a separate table with the unencrypted logs with non user identifying attributes, so i can make sense of the data for othet purposes.
And also save the encrypted log in table, that is linked to the user. So the user can retrieve it on the front end?
I cant stress enough how much I dont like this idea. You have no idea what users might write into these log entries. Even though it might seem unlikely for them type in their own name, they might "log" sensitive data containing a relative or a friends name which would be enough to easily identify them.
Regardless of what I think of the idea. If you wanted to store it like that, once decrypted but "anonymous" and once encrypted but linked to a person, then you should absolutely separate that into two tables. One might even argue into two separate databases entirely
I can definitely store it in two separate databases. Would that satisfy your concerns?
Also, what do you say about using one encryption key for all logs. In your experience whats the safest way to store that very important key?
No that would not satisfy my concerns. It's not about the technical implementation. I think the entire idea of prying into individuals sensitive data is immoral. I wouldn't care if you encrypt the logs so that only you could read them (in case of a data breach for example) since I think you reading the logs is the bad part.
I don't care much for discussing the business idea further than this.
I'm not a security guy so I can't recommend a specific solution. However all logs should be encrypted, not by a single key since leaking or having that key cracked would expose all user data at once. It would need at least some segmentation. How much you need to care about all this is highly dependent on how sensitive the data in question would be
Yeah i understand what you are saying. I cannot access the logs there is no going around it.
that sounds inmoral
"yes its encrypted but i copied it again and didnt encrypted it and now im selling it"
it's supposed to be non identifiable
like, if you have a category of "likes cats"