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.
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.
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 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."
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.
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.
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.
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.
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).
to see who is user x all you have to do is graph.facebook.com/x.1,2,3 are not active for some reason(anyone knows why??) but the rest from 4 to 10 are
4:Mark Zuck
5:Chris Hughes
6:Dustin Muskovitz
7:Arie Hasit
8,9 Dont Work
10:Marcel Laverdet
11:Soleio Cuervo
12 Doesnt Work
13 Chris Putnam (wtf?...i thought he joined facebook much later..hmmm interesting!)
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.
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?
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.
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.
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.
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'.
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.
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.
112 comments
[ 3.2 ms ] story [ 169 ms ] threadIf you check this and it says yes, you'd better hurry up and go to work!
In short: FB employees get to see the new features first, and are encouraged to submit bug reports.
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.
Now, seriously talking. A joke doesn't hurt a discussion. Laugh and move on. Or even better, keep making jokes.
Sorry yid.
No facebook account here. Do I win?
Here's the full history of how FB UID's have been assigned over time: http://www.quora.com/What-is-the-history-of-Facebooks-user-I...
homepage screenshot: http://bit.ly/q5P4kQ
Assuming similar adoption rates at the 4 other "second wave" schools, I'm probably one of the first 5-10k users of Facebook.
100k = Columbia 200k = Stanford 300k = Yale 500k = Dartmouth 600k = Penn 1000k = Brown
You can keep plugging away IDs into http://facebook.com/profile.php?id=[id]
How many people here realize they are outing themselves by posting the whole number?
4:Mark Zuck 5:Chris Hughes 6:Dustin Muskovitz 7:Arie Hasit 8,9 Dont Work 10:Marcel Laverdet 11:Soleio Cuervo 12 Doesnt Work 13 Chris Putnam (wtf?...i thought he joined facebook much later..hmmm interesting!)
anyone care to finish up to 20!!
"Hey Mark, am I a facebook employee?"
"Not any more!"
They mention this in the Facebook Effect (http://www.amazon.com/Facebook-Effect-Inside-Company-Connect...). Or, at least the part about an subdomain for testing their website in-house. Everything else was me analyzing that.
http://en.wikipedia.org/wiki/Proxy_auto-config
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.
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.
{"is_fb_employee":"maybe soon? https://www.facebook.com/careers/department.php?dept=enginee...}
EDIT: Oh, I did put my profession. Stupid me.
Maybe soon ... Engineering department .. I HOPE SO!
..im actually an engineer
I mean, I already assumed FB had a staging server. Why does this interest people so much?
"Hey, we have reviewed your application and unfortunately don't have an opening for you."
I can't really square that with "Maybe soon?"
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.
If I open a new window and copy/pasta the URL, it'll say false :)
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).
Even if you are logged out.
I am not an facebook employee so if i just paste the url in address bar and enter it, it shows: is_fb_employee: false with my UID.
If i logged out, it shows UID: 0 with is_fb_employee: false.
It's a nice idea to attract ppl from different site and based on the site domain, give them relevant career page url. (May be an intern project)
So for HN, it's engineering career page, if the referral site is relevant to some other domain (i.e. sales/marketing) then they will give http://www.facebook.com/careers/department.php?dept=sales.
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.