Conversations About The Internet #5: Anonymous Facebook Employee(therumpus.net)
therumpus.net
Conversations About The Internet #5: Anonymous Facebook Employee
http://therumpus.net/2010/01/conversations-about-the-internet-5-anonymous-facebook-employee/?full=yes
11 comments
> Unfortunately, there is no way to secure it end to end in its current form
How about supporting public key encryption for SMS?
Oh sorry, I forgot that the government wouldn't like that too much. Everything should be out in the open so that everyone can view it to make it easier for law enforcement (at the same time making it easier for criminals to access the information of 'normal/average' people).
How about supporting public key encryption for SMS?
Oh sorry, I forgot that the government wouldn't like that too much. Everything should be out in the open so that everyone can view it to make it easier for law enforcement (at the same time making it easier for criminals to access the information of 'normal/average' people).
> How about supporting public key encryption for SMS?
The protocol in its current widely deployed form does not support it.
The protocol in its current widely deployed form does not support it.
The Facebook employee:
- checked a guest named "Phil Wong" into the new Facebook office in the recent past (after the move)
- is a woman
Holy shit guys, "anonymity"? Protecting her job? I think not.
- checked a guest named "Phil Wong" into the new Facebook office in the recent past (after the move)
- is a woman
Holy shit guys, "anonymity"? Protecting her job? I think not.
She's not a woman - "her" word choice was totally male.
That detail is just a really poor attempt at anonymization, IMO.
That detail is just a really poor attempt at anonymization, IMO.
How do you know that the responses aren't all paraphrased?
The diction struck me as quite masculine, as well.
I think it's supposed to be anonymous to GoogleBot + 4chan, not to Facebook. Pretty much every tidbit that isn't normally in FB press releases would be an identifying detail, even the sentence structure.
Who's to say 'she' isn't a composite or fabricated anyway?
Who's to say 'she' isn't a composite or fabricated anyway?
"I think it's supposed to be anonymous to GoogleBot + 4chan, not to Facebook."
I would hope it's supposed to be anonymous to Facebook - after all, there were some fairly frank discussions on topics that aren't exactly public knowledge (e.g., Facebook tracking clicks and other little bits of things that really should be revealed by PR, not an employee in an unsanctioned conversation).
"Who's to say 'she' isn't a composite or fabricated anyway?"
Well, in that case the author never visited Facebook's offices - that's the detail that gives away the employee's identity. Given the level of detail gone into by the author, I doubt this is fabricated.
It would probably be better for everyone if it were, though, because he just made a real big boo-boo that will probably cost someone their job.
I would hope it's supposed to be anonymous to Facebook - after all, there were some fairly frank discussions on topics that aren't exactly public knowledge (e.g., Facebook tracking clicks and other little bits of things that really should be revealed by PR, not an employee in an unsanctioned conversation).
"Who's to say 'she' isn't a composite or fabricated anyway?"
Well, in that case the author never visited Facebook's offices - that's the detail that gives away the employee's identity. Given the level of detail gone into by the author, I doubt this is fabricated.
It would probably be better for everyone if it were, though, because he just made a real big boo-boo that will probably cost someone their job.
If not the interviewees. I was reading this and thinking "holy crap this is a meaty interview" while simultaneously thinking "there's no way Mark won't find this girl and gut her."
Maybe not because the information she gave was all that important (although the HPHP thing certainly is an interesting piece of information), but to make an example to other employees about babbling on about the internal workings of their enterprise.
Chief Privacy Officer Chris Kelly might be paying her a visit shortly.
Maybe not because the information she gave was all that important (although the HPHP thing certainly is an interesting piece of information), but to make an example to other employees about babbling on about the internal workings of their enterprise.
Chief Privacy Officer Chris Kelly might be paying her a visit shortly.
> although the HPHP thing certainly is an interesting piece of information
Except that the employees description of the differences between "scripted" and compiled languages leads me to think that this person doesn't really know much about programming languages.
Except that the employees description of the differences between "scripted" and compiled languages leads me to think that this person doesn't really know much about programming languages.
Sounds like he/she was really just trying to dumb it down for the interviewer, someone who didn't understand what "eyeball-tracking" was or thought that Facebook's servers were hosted in their offices.
I was thinking the same thing.
I get the feeling the PHP is probably compiled into some C or C++ format. The speed increase would work wonders for the production server, and if you didn't change HPHP too much from regular PHP, you could still run interpreted for development.
For scaling, I wouldn't be surprised if we started seeing hybrid models like this in the future.
I get the feeling the PHP is probably compiled into some C or C++ format. The speed increase would work wonders for the production server, and if you didn't change HPHP too much from regular PHP, you could still run interpreted for development.
For scaling, I wouldn't be surprised if we started seeing hybrid models like this in the future.
Wellll.... I don't know if it's meaty at all. Nothing in there actually is revealing: yeah, they do eye-tracking. So does every serious outfit. They store all the data they create: yes, it's nearly free to do that (relatively speaking), and I'd be surprised if they didn't do it (nearly all graph algorithms they should employ will benefit from more data to train/test); they're creating Hyper-PHP--great etc, but you'd really think twice before creating your own site on PHP, so it's a non-issue for me at least.
Bonus: I'm also certain they have their own front-end engineering which is speeding up javascript. Nearly everyone else does, and getting that 0.5s page-load will certainly need this boost.
Bonus: I'm also certain they have their own front-end engineering which is speeding up javascript. Nearly everyone else does, and getting that 0.5s page-load will certainly need this boost.
"I don’t think there’s any question that Stanford is the number one CS department in the world."
Whomever it is certainly is a Stanford graduate :-)
Whomever it is certainly is a Stanford graduate :-)
"Employee: We’re going to reduce our CPU usage on our servers by 80%, so practically, users will just see this as a faster site. Pages will load in one fifth of the time that they used to."
With gems like that, one can't help but deduce that, if anonymous employee IS a Stanford grad, Stanford is the best CS department in the world. I mean, they seem to have invented the zero-latency, infinite bandwidth internet, where all network operations are CPU bound!
The average Stanford Kid is about the same as the average MIT kid is about the same as the average CMU kid. The most brilliant Ohio State kid is likely about as smart as the most brilliant MIT kid.
[Edited to be less snarky :)]
With gems like that, one can't help but deduce that, if anonymous employee IS a Stanford grad, Stanford is the best CS department in the world. I mean, they seem to have invented the zero-latency, infinite bandwidth internet, where all network operations are CPU bound!
The average Stanford Kid is about the same as the average MIT kid is about the same as the average CMU kid. The most brilliant Ohio State kid is likely about as smart as the most brilliant MIT kid.
[Edited to be less snarky :)]
I'd agree with that completely.
My roommate recently interviewed with Facebook(we attend a state school in the midwest). The other candidates were going around saying where they were from, many were from Stanford, and when it came to him they basically snubbed him afterwards.
That said in programming competitions we've beaten schools like UIUC.
My roommate recently interviewed with Facebook(we attend a state school in the midwest). The other candidates were going around saying where they were from, many were from Stanford, and when it came to him they basically snubbed him afterwards.
That said in programming competitions we've beaten schools like UIUC.
If a graduate at all. Consider:
"PHP is an example of a scripted language. The computer or browser reads the program like a script,..."
Hard to remember the last time my browser was reading a server-side script. ( or was it just "all those beers" they were drinking? )
"PHP is an example of a scripted language. The computer or browser reads the program like a script,..."
Hard to remember the last time my browser was reading a server-side script. ( or was it just "all those beers" they were drinking? )
Their statement is logically correct..
After all, the server is a computer, so you can replace 'computer' with server. Which makes the first evaluation true, and the word 'browser' is never evaluated, or at least irrelevant. You could even say that either the server or my pet ferret reads the program like a script...
But seriously... the guy/girl was talking generically about scripting, not specific to server-side web scripts. So the statement is accurate.
After all, the server is a computer, so you can replace 'computer' with server. Which makes the first evaluation true, and the word 'browser' is never evaluated, or at least irrelevant. You could even say that either the server or my pet ferret reads the program like a script...
But seriously... the guy/girl was talking generically about scripting, not specific to server-side web scripts. So the statement is accurate.
Also consider that the speaker was talking to a computer layperson. Depending on what "level" you are speaking at, it may behoove you to simplify things and remove terminology like "server" or "client" from what you're saying. She may just have been toning things down a little.
That was my precise first thought. But he's really talking of a scripting language in general: think Javascript (browser)or Perl (computer).
Since the discussion before this line was about PHP, I think it tends to trip you up.
Since the discussion before this line was about PHP, I think it tends to trip you up.
They mention having a "global" password that allows access to any user account. I've thought about doing this in the past, as a means of troubleshooting user support requests, but haven't implemented it on any sites.
Are there better ways of doing this, rather than having a global admin backdoor password? Is there a recommended "best practice" for logging in as a user, to see what they see when they use the app? I get a decent number of support requests where the user is seeing something in particular, and my being able to see it would be useful. At the same time, there's a pretty serious risk that's opened up by having this in place.
Anyone have any thoughts / suggestions?
Are there better ways of doing this, rather than having a global admin backdoor password? Is there a recommended "best practice" for logging in as a user, to see what they see when they use the app? I get a decent number of support requests where the user is seeing something in particular, and my being able to see it would be useful. At the same time, there's a pretty serious risk that's opened up by having this in place.
Anyone have any thoughts / suggestions?
I think defending against internal abuse is always an uphill task. The key thing is to have auditability - store records of who accessed what and when and make sure those records can't be tampered with. The knowledge that that data is being generated acts as a major deterrent (apart from being a forensic tool)
Seems to me the best way to implement the "login-as" feature is to make it possible for an admin account with sufficient privileges to just enter the name of any user to start a "nested session" from their admin account (password of the user you're logging in as not required) where they see everything the real user would see but the logging somehow remembers that this is a nested session.
So you could differentiate between RandomGuy actually logging in, Hexstream logging in as RandomGuy and MetaNull logging as RandomGuy. No need to fuck with passwords, guys!
So you could differentiate between RandomGuy actually logging in, Hexstream logging in as RandomGuy and MetaNull logging as RandomGuy. No need to fuck with passwords, guys!
I have a "login as this user" link in my admin panel. Once I click it, I see what they see. The only downside is that I have to log out and log back in to get back to my admin account, but I usually keep myself logged in in firefox and do the testing in IE, so this isn't that big of a deal.
This might be horrible idea from a security perspective, and if it is, please tell me, but what about allowing the hashed password in the password field, that way, you could copy it from the db, and sign in?
That seems like a really good way to handle it. Each account has a unique password, then, and it's only available to the admin. As long as the controller's coded well, this seems like a great solution. (If anyone has any concerns, I'd love to hear them.)
There's a security issue with this idea obviously. If I'm not mistaken, the whole point of hashing passwords is so that a loss of the user database in some way does not compromise any accounts. You might as well store passwords in plain text if you allow hashed passwords as passwords.
It might just be acceptable though, since almost nobody would guess that a hashed password would be accepted as a password. That is, unless they have access to the controller source code too, and check it out (as you'd assume since the database itself has been compromised).
A better solution may be to create a second temporary password, hashed in another field in the database, and wipe it out when you're done.
It's fine to use an extremely long master password too, making sure it's stored as a bcrypt hash or something. Just run the calculations to make sure that it couldn't be broken in 2^999 years.
It might just be acceptable though, since almost nobody would guess that a hashed password would be accepted as a password. That is, unless they have access to the controller source code too, and check it out (as you'd assume since the database itself has been compromised).
A better solution may be to create a second temporary password, hashed in another field in the database, and wipe it out when you're done.
It's fine to use an extremely long master password too, making sure it's stored as a bcrypt hash or something. Just run the calculations to make sure that it couldn't be broken in 2^999 years.
Hrm. You're right. Secondary benefit of the hashing is so that a user's re-used password isn't compromised for other sites, but ... yeah.
Your dynamically-generated temporary password is probably a better way to go about it. Or the hashed master password.
Thanks.
Your dynamically-generated temporary password is probably a better way to go about it. Or the hashed master password.
Thanks.
Well, it doesn't sound bad, until you rephrase it to how it will actually be implemented:
How about allowing the contents of the hash column in the database as the password?
It only takes one incompetent engineer to sometimes store the raw password in the database, and it takes two to make that work to log in somewhere (presumably an easy defense is to only allow "verbatim logins" using something the same length as a hash).
How about allowing the contents of the hash column in the database as the password?
It only takes one incompetent engineer to sometimes store the raw password in the database, and it takes two to make that work to log in somewhere (presumably an easy defense is to only allow "verbatim logins" using something the same length as a hash).
Also it would defeat the purpose of having passwords hashed, because a data leak would then expose people's account just as if you were storing the plaintext password.
At the one place I worked where this was actually implemented (spoof a user by entering a hashed password), it only worked from inside the firewall, to mitigate this risk. According to the interview, Facebook has similar restrictions on user spoofing.
[deleted]
[deleted]
It's probably just because I don't go to Stanford or Harvard, but I think it's silly and diversity-lacking to have almost all your hires come from those two schools. Good CS students can come from elsewhere, though they are probably a bit harder to sift out.
It may be unfair to candidates trying to get a job at Facebook if they didn't come from Stanford or Harvard, but it's completely reasonable to focus their hiring efforts on those two schools. It makes it less work for them.
As a plus for non-Stanford/Harvard grads, it means if you don't want to work for Facebook, you have less competition from Stanford/Harvard grads!
As a plus for non-Stanford/Harvard grads, it means if you don't want to work for Facebook, you have less competition from Stanford/Harvard grads!
It only takes about 25% of a company to come from one place for it to seem like "everyone" comes from there, especially if any other individual school is no more than a few percent.
The facts that Facebook saves and keeps all interaction and user generated data and their engineers can access that data should be nothing new to you: Google, Amazon and every sane internet company do it too because they want to make decisions based on data.
The author clearly doesn't understand what he is talking about and doesn't try too hard to understand it; he wants to be sensational instead. Oh well.
The author clearly doesn't understand what he is talking about and doesn't try too hard to understand it; he wants to be sensational instead. Oh well.
They don't need the raw data to make decision. Statistics are enough (and even better, most of the time).
Keeping information that almost anyone would think of as private (search history for Google, list of purchased goods for Amazon) is insane. Literally. This kind of data can sort people by political opinion and sexual preferences, for one thing. This kind of data has already been used to spot or incriminate dissent. At the scale of these companies, this can go very wrong.
How they are using this data right now isn't relevant. The fact that every big internet company is doing it doesn't make it acceptable. The fact that no one bother doesn't make it normal.
The risks are just too high.
Keeping information that almost anyone would think of as private (search history for Google, list of purchased goods for Amazon) is insane. Literally. This kind of data can sort people by political opinion and sexual preferences, for one thing. This kind of data has already been used to spot or incriminate dissent. At the scale of these companies, this can go very wrong.
How they are using this data right now isn't relevant. The fact that every big internet company is doing it doesn't make it acceptable. The fact that no one bother doesn't make it normal.
The risks are just too high.
You need the raw data in order to be able to calculate statistics in the future about relations you don't anticipate now. Also keeping only aggregated numbers would mean you give up on data mining.
I don't know if this use of data is "insane", but companies doing it get a clear competitive advantage over the rest. If governments decide to restrict it with some kind of regulation, there would be a clear cost in a less efficient economy. People are willing to give up privacy in order to gain convenience, otherwise they wouldn't be using these services. All these factors say we are going to see more data gathering in the future.
I don't know if this use of data is "insane", but companies doing it get a clear competitive advantage over the rest. If governments decide to restrict it with some kind of regulation, there would be a clear cost in a less efficient economy. People are willing to give up privacy in order to gain convenience, otherwise they wouldn't be using these services. All these factors say we are going to see more data gathering in the future.
The advantages you speak of seems stronger than what I was thinking about. But I still think the current trade off is too dangerous.
Plus, I disagre about people willingly giving up privacy. I think most of them either undervalue their privacy or don't know they are giving it up.
Plus, I disagre about people willingly giving up privacy. I think most of them either undervalue their privacy or don't know they are giving it up.
Everything in here sounds believable and I have no doubt that things like that have happened and do continue to happen at FB.. My only problem with this interview is that it seems very scripted..
Either this person had the questions in advance, the interview is an elaborate hoax, or she just happens to be really articulate and alert after a few beers.
Either this person had the questions in advance, the interview is an elaborate hoax, or she just happens to be really articulate and alert after a few beers.
I am completely shocked by "her" casual admission that Facebook employees have in the past logged in as other users on a whim, and potentially continue to do so via database access and user-switching.
In some countries -- for instance the UK -- data protection laws mean that viewing personal data without a specific business reason is itself illegal, even if that data is not manipulated (this may be why the new user switching system requires a reason to be entered). Even if this casual viewing was done before they opened a data center in the UK, this seems a pretty shocking admission to make so casually.
In some countries -- for instance the UK -- data protection laws mean that viewing personal data without a specific business reason is itself illegal, even if that data is not manipulated (this may be why the new user switching system requires a reason to be entered). Even if this casual viewing was done before they opened a data center in the UK, this seems a pretty shocking admission to make so casually.
I am completely shocked by "her" casual admission that Facebook employees have in the past logged in as other users on a whim
I doubt there's any company that has user data that this doesn't happen at. I bet it happened a hundred years ago at mail order companies. A claim that it had never happened somewhere would be suspicious.
I doubt there's any company that has user data that this doesn't happen at. I bet it happened a hundred years ago at mail order companies. A claim that it had never happened somewhere would be suspicious.
That used to be on their job postings. "Get inside information about your friends! See all their private details!" (or something similar)
I think their foster mother has tried to make them grow up a little.
I think their foster mother has tried to make them grow up a little.
It makes a lot of sense for a site of facebook's size to do away with most of the dynamic language coded stuff on the backend.
In terms of identity, this is facebook, I'm sure they could work out what employee it was (if it was an employee) without the office visit details.
In terms of identity, this is facebook, I'm sure they could work out what employee it was (if it was an employee) without the office visit details.
I'm somewhat disquieted by these admissions, and I think that eventually there are going to be some social networking privacy scandals. Ultimately the solution is probably a peer-to-peer equivalent to facebook.
For example, this guy right now is single-handedly rewriting, essentially, the entire site.
Well, at least we know the end of facebook is coming then ;)
Well, at least we know the end of facebook is coming then ;)
For example, if you receive SMS alerts from your bank about transactions, account balance etc. there are multiple engineers in the chain who have access to the information, but should not -
* At the SMS gateway company to which the bank has outsourced the services
* Your mobile service provider
* People who run the SMSC (if the mobile operator has outsourced that)
Unfortunately, there is no way to secure it end to end in its current form. The same is applicable to a lot of services.