Now, if you were to browse Facebook through a proxy that always tampered with this result in transit to say you were an employee... might some stray client-side code do anything interesting because it trusted that response?
That's cute but it's not accurate. I interviewed there over two years ago and I appear to be blacklisted, since whenever I look at any of their job descriptions I get this:
"Hey, we have reviewed your application and unfortunately don't have an opening for you."
That sounds like a bug - from what I'm told by a recruiter, you should be able to apply again by now. You can also start the process by emailing the address in the text at the bottom of job once you click on "Apply for this position".
If ever the online recruiting system gives you trouble but you think you ought to be able to apply, send your application to HR by email. (careers@fb.com should do it, I believe) And tell them about the bug too, so they can get it fixed.
Also, if you know somebody who works at Facebook, try to get them to refer you instead of applying directly. (Just email them your resume and ask if they can forward it.) This applies not just to Facebook but to most other big companies, especially popular employers that get a lot of resumes every week. Our recruiters try hard to evaluate all the resumes they receive, but if you guessed that they probably look more closely at ones that reach them by way of an internal referral, I think you guessed correctly.
I think this is_fb_employee variable is to check if they should be running the internal testing version of Facebook. Facebook has a subdomain which, in their offices everyone is redirected to. It's something like 'preview.facebook.com'. It houses the latest testing build of Facebook. This way all the employees are testing Facebook just by being on it, and they have other people testing their new builds for short periods of time (~2 weeks). Chances are, the server checks if the user is at an IP of a Facebook office, and that's the only condition where this is true. This would make sense because if they just redirect users to Facebook.com in their offices to preview.facebook.com, then nearly anyone could do it. This would also help prevent leaking of new features as well, because employees wouldn't be able to access them outside of Facebook.
Actually, we do know when you are on the Facebook corp network and can filter by that, but we rarely gate on that. We have a system we call gatekeeper for controlling the launch of new features. If I'm coding up something new I'll usually just add my own user ID (we call GUIs in Facebook FBIDs) first. The gatekeeper system is a very full featured roll-out system. I can launch to just employees, 1% of users world wide, Facebook users in Peru, viral growth mechanism, etc..
We also maintain a robust employee list that is cached in APC on every web host that you can always call an is_employee style function for any user ID on. The careers site in particular has some employee only functionality that this endpoint is probably checking.
Just a javascript script file that tests for where ip-wise the user originates from and determines if you use a proxy for the site or connect directly.
I don't understand. If they're proxying requests, what would this variable ever be used for? This is at an endpoint for a client or their javascript to consume (or just as a recruiting-marketing tool). That would be redundant if they're proxying requests and insanely silly if it's the only way (instead of proxying) that they flex new features on... as they'd be visible in the javascript and it would be trivial to spoof the response to be "yes".
I have no doubt that their internal employees or a subset of them are using a different build of Facebook, and maybe I'm missing something, but I don't understand how this is related.
"I looked into it more deeply and I found that apparently what happened is that yid was laid off five years ago and no one ever told him about it; but through some kind of glitch in the payroll department, he still gets a paycheck. So we just went ahead and fixed the glitch."
I think HN still tends to reward quick posts over more thoughtful ones. As humor is quicker to post, it will come to dominate (i.e. HN will become Reddit) without this important check/balance in the culture.
As far as value added to the conversation, the joke added more value than the sarcastic passive agressive response did. HN should be more concerned with monday morning quarterbacks than people who add a new facet to the discussion.
It's occasionally helpful to explain to people why they're being downvoted. Comments that consist of pop culture references usually aren't treated kindly.
If you get a 0 for your user ID, I have to imagine you are not logged in. I get a JSON object that shows "is_fb_employee" going to a literal false value.
No, they haven't; if you open it in a new tab the referrer goes (at least in Safari), so you get 'false' - just click on the link in the same window and you'll get 'maybe'.
It appears that this web service has a rather obvious defect, the Content-Type is set to "text/html; charset=utf-8" yet, the response body seems to be JSON rather than HTML. The proper Content-Type should be "application/json" with Content-Disposition to "inline". Perhaps they didn't do this since some browsers ignore the Content-Disposition with this Content-Type, and prompt to download the content regardless.
Even so, "text/html" is still wrong. Since the content actually isn't intended for a JSON parser, but, a human, "text/plain" would be the most conservative (and not wrong).
Not sure how much data facebook have of other websites for categorizing majority of the websites in to different domain, but i feel Google can do much better with the same concept.
JSONP is a way to consume a feed from a willing website on a different domain name. I say "willing" because the feed must be presented in JSONP -- there is no way for you to alter a JSON feed into a JSONP feed without using some sort of proxy.
Because you'd need to use a proxy on your domain to convert the feed to JSONP, you would then lose access to the client's cookies for the target domain. That basically means that no, you can't use a JSONP request to defeat the same-origin policy.
I hope there isn't a flash app on Facebook that is using just that to decide whether to show an employee/admin interface.. Will be quite easy to spoof the result of that page if it is client-side.
My own id is quite high, however... About a year ago I wrote a script to scrape Facebook users and their friendship information. I wanted to get the social graph of my university (Warwick), so I seeded it with me and a few random friends from the same school, and coded it expand nodes already well-connected to the network. It turns out that university students form a fairly tight international network, so my script starting scraping people from other universities, including some colleges in the US. Anyway, when I only had a few thousand users in the database, I noticed there was one with FBID 7 - Mark Zuckerberg's old roommate. Pretty cool how few hops were needed to get to him (and shows how FB managed to grow so quickly amongst the uni market).
I'm < 50,000 ... I have old screen shots of thefacebook.com too somewhere. In fact, I have an outstanding friend request from the early days that I've never clicked on, just for fun. I think this was either 2004 or 2003.
I imagine there would be some utility in knowing whether FB employees use your site/app. Though there'd be some complex cross-domain issues to solve first.
Hm, I think you can still invoke it jsonp style and overload the Object constructor in older browsers though, right? This would not only tell you whether they were a FB employee, but perhaps more importantly, their facebook UID without needing them to agree to any OAuth access.
