It's always important to know for developers what browsers they are developing for, who dominates the market, and what the current trends are.

I have gotten my hands on the Plaxo.com visitors' browser stats for December of 2009.

This information is valuable because Plaxo has a relatively general demographics, as it's not a site only geeks or only moms visit, and the statistics tends to not be skewed. Therefore, as you can see, Firefox doesn't occupy the same share as you might see on a techy site (on this site, more than 50% of users visit in Firefox).

Also, since Plaxo has a couple million monthly visitors and therefore a couple million data points, statistically speaking these numbers are relatively accurate.

Without further ado, here is the data, with some spiffy charts.

Overall Browser Breakdown For December 2009

Internet Explorer Version Breakdown For December 2009

Some numbers here have a value of 0.00% which means they've been rounded down and have really low numbers. The order is still correct though.

Firefox Version Breakdown For December 2009

Thoughts

• Internet Explorer is doing remarkably well – it is still most definitely the primary browser, so testing it should be planned accordingly.
• Internet Explorer 7 is by far the most popular version with 65.9% of all IE versions, followed by IE6 at 17.2% (wtf??), and only then IE8 at 16.9%. This definitely came as a surprise to me – both in how popular IE7 still is and how pathetic Microsoft's efforts to upgrade Windows users up from IE6 have been.
• Safari and Chrome are neck and neck at 6.20% and 4.6% respectively, with Chrome gaining rapidly.
• Opera is doing undeservedly badly – 0.6%. That makes me sad.
• IE 999.1? Interesting. I wonder if it's some sort of an uber hacked version.
• And, instead of conclusion: damn you, IE6! Why can't you die already?

• Firefox Being Slow, Especially Switching Tabs, High CPU Load, Memory Problems? Are You Using Firecookie For Firebug?
• Meet Firefox For Mobile [Video + Feature Highlights + More Info]
• Modern-Day Frame Busting With X-FRAME-OPTIONS And "This content cannot be displayed in a frame" Warnings
• Converting from CVS to SVN: Developer's Notes And Why SVN Is Better
• How To Make Firebug's JavaScript Debugger Break Inside Dynamic JavaScript Using The 'debugger' Keyword (IE & Chrome Too)

Here's where Firebug comes in with its JavaScript debugger. I'm used to using a debugger in every language I deal with, so using Firebug is a no brainer. Since it supports breakpoints, stopping execution and inspecting local variables and the rest of the scope generally beats alerts and console.logs for me.

Here's what a typical breakpoint looks like in Firebug:

It's easy to set breakpoints in static scripts – just open the Scripts tab, select a JavaScript file from the dropdown menu, and click to the left of the wanted line number.

Then, when the page is reloaded, if your breakpoints are triggered, Firebug will pause script execution and transfer the control to you.

In most cases, the method above is the only method of setting breakpoints you will ever need to use.

The Problem With Dynamic JavaScript

However, what if the JavaScript file where you need to set breakpoints is not static but instead dynamic (generated on the fly). If you set a breakpoint in this case and reload the page, the breakpoint will most likely disappear, especially if the JavaScript url is generated uniquely every time.

The Solution

If you have access to the source, the solution comes in the form of the

debugger;

keyword. Just add it to your dynamic JavaScript generator or into any JavaScript file you have access to exactly where you want Firebug to break, and voila – it does.

More so, this method also works in Google Chrome and IE (if you have Microsoft Script Debugger). Here is a screenshot of my Chrome Beta 4.0.266.0 triggering:

I consider this feature relatively unpublished and therefore awesome because:

• it's hard to search for this specific meaning of the keyword "debugger" when Firebug itself is a debugger and it's a very popular word
• nobody really reads documentation for Firebug, and even if they do, I haven't actually seen the debugger keyword mentioned
• I didn't know about it until recently, even though I've been using Firebug for years

Of course, you need access to the code for this to work, so it's not going to work if you're trying to debug someone else's JavaScript.

And finally, don't forget to remove any traces of 'debugger' from your code when you go live or your users will rightfully hunt you down.

Credits And References:

• suggested by a co-worker from Plaxo – Russ. Thanks Russ!
• some more interesting info at StackOverflow and Infragistics.

Happy debugging!

(*) – if your project works 100% on the first pass, you must be either a magician or Jon Skeet (Jon Skeet Facts – a-la Chuck Norris, a must read).

• [WordPress Plugin Development] How To Include CSS and JavaScript Conditionally And Only When Needed By The Posts
• Here's An Exclusive 10% Off NuSphere PHPEd Discount Coupon Code (Also Includes NuCoder And PHPDoc)
• How To Make Your Site Lightning Fast* By Compressing (deflate/gzip) Your HTML, Javascript, CSS, XML, etc In Apache
• Follow-up To Loading CSS And JS Conditionally
• [Perl] Finding Files, The Fun And Elegant Way

Clickjacking is a malicious technique of tricking web users into revealing confidential information or taking control of their computer while clicking on seemingly innocuous web pages. A vulnerability across a variety of browsers and platforms, a clickjacking takes the form of embedded code or script that can execute without the user's knowledge, such as clicking on a button that appears to perform another function (credit: Wikipedia).

Clickjacking is hard to combat. From a technical standpoint, the attack is executed using a combination of CSS and iFrames, which are both harmless web technologies, and relies mostly on tricking users by means of social engineering. Additionally, the only server side technique against clickjacking known to me is “frame breaking”, which would cause a legitemate site to break out of any iFrames it may be embedded in. This is not always the desired behavior and is generally frowned upon.

Generic Example

In laymen’s terms, clickjacking means that it is quite possible for websites to trick you into, for example, clicking a button to show a cute kitty while in reality prompting a deletion of all your hotmail email. A malicious site uses an iFrame (which essentially allows embedding sites within other sites) with hotmail loaded inside and hidden using CSS (which is a web language for styling HTML elements). A button named “Show Me The Next Awwww Kitty” is then placed by the malicious site and positioned below the iFrame layer (manipulated by CSS, yet again). However, because the iFrame is hidden, it looks like the “Aww” button is all you’re clicking. Wrong!

Latest Example: Twitter

This morning a new, though harmless, epidemic hit twitter. Hundreds and thousands of messages saying “Don’t Click: http://tinyurl.com/amgzs6” started showing up. Clicking the link shows a simple page with 1 button:

Clicking (which I of course did) uses clickjacking to repost the message to your own twitter account. Take a look yourself: http://search.twitter.com/search?q=don%27t+click.

All of these are a result of an experiment by some French guys to mess around with twitter and show the effects of clickjacking. Thank you for that, French guys. Creating awareness via the most social platform on the web is the best thing they could do for us.

Fight Clickjacking

James Padolsey recently wrote an excellent blog post about clickjacking and mentioned Twitter specifically. Because clickjacking relies mostly on social hacking (i.e. tricking people into clicking malicious links and buttons), Twitter is nothing but a perfect platform. James gives some nice background info and code examples. He correctly highlights, as I did earlier, that clickjacking is not a software bug – it’s a malicious technique exploiting harmless technologies.

So how does one fight clickjacking?

At this point the most reliable way is to use Firefox and the NoScript extension. NoScript provides a simple, yet amazingly effective feature, called ClearClick. From their site:

“…it's enabled by default, protecting NoScript users from Clickjacking everywhere: it even remains active if you switch NoScript in the less safe Allow scripts globally mode. How does it work? Clickjacking hides or displaces or partially covers something you wouldn't want to click, if you could see it in its original context. ClearClick does the opposite: whenever you click a plugin object or a framed page, it takes a screenshot of it alone and opaque (i.e. an image of it with no transparencies and no overlaying objects), then compares it with a screenshot of the parent page as you can see it. If the two images differ, a clickjacking attack is probably happening and NoScript raises a "ClearClick warning", showing you the contextualized and "clear" object you were about to click, so you can evaluate by yourself if that was really something you wanted to do.”

Did ClearClick work in the earlier twitter attack? Sure did! After I clicked the “Don’t click” button Noscript promptly popped up a warning showing the hidden iFrame (since the original malicious page has been removed, I found another similar page from the same author for screenshot purposes).

So, even if you don’t want to enable NoScript globally, install it anyway, just for ClearClick.

That about covers what I had to say about clickjacking. Stay safe, folks!

• Modern-Day Frame Busting With X-FRAME-OPTIONS And "This content cannot be displayed in a frame" Warnings
• Enable A Twitter Retweet (RT) Button That Lets You Add Comments Before Retweeting
• How *Not* To Implement A Web Application That Handles External Authentication, Using BeTwittered.com As An Example
• StackOverflow.com, SuperUser.com, ServerFault.com Fan? Here's A Greasemonkey Script To Keep Track Of All Your Accounts
• Hidden Features Of Perl, PHP, Javascript, C, C++, C#, Java, Ruby, Python, And Others [Collection Of Incredibly Useful Lists]