
Conversations About The Internet #5: Anonymous Facebook Employee - blasdel
http://therumpus.net/2010/01/conversations-about-the-internet-5-anonymous-facebook-employee/?full=yes
======
thejo
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.

~~~
pyre
> _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).

~~~
thejo
> How about supporting public key encryption for SMS?

The protocol in its current widely deployed form does not support it.

------
potatolicious
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.

~~~
tjic
She's not a woman - "her" word choice was totally male.

That detail is just a really poor attempt at anonymization, IMO.

~~~
nostrademons
How do you know that the responses aren't all paraphrased?

------
larsberg
"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 :-)

~~~
CalmQuiet
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? )

~~~
synnik
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.

------
charliepark
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?

~~~
euroclydon
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?

~~~
charliepark
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.)

~~~
ehsanul
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.

~~~
charliepark
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.

------
bmalicoat
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.

~~~
rudd
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!

------
ntoshev
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.

~~~
loup-vaillant
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.

~~~
ntoshev
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.

~~~
loup-vaillant
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.

------
fjabre
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.

------
seldo
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.

~~~
gaius
_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.

------
robryan
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.

------
motters
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.

------
mattmanser
_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 ;)

