Facebook monitors your alert() usage

If you use a bookmarklet on Facebook and it calls window.alert(), it doesn't quite do what you expect. They've re-defined the entire alert() method – it will pop up a box, but it will also behind the scenes send what you tried to pop up to the server!?! Look at Facebook's alert code (shown in an appropriate setting, of course):

Since I routinely use alert() for debugging, should I be paranoid now?
I really wonder what this feature is intended for and whether they actually harvest this data and use it for anything.

Advertisements

24 thoughts on “Facebook monitors your alert() usage

  1. I would guess that they are trying to phase out using normal JS alerts for usability reasons, so they want to track how often they still occur in their legacy code in the real world.

  2. Originally posted by hallvors:

    Since I routinely use alert() for debugging, should I be paranoid now?

    You could use dragonfly, no? It has a command-line like firefbug. Any reason you don't use that?

  3. Jeff writes:If you're writing a bookmarklet, just do:delete window.alert;This will remove their implementation and you are free to call alert() as before without them capturing it.

  4. Anonymous writes:question to you the inventor of this "phisher" or whichever your small brain conjures up,..is how far do you want to take this..with our tools we can trace your location easily..and neutralize your stupidity…which way do you want to take this..think….G.GRP300

  5. Garry Tan writes:The biggest problem Facebook faces is malicious and spammy apps that degrade the service. JS is a huge attack vector for spammy sites. It makes sense that they would a) allow alerts but b) monitor.Trust but verify, as Reagan used to say.

  6. Originally posted by fearphage:

    You could use dragonfly, no?

    Well, I did use Dragonfly until the weird thing I was debugging claimed to run out of memory and stopped connecting to it :-pEven though Dragonfly is quite sweet by now, window.alert() boots up a bit faster, don't you think? For some small debug tasks it's still a good tool 😉

  7. Anonymous writes:Alert() is a lousy way to debug, since it changes page focus– it'll fire off blur handlers.

  8. Anonim writes:if DF was like firebug – ie. always active and NO reload of pages, then alerts would be obsolete..but well, it isnt. when it will behave like firebug?

  9. Anonymous writes:no. i hate windows alert. It gives you that annoying system bell designed to tell you that you are using the computer like a retard.

  10. Originally posted by anonymous:

    i hate windows alert. It gives you that annoying system bell

    Change your browser.. or sound settings :)As always: choose the right tool for the job. Dragonfly or Firebug or window.alert().

  11. Anonymous writes:this is probably to catch XSS holes early. one of the first thing many XSS crackers test with is an alert() – it tells them right away if they've found a place they can execute javascript. then they can continue on with their actual maliciousness. of course this would only catch the most unsophisticated ones, but that would certainly be useful.

  12. Nicholas C. Zakas writes:I think the purpose of this Facebook code is pretty clear. It has nothing to do with stopping your bookmarklets from working. This makes it painfully obvious that Facebook developers tend to use alert() in their debugging. I'm sure that in their development environment, these are popping up everywhere. My suspicion is that this code is inserted when the site is pushed live to ensure that no ugly alerts get displayed to the user. Instead, they're logging the debug information back to their servers so they can track any issues in production. It's a bit of a sideways attempt at the JavaScript error logging process that I typically recommend, but it does kill two birds with one stone.

  13. Jeff Walden writes:I can confirm this is an XSS detection technique. When I was actively working at finding exploits of Facebook's application platform (see http://stuff.mit.edu/iap/2008/facebook/ for details) one of the first ones I found got me a PM from one of their security team people encouraging me to look for any further exploits I could find. It took me a little time to figure out this was how they were doing it (I was also sending them to some @facebook.com address, so it wasn't clear whether they were getting them in that manner or not), but it was pretty cool when it became clear what they were doing. I've seen this basic trick documented a few different places since then, and I imagine it's a fairly common thing to do these days on most security-conscious websites.

  14. FBJS isn't well specified, features _and_ (API) restrictions, but window.alert() is known to be flagged as unavailable.Perhaps this is a last-line-of-defense for the alert() usages that FBJS doesn't manage to rewrite/elide from script sources? FB platform devs will hopefully shed some (real) light on why.

  15. Anonymous writes:Hmm… apparently the Opera Blog has the same bug as the Opera Forum (DSK-258593). Here is my posting again, with some work-around spaces.Sneaky.Here's a bit of User JS to prevent alert() from being modified, and to report modification attempts. It can be circumvented, though, if the site really wants to.(function() { var orgAlert = alert; // Save the original 'alert' before any script has been able to // alter it. window.__defineSetter__( "alert", function(val) { var trace; // Throwing and catching an error so that we have a stack trace. try { throw new Error("Attempt to modify alertn"); } catch (e) { opera.postError(e); orgAlert(e); }; }); window.__defineGetter__( "alert", function() { return orgAlert; });})();Strangely enough, this has the side effect that when you enter javascript:alert('foo') in the URL bar, a "type mismatch" error is raised, but if you enter javascript:var a = alert; a('foo') , it works. That sounds like a bug in Opera.

  16. SvdB writes:Sneaky.Here's a bit of User JS to prevent alert() from being modified, and to report modification attempts. It can be circumvented, though, if the site really wants to.(function() { var orgAlert = alert; // Save the original 'alert' before any script has been able to // alter it. window.__defineSetter__("alert", function(val) { var trace; // Throwing and catching an error so that we have a stack trace. try { throw new Error("Attempt to modify alertn"); } catch (e) { opera.postError(e); orgAlert(e); }; }); window.__defineGetter__("alert", function() { return orgAlert; });})();Strangely enough, this has the side effect that when you enter javascript:alert('foo') in the URL bar, a "type mismatch" error is raised, but if you enter javascript:var a = alert; a('foo') , it works. That sounds like a bug in Opera.

  17. Hallvord, please contact an admin or other person with access to the database. For some reason, the markup on this page got chumped up.I'm thinking SQL injection, or something similar must've occured here. Since the "new post" I was informed about has been removed, maybe you're already aware of the situation.

  18. Originally posted by _Grey_:

    Hallvord, please contact an admin or other person with access to the database. For some reason, the markup on this page got chumped up

    hmm this page is loading fine here in Opera 10.60, emptying the cache might help a bit

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s