There are three major JavaScript performance test suites, each of which were released by different browser vendors. Webkit released SunSpider, Mozilla released Dromaeo, and Google released the V8 benchmark. As is often the case with benchmark tests, they may not necessarily accurately determine what performs best in the actual situations that they try to simulate. These JavaScript benchmark tests may have their flaws, some of which are still being addressed. Despite the flaws that JavaScript benchmarks may have, they can give an indication of how some JavaScript engines can be better than others. In the Computerworld article previously mentioned here, the SunSpider test suite was used to test the performance of the JavaScript engines of different browsers.

After I wrote about Google Chrome in the last entry here, I wanted to more precisely determine how much better it is at JavaScript performance than other browsers are. I considered running a few benchmark tests on a few different browsers. However, that has already been done many times by others. One can view results of such tests in the Computerworld article to which I previously posted a link, and here. However, those tests were run before Firefox 3.5 was released, and JavaScript performance in Firefox 3.0 is not as good as it is in Firefox 3.5. In fact, according to what is on this page on Firefox performance, SunSpider tests indicate that JavaScript performance in Firefox 3.5 is twice as good as JavaScript performance in Firefox 3.0. I also wanted to run these tests myself. I ran the SunSpider benchmark tests using Firefox and Chrome, and found that the benchmark tests ran much faster in Chrome than they did in Firefox.

The SunSpider test suite is a comprehensive one that simulates situations that users will encounter when they browse the web, such as generation of tag clouds from JSON input. In running these tests, I ensured that I was using the latest versions of these web browsers. I also ensured that no other browser tabs were open when I ran these tests. I also created a new Firefox profile and used it to run the SunSpider tests on Firefox. I wanted to ensure that these test results would be as accurate as possible.

I found it interesting to see the mean times it took for the tests in the SunSpider suite to be completed. It was also interesting to see what the 95% confidence intervals were, which as some of those reading this may know, are used to determine with 95% certainty that true mean values are within those intervals. I viewed the source code on the SunSpider website to see how those values were calculated using a Student’s t-distribution, and was reminded of concepts that I learned about in a university statistics course. After running the tests three times with Google Chrome, the average time it took for the tests to be completed was 822.2 ms. I then ran the tests three times with Firefox, and the average time it took for the tests on Firefox to be completed was 1756.8 ms. Firefox took more than twice as long as Chrome to complete the suite of tests. One can verify this after viewing the results of the first, second, and third tests I ran with Chrome, and the results of the first, second, and third tests I ran with Firefox. One can also copy and paste URLs from one set of test results into a text box on a page that contains the other browser’s results to compare results.

As you may have seen if you have viewed the results of other JavaScript benchmark tests that have been posted on the web, they tend to list only the mean times it took to complete them. Confidence intervals are not mentioned in the Computerworld article that I previously mentioned. When one wants to see precisely how much faster one browser’s JavaScript engine is than another’s, one may want to take confidence intervals into account. However, in the tests that I ran, overall confidence intervals did not differ by a large percentage. The mean values and confidence intervals were similar for the three tests that were run on each browser. This gives a strong indication that Chrome’s JavaScript performance is significantly better than that of Firefox.

Google Chrome may outperform other browsers in JavaScript performance. However, Internet Explorer’s JavaScript performance is as good as Google Chrome’s when Google Chrome Frame is used with it. According to this other Computerworld article, when Internet Explorer is used with Chrome’s JavaScript engine, its JavaScript performance is, understandably, much better. Once again, Computerworld used the SunSpider test suite to determine these JavaScript performance differences. Google Chrome’s JavaScript engine’s performance may be better than the performance of other JavaScript engines. It also appears that it will continue to be better than other JavaScript engines. In this post on the Google Chrome blog it was said that JavaScript performance in its latest beta has increased by 30% since the last stable release of Google Chrome.

I found that I needed to update the Greasemonkey user script that I wrote titled “Do Not Remember Me” a few weeks ago. There was a very minor adjustment that I needed to make to it after a change was made to the Google Accounts login form. I chose not to write a blog post about this update, as this update was a very minor one. However, if I had a Twitter account at the time, information on this update could have been posted there. Also, the Firefox extension that I wrote titled “Bookmark Current Tab Set” is now considered public and is no longer considered experimental. This change of the status of this Firefox extension is more information that I thought would be better suited to a Twitter post than to a post to this blog.

You may find me on Twitter here. I am not sure how often I will be posting to my Twitter account. However, I plan on posting to it, as I plan on continuing to post to this blog, and I plan on “tweeting” about updates to this blog.

The most significant difference between this version of the extension and previous versions of it is that this new version is compatible with Firefox 3.5. However, some might find that folders to which this extension adds bookmarks can no longer be placed within other bookmark folders. Some might also find that new folders cannot be created from the dialog box from which tabs can be bookmarked. However, this functionality was quite dependent on code in Firefox 3.0, and that code had been modified. The ability to put the folders that this extension creates within other folders may have been a seldom used feature, and it needed to be removed in order for this extension to be released within a reasonable amount of time. I apologize to those who made use of these features that needed to be removed. If some want this ability to put folders created by the extension into other folders, then the feature for doing this may appear again in future versions of this extension.

The extension can be downloaded and installed from here or from here. I would appreciate receiving feedback on this extension. It has also been modified so that it will not be as likely to conflict with other Firefox add-ons. For this reason, it will be more likely to be considered non-experimental soon, and so there may be more users who will suggest changes to it in the future. And when more users make suggestions on what can be adjusted in the extension, suggested changes will be more likely to be implemented.

Reflected XSS attacks tend to be carried out by directing users to malicious URLs. When I look through the URLs on the list of reflected XSS vulnerabilities on XSSed.com, I find that many of these URLs are quite unwieldy, and contain text that may appear suspicious. It seems that a method for making URLs appear to be innocuous would be to display them in the form of URLs that would be output by URL shortening services. Also, Twitter has been used to spread an XSS worm before, and so URL shortening services could be used to launch XSS attacks via Twitter once again.

I am not the first to write about the security implications that these services have. There is a very good blog entry on this topic that can be viewed here. There are articles on how these services can be used in phishing attacks that can be viewed here and here. It is mentioned in each of these articles how revealing of the longer versions of shortened URLs can be done. However, many users may not take the time to verify where they would be taken when they go to one of these shortened URLs. Some might not want to take the time to visit a website such as LongURL to view the longer URL to which they would be redirected. And some might not use tools such as the Firefox extension for revealing URLs shortened by the service known as bit.ly. Many users simply prefer not to take the necessary amounts of time to prevent themselves from possibly going to a place on the web to which they would not want to be redirected.

It seems that when users are given a choice between security and convenience, they tend to choose the latter option. There must be a way for URL shortening services to be both secure and convenient. Until there are improved methods for determining whether or not shortened URLs are being used for malicious purposes, these URL shortening services will be used for attacks such as phishing and XSS attacks.

As those familiar with Adblock Plus (often abbreviated as ABP) know, it blocks web page content by using sets of filters. JavaScript content, Flash animations, and groups of image files are examples of what can be blocked by these filters. Any content that matches certain patterns in the source code of web pages can be blocked with ABP’s filters. As end users prefer to have web content filtered for them automatically, users can subscribe to filter lists. These lists are maintained and updated by individuals who look for content that users may want to have blocked. These lists tend to be modified over time, and users who subscribe to these lists have their lists updated periodically. Users who subscribe to these lists trust those who maintain these lists to block content that these users would want to have blocked.

NoScript is a Firefox extension that blocks much content of web pages by default. NoScript relies on the donations of users in order to fund the project, and this is done through advertising on websites run by NoScript creator Giorgio Maone. Those who have subscribed to a filter list for ABP known as EasyList may have found that some of the page content on sites run by Maone had been blocked. Maone responded to this by updating the pages on these websites so that those ads could again be viewed by those who used EasyList. Then these filters continued to be updated so that those ads would be blocked again. To Maone, it seemed as though the site content that helps create funding for the development of NoScript was being deliberately targeted by the EasyList filter for ABP. In fact, according to Maone, filter rules were implemented that would even prevent the download of NoScript from those websites. This is what led to a response from Maone that was highly controversial, and was one that he would understandably regret very much.

Firefox extensions are not “sandboxed” in the browser, meaning that there is nothing preventing them from interfering with each other. Maone took advantage of this fact. NoScript was modified so that it would actually modify ABP’s filter list so that the four websites that were targeted would be whitelisted. This interference with another extension was done rather surreptitiously. Information on this was added to the release notes of the NoScript version that performed this action. However, not many users may have read this, and Maone later admitted that he should have done more to inform users about this. One extension interfering with the operation of another, without explicitly asking for user consent, was considered a very questionable action on the part of Maone.

Some may want to read the official statements on this conflict that were written by the authors of these extensions. ABP creator Wladimir Palant’s comments about this issue can be found in this blog post. Maone’s response can be read here.

It was only in the last entry that I wrote here two weeks ago that I mentioned how NoScript could be used to defend against XSS attacks. There were many who considered NoScript a trusted extension, and it may have been considered one of the most trusted Firefox extensions in existence. In fact, all Firefox extensions can be considered trusted after they are reviewed and approved by staff members at addons.mozilla.org, a website that is often referred to simply as AMO. All extensions uploaded there are considered “experimental” before their code gets reviewed. Theoretically, the trust that users would have in non-experimental extensions could be betrayed by individuals who could write extensions that get approved, only to be later modified to surreptitiously perform actions undesired by its users. One would certainly not expect an extension written by someone who seemed motivated to prevent websites from doing anything without user consent to be such an extension. However, this is what happened, and it is the reason for the recent backlash against NoScript and for its creator’s apologies. If anything good can come from this dispute, it is that this could lead to sandboxing of extensions within the Firefox web browser.

There are those, however, who would say that Palant should also admit to wrongdoing. When users install Adblock Plus, it is with the expectation that advertising that is considered intrusive will be removed by it. When viewing the four sites run by Maone, one can see that the advertising there is unlikely to be considered a reason for the existence of ad blocking software. Targeting of Maone’s sites, which Palant admitted to doing, seemed questionable. However, it seemed as though there should have been more communication between individuals on the two sides of this dispute. There had to have been a way to avoid the cycle of filter updating followed by evasion of those filters.

Both Maone and Palant have faced backlash from many users. Maone, however, has admitted to wrongdoing, and has removed the code that was the reason for his apologies. And after checking the EasyList filter list, the filters Maone mentioned no longer seem to be there. I believe that the individuals on both sides of this dispute could have done better in trying to prevent it. Those who write Firefox extensions seem to be motivated by simply making Firefox a better browser, and thus one would not expect them to have such disputes as they try to reach their common goal. It seemed as if Maone and Palant might have lost their focus, and are now not as trusted as they had previously been. However, over time, I believe that we might be able to trust these individuals and their extensions again. In any case, I hope to not have to write about a conflict between Firefox extension developers again.

These surrogate scripts handle the situations in which 3rd party scripts from sites such as Yieldmanager.com look for page content that is blocked by NoScript. These surrogate scripts cause pages to be more likely to be error-free by replacing blocked scripts with similar scripts. Some concerned “non-geeks” have wanted to know if these surrogate scripts send any data to 3rd party sites. However, those who have viewed and understand the source code in these scripts can assure these individuals that these scripts simply try to prevent web pages from being broken. There are some users of NoScript who had previously found that some pages were broken unless scripts from sites such as Yieldmanager.com were allowed. I found that when scripts from Yieldmanager.com were blocked, pages on Imageshack.us appeared to be broken. However, these pages did not appear to be broken when the surrogate script for Yieldmanager.com was used. I have also found that these surrogate scripts cut down on the clutter that appears in the error console, as there would be fewer errors on pages when these surrogate scripts are used.

Users who have used the more recent versions of NoScript may have used these surrogate scripts without even knowing that they used them. However, there are those who might want to more easily configure these scripts. At this time, there is no user interface for configuration of surrogate scripts, because as NoScript author Giorgio Maone says, those who would configure these scripts and options regarding them would likely not need one. Still, a UI would be convenient, as adjustments to configuration settings may sometimes be necessary. One might want to more easily adjust which sites use surrogate scripts and which ones do not. Also, one might want to be informed when sites are using these surrogate scripts. In fact, I decided to make a few adjustments to surrogate scripts so that they would display information that says surrogate scripts are being used right on these pages where they are used.

I wanted to know when the surrogate script for code from YieldManager.com was being used. So I added a JavaScript alert statement to the surrogate script for YieldManager.com to determine this. As those who are familiar with JavaScript know, that statement would make a pop-up window appear when that script is executed. I then decided to make that code more complex by adding code to it that would execute when the page is finished loading so that text would be added directly to pages to indicate that this surrogate script is being used with these pages. However, it would be preferable for information on when these scripts are being used to instead be in the browser UI.

Users of the web may always need to choose between security and convenience. The newer versions of NoScript make it so that less convenience would need to be sacrificed for improved security. Still, it would be more convenient for there to be a UI to work with these surrogate scripts used by NoScript. However, it is good to know that the decision to choose security over convenience when browsing the web now seems to be a less difficult one to make.

While some might like to be able to view data that is being sent to and from a web browser, there are those who may find that the Tamper Data extension is not what they need. Those who want to be able to view the data that is sent via web forms may want something more simple, and something that is specialized to the task of displaying the data that is sent through forms. The Web Form Data Analyzer script is for those who only need the software to perform the task that it performs. In addition, the script displays the form data that would be sent through the form without the data ever being sent to the website to which form data is supposed to be sent. Therefore, those who would prefer to simply view the data that would be sent through a form without actually submitting it to the site where it is supposed to go may prefer to use this script.

There may be those who are not sure if the page to which the script redirects submitted form data will accurately display this submitted data. However, the source code that this page apparently uses can be viewed here. As one can see by viewing that code, it is simply PHP code that displays values that would be stored in variables when form data is submitted. And if one does not think that that page actually uses that source code, then the script could be modified so that the page to which it redirects form data will be different. What would be needed in that case would be a web server to host a page that uses code that displays this data. One would likely be using Firefox when using this script, and so one would likely be able to use an extension called Plain Old Webserver to set up a web server. Going through this process of setting up a web server that hosts this page might seem like more work than it is worth, although it is a way to ensure that the data returned will be accurate.

This script may be useful for those who trust the official reference website for the book titled “Webbots, Spiders, and Screen Scrapers.” Those who do not trust it may find that there are other methods for determining what data is sent through web forms. Opinions on whether or not that page can be trusted may differ, and this script is useful for those who believe that the page that this script uses is reliable.

I have recently found that a number of individuals have found their way to my site after entering “writing firefox extensions” into a search engine. It was after finding that more individuals than I expected were viewing a post that contains that search term in its title that I decided to conduct a Google search using that term. I then found that the blog post that I wrote titled “Going Beyond Programming When Writing Firefox Extensions” was on the first page of search results when I Googled that term. You can see where that blog post currently ranks in search results when that term is entered if you click here. Since the time that I first discovered where that post ranked when that search term is used, I have found that that post did not rank as high as it previously did. However, I am unsure if it should be ranked among the first ten results, ahead of hundreds of thousands of results returned when a search for that term is conducted.

The term “writing firefox extensions” may often be entered by those who would like to join the many individuals who write extensions for Firefox. When a search for information on writing Firefox extensions is done, what individuals may want is the best information on how to write these extensions. However, my aforementioned blog post does not contain the best information for those who aspire to write Firefox extensions. Inclusion of the text of this search term in the title of that blog post is what may be one reason it ranks as high as it does among these search results. However, I never meant for that blog post to be considered an authoritative guide for those who want to write Firefox extensions. If I had known that that post was going to be ranked that high among search results, I would have put more effort into making it contain as much useful information as possible.

I would like to apologize to those who tried to find information on writing Firefox extensions only to find that any of their time was wasted by coming across this information that may not have been very useful. I have mentioned before that Google is not perfect. That blog post being ranked as high as it is appears to be evidence of this fact. However, Google’s algorithms were designed and written by those who have much knowledge of search engine technology. To dispute where pages should rank among search results would seem to be arguing with these individuals. And who am I to argue with them? I suppose I will need to accept that some my blog posts rank higher among Google’s search results than they should.

This Greasemonkey script that I wrote did not work with embedded videos that were embedded a certain way, and so I made the necessary corrections to it. I also added a feature to it so that it would not add links to YouTube pages on the main Google Video page. This was done because there already is a link below the embedded video that is featured on that page to the page on YouTube where that video can be found. These updates were quite minor, although they needed to be made.

In version 0.2.0 of the Firefox extension that I wrote, I added a menu option that brings up a dialog box. However, it was only after releasing this version of the extension that I thought that I should add an ellipsis to the end of the title of this menu option. I could have checked the extension more thoroughly for errors both in functionality and in the user interface before releasing version 0.2.0 of the extension. However, as is it often said that those who write this kind of software should release early and release often, I chose to release it before I could check for all errors that I might have made in writing it.

I am currently trying to decide on what kind of software to write next, and I am not sure what my focus should be. However, I am sure that I will continue to make the necessary updates to what I have already written.

As it says on the main page for the project here, this extension is based on technology proposed by two individuals from the University of Passau and one individual from the University of Hamburg. This paper in which this was proposed can be viewed in PDF form if you click here. In that paper, it was mentioned that input filtering and output sanitation are commonly used methods for preventing XSS attacks. However, the process of filtering of certain keywords that may indicate the possibility of an XSS attack, such as "document" or "javascript" tends to be flawed. This fact was noted in the paper, and the fact that output sanitation fails frequently was also noted. More complex and more reliable methods for detecting possible XSS attacks were proposed in that paper. It was suggested in that paper that data in HTTP requests and their corresponding HTTP responses should be analyzed and compared in order to report possible XSS attacks while preventing reports of false positives. It was said in that paper that when this XSS detecting software that was proposed was tested, there were no false negatives, and few false positives. Methods for further preventing false positives were also mentioned in the paper. Having said this, a Firefox extension based on what was proposed in this paper would be one that many would like to have.

The Firefox extension based on what was proposed in that paper currently only implements part of what was proposed in the paper. For example, it currently uses string matching when trying to detect XSS attacks, when the process of subsequence matching mentioned in the paper would detect more XSS attacks. However, in tests that I have run with it, it successfully prevented XSS attacks, except in situations that are not yet supported by this extension. In addition, I have yet to receive a false positive when using the newest version of noXSS. The testing that I had done on it may not have been thorough, and the author of the extension mentioned that there are some XSS attacks that it currently will not block. However, based on what I have seen on the noXSS project page regarding future plans and based on what I have seen in comments in the extension’s source code, there are clearly defined plans to make it work well in the future. At this time, one might still want to use the protection against XSS attacks offered by a Firefox extension named NoScript, which was mentioned both on the project page and on the paper on which this project is based. However, in the paper, it was said that use of NoScript can result in false positives because NoScript does not analyze as much HTTP data as the software proposed in the paper.

This Firefox extension has potential to be very useful, as it is based on technology that has already been found to work well. A number of individuals will need to test it and give feedback about it in order to ensure that it will be implemented properly. I will continue to test it, and I plan on testing future versions of it. I also may write more about it in the future. I look forward to working with future versions of this extension, and I plan on assisting in ensuring that it will work as well as it should.