protected content security
May. 9th, 2010 11:42 amThere's a bunch of talk going around right now about the whole issue of content security, and trusting the people who host your content and have access to it. I wanted to talk on that for a moment as it's something that is really important to me.
The only people that are authorized to view protected content on Dreamwidth that they don't otherwise have access to are
denise and myself. We are the only people with the proper access level. On top of that, it's not automatic -- in order to view the protected content, every time one of us visits a URL we have to edit it and add "viewall=1" to the end of it. It's a very manual process (for good reason). It's also logged -- and I don't know about Denise, but I review the logs regularly, just like every other security log we have.
The second level of access is for people who have access to the production servers that run Dreamwidth. When someone has the ability to log in to our servers, they have full access to the data on the databases and could in theory access protected content. The only people with server access are again myself and Denise, plus our two sysadmins:
matthew, who used to work for LJ (before and during Six Apart), and
alierak, who I've known for a decade and I trust completely.
That's it. The four of us.
At some point, it comes down to trust. We need the ability to work on the servers, so there are always going to be a set of people who have the ability to see private data. This isn't something that we can feasibly get rid of, either. The data exists on the servers (that's how we can show it to you and the people who are authorized to see it) and we need access to those servers to maintain them. The data isn't just sitting around visible to us, though -- it's tucked away in the database and requires a lot of manual effort to dig out, unzip, and connect to a user account. We never see post content accidentally.
In the end, I think that the best that I can offer anybody is to be explicit about who has access (and what kind of access they have) and to personally watch the security logs. I watch to make sure we don't have unauthorized access to our servers, and I look for unauthorized access to private data as well. It's part of the routine, and it's something I take very seriously. Having dealt with some problems related to this in the past (on other projects, with other people) it's not something I want to see Dreamwidth have to go through.
I'm happy to talk about this, if anybody has any thoughts, comments, or questions.
The only people that are authorized to view protected content on Dreamwidth that they don't otherwise have access to are
The second level of access is for people who have access to the production servers that run Dreamwidth. When someone has the ability to log in to our servers, they have full access to the data on the databases and could in theory access protected content. The only people with server access are again myself and Denise, plus our two sysadmins:
That's it. The four of us.
At some point, it comes down to trust. We need the ability to work on the servers, so there are always going to be a set of people who have the ability to see private data. This isn't something that we can feasibly get rid of, either. The data exists on the servers (that's how we can show it to you and the people who are authorized to see it) and we need access to those servers to maintain them. The data isn't just sitting around visible to us, though -- it's tucked away in the database and requires a lot of manual effort to dig out, unzip, and connect to a user account. We never see post content accidentally.
In the end, I think that the best that I can offer anybody is to be explicit about who has access (and what kind of access they have) and to personally watch the security logs. I watch to make sure we don't have unauthorized access to our servers, and I look for unauthorized access to private data as well. It's part of the routine, and it's something I take very seriously. Having dealt with some problems related to this in the past (on other projects, with other people) it's not something I want to see Dreamwidth have to go through.
I'm happy to talk about this, if anybody has any thoughts, comments, or questions.
no subject
Date: 2010-05-09 07:07 pm (UTC)Thinking along those lines, could you send a notification to the user, as well as logging, when someone with privs views a protected entry? The text of the message could include something like, "This is most likely in relation to a support request you raised" or whatever is necessary to explain why it's happening and reassure the user. It feels, to me, a bit like the email you get that says "Someone, possibly you, has requested a password change."
no subject
Date: 2010-05-09 08:06 pm (UTC)My first thought is: it only addresses half of the issue. On-site access. Right now, that's only Denise and myself, but in the future I can see us adding staff to that list who need that ability. (Think Terms of Service people, senior support administrators, etc.) The idea doesn't address sysadmin level access -- and I'm not even sure how you could, at that.
But even if we accept only the on-site half as being worth addressing, then we run into more problems. The viewall utility is used for many uses, not all of which I would want to send emails for. (Reports of a credible suicide threat, investigating a ToS violation, me verifying imports/deletes/purges/things, etc etc...)
Also, I could see us being in a situation where someone makes a report that user X is posting their private details, invading their privacy, all behind a lock! So we viewall, but it turns out to be a false report -- now user X is all "WHY WERE YOU DOING THIS TO ME" and we have to say "someone reported something" and that seems problematic to me. We're not going to release details on who reported what, or why they reported it, so we're pretty tied in what we can say. I expect getting a form letter would get old and not engender trust.
Of course, then another thought is, would you rather know that someone looked, even if they won't tell you why, or just not know at all? I lean towards the latter, but I know other people will lean towards the former. I know that my data on Facebook is visible to their admins, I accept that, and I don't put anything there I don't want them to see.
I dunno. I definitely see where it would be nice to say "look, we email you when your content is viewed by admins" but I can easily see how unscrupulous people will weaponize that, or how it will hinder me in some situations (i.e., if I'm verifying a community import worked, sometimes I viewall to make sure everything worked right -- screened comments, members only posts, etc). The ability to, as a sysadmin, check that things worked properly is valuable to me.
All of those thoughts, plus the fact that it only works for on-site access, makes me think it's not really worth doing. What do you think?
no subject
Date: 2010-05-09 08:35 pm (UTC)My purely personal perspective, admittedly as someone who knows a lot about how this sort of thing works since I'm a professional sysadmin, is that the site users have to trust you and Denise by necessity and, beyond that, I'm not sure there's a lot of utility in trying to enable community audit of your activities. I'm also not sure that there's much utility in notification if there's no option or decision available to the user.
One thing you could consider is, in a future world in which you may want to grant more fine-grained access to additional people, would be to distinguish between access under the user's control and access that is done by a site admin. For instance, when submitting a support ticket, a user could potentially get a checkbox saying "allow senior support people access to my restricted content" which they could check if the request seemed to warrant it. If they chose not to check it, then their support request may take longer if it requires such access until you or Denise or similar staff had a chance to look at it.
Not sure if the gain is worth the complexity, though.
no subject
Date: 2010-05-10 08:11 am (UTC)I would love that.
no subject
Date: 2010-05-10 10:52 am (UTC)That reminds me of rsync.net's warrant canary (and others like it).
no subject
Date: 2010-05-09 08:43 pm (UTC)An alternative could be something like you guys have talked about it terms of sharing TOS investigations; doing it the other way? "In May, x journals were looked at for a, b, and c reasons". Let people know how rare or common it is?
no subject
Date: 2010-05-09 11:44 pm (UTC)no subject
Date: 2010-05-11 03:21 pm (UTC)no subject
Date: 2010-05-09 08:53 pm (UTC)Maybe it would be useful to have a FAQ section or something about this, spelling out under what circumstances viewall gets used, who can use it, and emphasizing what DW does to protect privacy and ensure that the ability to access private/locked posts won't be abused.
no subject
Date: 2010-05-09 09:47 pm (UTC)no subject
Date: 2010-05-10 08:10 am (UTC)I think this would be a great thing for the FAQs.
no subject
Date: 2010-05-09 07:09 pm (UTC)no subject
Date: 2010-05-09 07:31 pm (UTC)Personally I try not to have locked content that is going to be damaging if it gets out because I heard the rumors about [other places] sending restricted-access content to advertisers for keyword mining.
no subject
Date: 2010-05-09 08:09 pm (UTC)But yes, I know what you mean, and I tend to stick to the same policy for my personal journal usage. :)
no subject
Date: 2010-05-09 07:33 pm (UTC)I think I'm trying to have a grateful party right now, but I'm lacking the words to properly express it. Really, truly, thank you.
no subject
Date: 2010-05-09 07:36 pm (UTC)Thank you for the explanation.
no subject
Date: 2010-05-09 07:53 pm (UTC)no subject
Date: 2010-05-09 08:11 pm (UTC)no subject
Date: 2010-05-09 08:30 pm (UTC)PGP Option?
Date: 2010-05-09 08:30 pm (UTC)It's quite possibly excessive, and not something I personally would necessarily use or care much about, just an idea that popped into my head if you wanted to offer something for those who are really paranoid or really have something they feel strongly that they need to keep confidential.
Re: PGP Option?
Date: 2010-05-09 09:45 pm (UTC)Having some sort of tag or something that we could say "hey, here's content that is PGP encoded, use the key labeled 'xb95'" and having the browser handle decrypting that particular block of text...
Of course, then I wonder if that's even possible to make secure. I could write some JS that just runs in the DOM and waits for that particular block to be decoded. But then, the plugin could do something more fancy -- or maybe we could just make this an option that shows up to RSS readers. Then it's just, "here's the content, you can do something with it".
Personally, the security conscious and paranoid part of me really likes the idea. Realistically, I don't know that it's a good fit for what we're trying to do with Dreamwidth. But hmm...
Re: PGP Option?
Date: 2010-05-09 11:55 pm (UTC)As long as it's clearly explained that this is no guarantee of privacy, it would be another useful tool.
Re: PGP Option?
Date: 2010-05-10 01:28 am (UTC)A minor gain probably not worth the complexity, but that sort of server-side encryption is becoming increasingly common in the storage world. (Although there the concern is often about backups, which are frequently sent off-site to unaffiliated storage companies who shouldn't be able to read the stuff they're storing.)
Re: PGP Option?
Date: 2010-05-10 06:21 pm (UTC)If the encryption is done browser-side with another plugin then Dreamwidth never touches the plaintext or the keys and the only thing that needs security auditing is the plugin. All DW has to do is provide a nice way of tagging the text. Or am I missing something?
no subject
Date: 2010-05-09 08:53 pm (UTC)no subject
Date: 2010-05-09 09:56 pm (UTC)no subject
Date: 2010-05-10 05:23 am (UTC)no subject
Date: 2010-05-10 06:36 am (UTC)no subject
Date: 2010-05-10 08:16 am (UTC)Again, thank you so much for this post!
no subject
Date: 2010-05-10 10:48 am (UTC)Again, thanks!
no subject
Date: 2010-05-10 11:51 am (UTC)no subject
Date: 2010-05-10 04:54 pm (UTC)no subject
Date: 2010-05-11 12:54 am (UTC)no subject
Date: 2010-06-30 12:34 pm (UTC)no subject
Date: 2010-09-05 05:56 pm (UTC)I'm so not used to being able to edit my commentsno subject
Date: 2010-09-18 02:28 am (UTC)Thank you for that.