Many SaaS products, especially enterprise software, have a "login as a different user" feature that engineers use for debugging. It's good that non tech savvy users aren't always aware of the amount of information leakage that happens in situations where privacy is important. It would lead to a mega freak out.
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.
> 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).
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?
"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.
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.
> 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.
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 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.
"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.
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.
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.
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.
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!
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.
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).
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.
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!
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.
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.
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.
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.
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.
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'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, 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.