No. It turns out after a bit of digging that this might be technically possible even though we’re a ~7-person team, but it’d still be additional overhead and I’m not sure I buy that the concerns it’d be alleviating are that reasonable[1].
Not a confident claim. I personally wouldn’t be that reassured by the mere existence of such a log in this case, compared to my baseline level of trust in the other admins, but obviously my epistemic state is different from that of someone who doesn’t work on the site. Still, I claim that it would not substantially reduce the (annualized) likelihood of an admin illicitly looking at someone’s drafts/DMs/votes; take that as you will. I’d be much more reassured (in terms of relative risk reduction, not absolute) by the actual inability of admins to run such queries without a second admin’s thumbs-up, but that would impose an enormous burden on our ability to do our jobs day-to-day without a pretty impractical level of investment in new tooling (after which I expect the burden would merely be “very large”).
I think it would be feasible to increase the friction on improper access, but it’s basically impossible to do in a way that’s loophole-free. The set of people with database credentials is almost identical to the set of people who do development on the site’s software. So we wouldn’t be capturing a log of only typed in manually, we’d be capturing a log of mostly queries run by their modified locally-running webserver, typically connected to a database populated with a mirror snapshot of the prod DB but occasionally connected to the actual prod DB.
Thanks for response; my personal concerns[1] would somewhat be alleviated, without any technocal changes, by:
Lightcone Infrastructure explicitly promising not to look at private messages unless a counterparty agrees to that (e.g., becasue a counterparty reports spam);
Everyone with such access explicitly promising to tell others at Lightcone Infrastructure when they access any private content (DMs, drafts).
Clarifying in the first case: If Bob signs up and DMs 20 users, and one reports spam, are you saying that we can only check his DM, or that at this time we can then check a few others (if we wish to)?
TBH the main thing that helps with in practice is that it forces teams to get off the “emailed spreadsheet of shared passwords” model of access management. Which mainly becomes useful if someone is leaving the team in a hurry under less than ideal circumstances.
“That problem is not on the urgent/important pareto frontier” is absolutely a valid answer though, especially since AFAIK LW doesn’t store any data more sensitive than passwords / a few home addresses.
No. It turns out after a bit of digging that this might be technically possible even though we’re a ~7-person team, but it’d still be additional overhead and I’m not sure I buy that the concerns it’d be alleviating are that reasonable[1].
Not a confident claim. I personally wouldn’t be that reassured by the mere existence of such a log in this case, compared to my baseline level of trust in the other admins, but obviously my epistemic state is different from that of someone who doesn’t work on the site. Still, I claim that it would not substantially reduce the (annualized) likelihood of an admin illicitly looking at someone’s drafts/DMs/votes; take that as you will. I’d be much more reassured (in terms of relative risk reduction, not absolute) by the actual inability of admins to run such queries without a second admin’s thumbs-up, but that would impose an enormous burden on our ability to do our jobs day-to-day without a pretty impractical level of investment in new tooling (after which I expect the burden would merely be “very large”).
I think it would be feasible to increase the friction on improper access, but it’s basically impossible to do in a way that’s loophole-free. The set of people with database credentials is almost identical to the set of people who do development on the site’s software. So we wouldn’t be capturing a log of only typed in manually, we’d be capturing a log of mostly queries run by their modified locally-running webserver, typically connected to a database populated with a mirror snapshot of the prod DB but occasionally connected to the actual prod DB.
Thanks for response; my personal concerns[1] would somewhat be alleviated, without any technocal changes, by:
Lightcone Infrastructure explicitly promising not to look at private messages unless a counterparty agrees to that (e.g., becasue a counterparty reports spam);
Everyone with such access explicitly promising to tell others at Lightcone Infrastructure when they access any private content (DMs, drafts).
Talking to a friend about an incident made me lose trust in LW’s privacy unless it explicitly promises that privacy.
Second one seems reasonable.
Clarifying in the first case: If Bob signs up and DMs 20 users, and one reports spam, are you saying that we can only check his DM, or that at this time we can then check a few others (if we wish to)?
TBH the main thing that helps with in practice is that it forces teams to get off the “emailed spreadsheet of shared passwords” model of access management. Which mainly becomes useful if someone is leaving the team in a hurry under less than ideal circumstances.
“That problem is not on the urgent/important pareto frontier” is absolutely a valid answer though, especially since AFAIK LW doesn’t store any data more sensitive than passwords / a few home addresses.