Theoretically, forwardslash and I (the coders) could see comments that you upvote, since the app needs to know and that data isn't encrypted. Off the top of my head, we could probably write the app in such a way that we can't know, but I am not sure if that information could be useful in a functional/moderation sense in the future. -That is, maybe you want to see the comments that you have upvoted. Actually, if you visit my profile mk, you can see your interactions with me there. So that uses this comment upvote data, but it's not post-specific, and only you can see it. In reality, we don't, and I don't think we should. I don't think other users should see your comment upvotes. I haven't spent a lot of time thinking on why, but I am against it. As for clicks and page histories, no. The only thing we log in terms of non-vote/comment/share activity is the last time you as a user logged in (not visited, but actually logged in). We don't log posts or links visited, IP address, entry page, visit length, or anything like that. The app doesn't have activity logs. Our Piwik Analytics does some of that with the accuracy of the first 3 digits of your IP (the last 9 are masked, so we only know your country), but even that data is wiped every 24 hours. If you had access to our analytics data, you could probably figure out the countries some users in the last 24hrs were from based on some of the pages they visited (like the settings page). The Hacker News source code did log aggressively, but we removed all of that.
I wonder, would it be a good idea to use the rewriting of the Hubski code to improve the safety by design part of the code? This means that you design the code from a safety point of view from the get-go. A while ago I read about this subject which used an insurance company as an example. They wrote / encrypted their database in such a way that no single worker could access a customers sensitive information, that it could only be unlocked when the person whose data it was was actually there. I could see this with hubski where the comment liking system has to check if the user requesting that info is the logged in user that it's about (if that makes sense). forwardslash?
It's definitely something we can look into, and something I plan to delve into especially around user authentication and authorization. Any ideas you had in mind?
You're hashing the password serverside, yes? So hash it via two different methods(*) - one for the password check as usual, one that is used as an encryption key to unlock the person's history. This doesn't prevent everything, but at least prevents (for example) someone from walking off with the database and automatically getting everyone's history. (*) Or hash it with two different salts, probably simpler.