Not sure how they are doing this, but I have gotten tired of having to play “whack-a-mole” with FB scraping private information from my browser in other ways, so what I have done is sandboxed it: I have a separate “Facebook” account on OS X, and I assume that anything I do on that account is shared with Facebook.<p>I don’t log into Facebook for any reason on my normal user account, and I don’t log into anything else on my Facebook account. They can still sniff certain things using browser fingerprinting and so on, but this seems like the best I can do for the moment on my desktop.
It's not very hard to do. The trick is to know a resource that only the user can access and then trigger an HTTP request to it.<p>For instance if you have website a and say the user profile "mitsuhiko" can only be edited when you are logged in as "mitsuhiko" on <a href="http://a.example.com/profile/edit/mitsuhiko" rel="nofollow">http://a.example.com/profile/edit/mitsuhiko</a> you could use this code to see if the logged in user is "mitsuhiko":<p><pre><code> <script type="text/javascript" src="http://a.example.com/profile/edit/mitsuhiko"
onload="user_is_logged_in()" onerror="user_is_logged_out()" async="async"></script>
</code></pre>
Why does this work? Because onload is fired if the resource answers with 200 OK, not if it's a valid script. onerror is called for any other error code.<p>So if you know what you are probing for: easy.<p>// Edit: Yes, this is most likely not what Facebook is doing if that's their only method of security. However see my reply to the first comment here about the security aspect for a possible way to solve this problem.
When I tried the same thing, it popped up a OpenID dialog the first time, and I confirmed it by seeing facebook.com on <a href="https://accounts.google.com/b/0/IssuedAuthSubTokens" rel="nofollow">https://accounts.google.com/b/0/IssuedAuthSubTokens</a> Revoking the facebook token causes Facebook to prompt again.<p>Subsequent attempts make the auth dialog flash briefly without displaying any content and still present the "You can change your password immediately because you are logged into your email account on this browser" message.
That's pretty neat, I wish they'd publish on how they did this so others could use it. Sounds like another great way to remove friction for the user, always a great thing.
It must be using oAuth. I think it was a mistake in the oAuth protocol to not build in a default, short, expiration for secret keys. Now users (most of them non-tech savvy) have to rely on visiting the apps page and manually removing authorizations.<p>Edit: I just profiled the process, and it is using OpenID. It pops open a new window that will check your OpenID login and call back with a success and will close the window if it is. I had to slow down my connection to actually see it.
I think they should have used that information differently. Given they know that you are already logged into your gmail, any visitor to your machine will therefore know how to reset the password to his advantage.<p>Instead, they should have make a block, so that you are forced to logout of your gmail and login to your gmail to enhance security.
Question...has anyone noticed if this relationship is reciprocal? I keep an eye on my Gmail ads to see how far along they track my activity while I am logged in and browsing, but has anyone noticed Gmail ads showing content that wouldn't be there without placement or data from Facebook? Obviously this doesn't apply if you sandbox Facebook as some commenters have, but if you use both in one browser I mean. I may use Firebug and see if the two communicate while I'm logged in...
I bought <a href="http://fluidapp.com/" rel="nofollow">http://fluidapp.com/</a> just for Facebook.<p>Now I have a nice separate window for browsing Facebook and nothing but Facebook.<p>Separate cookie store is awesome.