31 ms·
I agree, and also yes he admitted it, but isn't that worse? There weren't any safeguards or anything to catch it on the reddit organisation side. It was only u
by eterm 10y ago
I agree, and also yes he admitted it, but isn't that worse?
There weren't any safeguards or anything to catch it on the reddit organisation side. It was only users noticing forcing an admission that means it's even a matter of record.
- freehunter 10y agoWhat kind of safeguards could be put in place that couldn't be disabled or overridden by the admins?
- logmeout 10y agoUse a bot to monitor comments and an SCM like git to detect potentially suspicious differences. Like a comment change that is not marked as user edited. Or a comment change that seems to shift the original meaning significantly.
- freehunter 10y agoWould those be managed by the community, or by the admins? If it was official, it seems like the admins could still shut it down, or edit that database to ignore their changes.
- qb45 10y agoNo UI for traceless edits and DB password split in three parts like nuclear launch codes. Then the CEO couldn't do it alone and he would have some time to think things through before others agree to participate in such fishy business, if they do at all.
- freehunter 10y agoThe password one is good, but if three admins decided to conspire to change a comment, what then?
- ibejoeb 10y agoThen you have collusion, and this is what we want. This is a very typical control in regulated environments. It makes the action more difficult to execute, and it tends to carry an additional penalty as a separate offense. This is bigger than trolling. We know people inspect the social network activities of others. This kind of abusive can result in all sorts of bad things. What if and admin didn't like you, edited your history, and then suddenly you lost your job for some fabrication of, e.g., a racist comment?
- tzs 10y ago> No UI for traceless edits and DB password split in three parts like nuclear launch codes. That works well for nuclear launch codes because the only time you need to combine the split parts to make the full launch code is when you are actually going to launch (and perhaps during scheduled readiness tests). This should be fairly infrequent. For a database, you'll have processes that frequently need access. For persistent processes, you'll need to have the reconstituted password available at least whenever the persistent processes start. If you architecture has dynamic processes that access the database (e.g., you have something internal working over a REST or CGI or similar interface, that starts upon receiving a request), you need a way to get the password to them. Most solutions I've seen for supplying the full password in these cases have been fairly easy for someone with admin access to the machine running whatever it is that holds the full password and/or to a machine running one of the processes that needs to full password to get a copy of the password.
- xg15 10y agoThat's proposing a technical solution for a social problem, which is usually a bad idea.