When considering ways to make web pages appear more quickly in browsers, one needs to consider everything that occurs when a user visits a web page. It might seem to be a good idea to retrieve the IP addresses associated with the domains to which users may navigate next in advance. When this is done, then the time it takes for web pages to appear should decrease. One can see how much faster pages appear when DNS prefetching is used in Chrome after entering “about:dns” into the address bar in Chrome. After viewing that page, one will be able to see which hostnames had benefits produced as a result of this prefetching. I found this information quite interesting. So I used the packet sniffer named Wireshark to view network traffic with DNS prefetching off, and then I viewed network traffic with it on. There are many pages with many links on them that one can view with DNS prefetching off and then with it on. I personally experimented with viewing Slashdot with this off, and found it interesting to see how much more DNS traffic there was when I refreshed the page with it on.

In theory, and according to tests run by Google, DNS prefetching leads to more efficient web browsing. However, when viewing DNS traffic using a sniffer such as Wireshark, one can get an idea how this can have the opposite effect on web browsing. When there are many links on a page, the majority of them may not ever be clicked by users who view these pages. In fact, it is said in this blog entry that DNS prefetching can lead to the browser spending much time resolving hostnames. It is also said in that entry that incorrect implementation of DNS caching or prefetching or other related errors can lead to web pages not appearing at all. It is suggested there that DNS prefetching be disabled, although I would like to note that I have never encountered issues such as these in the time that I have used Chrome. It should be mentioned that disabling of DNS prefetching tends to be considered a good idea when Chrome seems to be running slowly. When one searches for information on DNS prefetching on the help forum for Chrome, one will see that disabling of DNS prefetching is a common suggestion there. Although some may have found that browser speed issues are worse when this prefetching is disabled, the goal of reduced perceived latency when DNS prefetching is used might not have been attained by Google.

Of course, ideas that may seem good in theory may not always be good in practice. DNS prefetching can be considered an example of such an idea. One must appreciate the efforts that Google is making to improve the web browsing experience for users. There most certainly is room for improvement in the way that the web works, and Google has recognized this. Some of this room for improvement came as a result of the nature of the web changing, and so Google is trying to keep up with changing times. This is what led them to try to improve on HTTP.

When HTTP was first designed, it was made for a web that consisted of single pages, and one in which fewer files were sent from a server to a client. Now that many files are sent to users when they load web pages, this would not suffice. HTTP 1.1 supports sending several requests before replies arrive, in what is known as pipelining. However, pipelining may not be very advantageous, as HTTP 1.1 requires that replies to requests be returned in order. The server must spend extra time processing incoming packets to determine the order in which packets must be sent. Some might also see how sending several requests at once and requiring the server to process them can lead to denial-of-service attacks. This is all explained well in this blog post.

SPDY addresses issues that HTTP has in a number of ways. In addition to its ability to send several requests over one TCP connection, requests are prioritized. The client prioritizing requests leads to what is more important being sent to the browser first. Also, headers are compressed, which is appropriate as much redundant header data tends to be sent back and forth when HTTP is used. It is interesting to note that all SPDY traffic is encrypted. It was claimed that page load times were reduced by up to 64% when SPDY was tested. However, SPDY may have its drawbacks. As it says in this article on SPDY, the amount of processing done in compression and encryption could lead to servers having to be upgraded. This article describes changes that would need to be made on the server side in greater detail.

Google also recently announced the launch of a public DNS resolver called “Google Public DNS” in another attempt to improve the web browsing experience for users. Google’s attempts at making web browsing more efficient may not work as well in practice as they do in theory. Nevertheless, one has to appreciate their efforts in updating the way in which browsers and protocols work to improve the efficiency of web browsing.

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.

After I read about what makes Google Chrome faster than other browsers, I have found that a few points tend to be mentioned consistently. It is often said that its use of the Webkit open source web browser layout engine and the open source JavaScript engine known as V8 set it apart. What it is about Webkit and V8 that make Google Chrome faster and more efficient is mentioned in a number of different places. And these explanations appear in a number of different forms, such as this video in which Lars Bak, the head programmer of the V8 project, explains the concepts behind V8.

Some might consider the explanation in that video useful. Others, who do not have as much knowledge of the topics that Bak explains, would prefer explanations that they would be more likely to understand. I personally wanted a thorough and complete explanation of what makes Google Chrome as fast and efficient as it is. What I had not realized was that I needed to look no further than the page on Google that lists its features for the link to the information that I wanted to find. This information may have been there for a long time, although it seems to continue to be the best introductory guide to the technology that makes Google Chrome different.

It seemed to be appropriate that the best guide to Google Chrome’s features came from those employed at Google. The differences in its user interface, security handling, and performance are covered in it. In this post, I will only focus on Google Chrome’s speed and efficiency. I may cover the user interface and security design decisions in a different post about Google Chrome. If I do, I may once again refer to this comic.

There is a section on Webkit and V8 in that comic in which important concepts about V8 are explained well. Webkit, which is also used by Safari, is said to manage memory well. It is said that Google Chrome is designed for the world wide web of today rather than the one that existed when browsers were first written. That is the reason it was said to be important that its JavaScript engine be efficient, considering how often JavaScript is used in web applications. The concept of hidden classes is covered well, and it is covered in enough detail for its intended audience to understand the basics of it. Those who would like a more detailed explanation of this concept may see it explained in further detail here. Also, it is mentioned that JavaScript is compiled into machine code when V8 is used. As those familiar with advantages of compiled code over code that is interpreted as JavaScript typically is, this can lead to a significant performance increase. Also, as hidden classes are created, the machine code can refer to these hidden classes, which leads to better performance. In addition, V8′s method of garbage collection is very efficient, and it is explained how memory is managed much more efficiently than it is in other JavaScript engines.

The explanations in this comic seem to be aimed at an audience that has some knowledge of the concepts explained in it. I thought that those who want to know more about this technology would find it understandable and entertaining. Some might also understand jokes in it, such as the “speed limit” depicted on this panel as being 10¹⁰⁰, also known as a googol. Some might like this comic, some might not. For those who prefer to view a video that covers some of the same material, but in less depth, there is this video.

Some may find my recent praise for comics interesting. Some might also find it interesting that I am praising Google Chrome after writing much here about Firefox. I still use Firefox quite often, mostly because of its extensions. However, when I want to use a browser that is simple, fast, and efficient, I use Google Chrome.

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.

In last fortnight’s entry here, I wrote about performing and preventing SQL injection attacks. After writing about that, I considered following up on that entry by writing about these attacks in greater depth. I thought of writing more about everything that one would perform in the process leading up to the SQL injection attack, rather than simply the SQL injection itself. So I decided to gain some practical experience with what may be involved in performing such attacks.

A step that is often performed when hacking is that of looking for potential targets that might have some sort of vulnerability. This activity is one that tends to have the word “war” prefixed to it, as phrases such as “wardialing”, “wardriving” and even “warflying” are often used to describe variations of this activity. And to look for websites that have login forms (through which SQL injection attacks can be attempted) Google can be used. To list websites that have login forms, one can enter a search query such as “inurl:login.php” into Google. This works because pages with login forms often have “login.php” or “login.asp” in their URLs. After I used this method for finding pages that have login forms, many results were returned. However, many of the sites returned in these results may not have had SQL injection vulnerabilities. So I then thought of a way of making it more likely that search results would contain pages that have these vulnerabilities.

The idea that I had for increasing the probability of finding sites with such vulnerabilities was based on this assumption: Websites that have these vulnerabilities are unlikely to be listed in the first pages of Google’s search results. Websites that would be more likely to be ranked before others when Google searches are performed may be more likely to have the measures needed to prevent SQL injection attacks implemented. Therefore, after displaying the first few pages of results after submitting the search query, I decided to bring up the tenth page of results, and then I brought up the nineteenth page of results. Then I received an error saying that my search query looked “similar to automated requests from a computer virus or spyware application.” Google thought that I was a bot. And so if you click here to perform a Google search similar to the one that I performed, you can convince Google that you are a bot as well.

I recall hearing about others finding that something like this happened to them. However, I had never experienced anything like this myself. I was not trying to pass or fail a reverse Turing test, and Google gave me a result that was unexpected and, of course, inaccurate. Some may find it interesting that I am writing something that may seem critical of Google near Google’s tenth anniversary. However, I did use Google in trying to find websites with a certain characteristic. And that is one of many tasks that I would always use Google to perform.

The malicious activity that can result from Greasemonkey scripts having the ability to access cookies has been a topic of discussion among Greasemonkey aficionados. Cookie-related Greasemonkey issues and the possible solutions to them were mentioned in the recent trilogy of entries on this blog about past and present security concerns with Greasemonkey. Possible solutions to these issues were mentioned in the third part of that series of entries. And one solution mentioned is one that would completely eliminate the possibility of Greasemonkey scripts performing malicious cookie-related activity. Such a solution would be implemented by having a future version of Greasemonkey deny its user scripts access to cookies. This solution may seem drastic, although it is one that has been given some consideration.

This simple solution’s drawbacks are about as obvious as its benefits. And if this solution were implemented, these drawbacks would be very similar to the ones that existed a few years ago when Greasemonkey 0.3.5 was released. The issues that Greasemonkey had with its API functions at the time necessitated that these API functions be disabled in version 0.3.5, and these changes caused many scripts to not work with this version. And Greasemonkey denying its scripts access to cookies would cause hundreds of Greasemonkey scripts to not work, as one can see by performing this Google search for scripts that use the document.cookie property. It should also be noted that the security issues prevented at the time Greasemonkey’s API functions were disabled were considered much more serious than the issue of cookie stealing scripts. In this case, the benefits of precluding a security risk do not outweigh the disadvantage of causing the number of scripts that would be affected to not work.

Many Greasemonkey scripts depend upon access to cookie data via the document.cookie property, and some of these scripts cannot exist at all without access to cookies. These scripts that would cease to be useful at all if Greasemonkey scripts could not access cookies are ones that perform what many users would like to have done with cookies. And in this entry, these scripts that completely depend on access to cookies are the topic. However, as the title of this entry suggests, much of the focus of this entry will be on one script in particular whose function is to work with cookies.

Greasemonkey scripts may be able to perform malicious cookie-related activity, although there are a few scripts that do what many users may want done with cookies. I considered writing a post here in which I would list a few of these scripts that are primarily for working with cookies. And I discovered a few scripts that require access to cookies in order to perform what they are intended to perform. One of these scripts is titled “Google Search Cookie Cleaner.” Much has been said about Google’s cookie policy, and how Google having its cookies expire after two years matters little to some of those concerned about privacy. And the Google Search Cookie Cleaner script removes much data from cookies that could possibly be used to track users. Another script, titled “Google Anonymizer” takes this prevention of possible tracking of user activity on Google’s part a few steps further. In addition to deleting more data that is in cookies from Google, it can disable JavaScript functions that appear to be used by Google to track users. And whereas the Google Search Cookie Cleaner script has a disadvantage in that it takes away the user’s ability to store preferences for Google searches, the Google Anonymizer script allows users to store these preferences by saving them in Firefox’s preferences.

There was one more script that I found was entirely dependent upon its ability to access cookies, as work with cookies was its primary function. This script, known as “Cookie Monster” was one that I found did not work at all when I tried to use it. It was quite unfortunate that it did not work, as its ability to give a quick way to reveal cookie data set by the page being viewed would be considered useful by some. A few modifications were needed in order to make it work, and so I decided to make those modifications, and I added a few of my own personal touches to it. And this modified version of the script, which I refer to as “Cookie Revealer,” is the primary topic of this blog post, as I explain how I went beyond simply making the script on which it was based work properly

There are a number of different ways that one can view the cookie data set by a page being viewed when Firefox is used. However, when using the option in Firefox for displaying cookies or a number of Firefox extensions made for working with cookies, there are no easy ways to get a quick overview of what is happening on a page cookie-wise. One might want information on cookies set by a page to be accessible through the page itself. Therefore, a script that adds elements to pages in which cookie data set by pages can be accessed could be one that some might want. And this script, which adds elements to web pages and frames within pages through which cookie data set by the page and its frames can be accessed, makes data in cookies easily accessible. And after I made adjustments to the script so that it would work as intended, I found the script useful. In fact, I used it to determine what data was removed from cookies set by Google by the two scripts previously mentioned. However, there were a few adjustments that I thought should be made to it.

Previously, the script would display cookie data only when leaving the mouse cursor over the elements the script would add. This may not be preferable to some, as in this case, the cursor would often be in the way of the cookie data being displayed. In addition, one would have more difficulty highlighting this cookie data when trying to copy and paste it, as the cookie data would disappear whenever the cursor is even slightly outside the area that would display this data. Therefore, I chose to modify it so that one could toggle whether or not cookie data is to be displayed by double-clicking the elements the script adds to pages. Also, I modified the CSS properties of the added elements so that scroll bars would added to the elements when necessary, so that all cookie data could be viewed when there is much cookie data to display. In addition, changes could be made to cookies while the pages that set them are displayed. And so I modified the script so that after these changes are made, they will appear when the cookie data is redisplayed. Also, the functionality for completely removing the elements for displaying cookie data was also removed, as one could simply disable the script and refresh the page when one does not want these elements to be displayed. Below are links to screen shots of a page on which this script is running. The first one simply displays the element added in the lower left corner of the page by the script, and the other displays cookie data after this element is double-clicked.

If you have Greasemonkey installed, then you can click here to install this script. I already have some ideas in mind on how to improve upon this script. I was primarily interested in simply making this script work correctly, and there are some improvements that can be made to it to make cookie data more easily visible in some cases. This is only version 0.1.0 of this script, and new versions of it will almost certainly be released in the future. There might be those who will suggest improvements to it, and implementing requested improvements will be a priority for me. There may be interest in this script and in improvements to it, and that is why this script could be considered a reason Greasemonkey should not disallow its scripts access to cookies.

However, some ideas I have for improvements to this script are beyond Greasemonkey’s scope. Therefore, what could evolve from this script is another useful Firefox extension for handling cookies. I may need to take some time to see if there are Firefox extensions that perform anything similar to what I am thinking of writing, as I prefer not to waste my time writing redundant extensions. In any case, I will write software that could make some people less nervous about cookies.

Note: There is a poll within this post, please visit the site to participate in this post’s poll.

I would first like to say that I was flattered that something that I wrote was featured among the interesting material on Lifehacker. However, I would have preferred that they got my name right when mentioning who wrote the featured blog post. And it was my first name, not my often-misspelled surname that was not entered correctly there. And to those interested in how I reacted to seeing that I was twice referred to as “Jane Kasprzak” in that post, I would like to say that I laughed out loud. However, my name being entered incorrectly there was not something that mattered to me very much. The interesting discussions that resulted from what I wrote is a reason my name being entered incorrectly is not something I will focus on here.

Some interesting points were made by Adam Pash, and by those who have contributed comments in response to what I wrote. It was after Mr. Pash asked for comments on Greasemonkey scripts for YouTube (and other related YouTube tweaks) that some interesting comments were made. A few other interesting Greasemonkey scripts were mentioned both here and in the comments section of the Lifehacker post. In fact, when writing last week’s blog post, I considered mentioning that some may prefer the script for removing comments, rather than the one for moving comments to a different location. This is one example of two scripts for YouTube that users may want to have, but conflict with each other. And there are many other scripts that perform many other tasks that may conflict with each other, but are ones that users may still want enabled at certain times. For this reason, it would be good to have a Firefox extension that contains all of these scripts and only allows scripts that do not conflict with each other to be simultaneously enabled. And it is this kind of extension that Adam Pash less-than-subtly suggested be written, and this suggestion led to another discussion that I would like to join.

Mr. Pash alluded to the extension titled “Better Gmail” that contains over twenty-five (25) Greasemonkey scripts that a user can have enabled. Many of these scripts are considered features that can be added to Gmail, and others are considered skins to customize the appearance of Gmail. It is convenient to have an extension such as this, as it saves the user the time that would be spent looking for and downloading each individual script. In addition, with this extension, scripts that conflict with each other cannot be simultaneously enabled through the interface that it has. And so with the many scripts available for enhancing YouTube, would it not make sense for a similar extension titled “Better YouTube” to be made available? Well, such an extension may be on its way soon.

There certainly would be interest in this kind of extension, and it may be available sooner than one might think, because it may be fairly easy to develop. This extension could simply be based on the Better Gmail extension, which in turn seems to be based on the Better GCal extension. After looking through the source code for both of these extensions, it appears that few modifications of the Better Gmail extension need to be made for it to work with YouTube. It may need to be based on the Better Gmail code, as the code for the Better GCal extension does not appear to work with conflicting scripts. It might take some time to determine which scripts should be included in this extension, and to determine which ones might conflict with each other. However, Gina Trapani, who wrote these two extensions, has emphasized in her book that where there’s a will there’s a way. And it is not my intention to pressure Ms. Trapani or anyone else who might write this extension into getting it done quickly. I am only saying it can be done, and that it may be done soon.

When I wrote last week’s blog post, I never did expect it to lead to the kind of discussion that took place here, let alone on Lifehacker. I never did think that this post would lead to anything that might possibly be considered a catalyst for the development of a Firefox extension that many would consider useful. However, I am quite pleased to see this, as this extension that I am indirectly and accidentally responsible for creating interest in is one that I too would like to see.

One of the advanced features of Google that I use most often is the one for searching within specific domains or websites, as Google can be better for searching through sites than the search features included in some sites. I have often found that I like to search for YouTube videos once I get Firefox started up, and YouTube-specific searches are not going to be included on Google’s main page despite Google owning YouTube. And I did not want to use the search plugin for YouTube, which you can find and download if you click here, as I preferred to simply work with what was on the web page. So I wanted to add some functionality to the Google’s main page that would allow YouTube-specific searches, as I was getting tired of having to type in “site:www.youtube.com” after entering search terms. And I still wanted to be able to do these searches from the main Google page, rather than set my browser’s home page to the advanced search page. (And even if I did have it set to this advanced search page, I would still need to type in the domain name in the place where it needed to be entered, which I wanted to avoid.)

I am fairly new to using Greasemonkey, as it has been somewhat recently that I have found out how useful it can be. What I have liked the most about it is its ability to add the kind of functionality to web pages that I, but not necessarily others, would like to see on them. And so I decided to use Greasemonkey to make it so that I could use some of Google’s advanced search capabilities on the simple and uncluttered main Google page. I quickly wrote a Greasemonkey script that adds a button for YouTube-specific searches to Google’s main page, and to Google’s pages that display search results. After entering the search string and clicking this button, it displays search results from within youtube.com. I have found this script useful so far, as it has saved me keystrokes, mouse clicks, and time it takes to load pages. In fact, I found it very useful after I time I walked by the intersection of Yonge and Dundas Streets in Toronto, where I saw a sidewalk chalk artist suggest doing a search on YouTube for “chalk this way.” With this script, the result that he would want me to see was the first in the list of the results, and I was able to get there without having to go through YouTube.

You can click here to download this Greasemonkey script. I don’t expect many others to be very interested in using the script at this time, but I’m making it available for those who might want to use it. I should also note that this script may be something I’ll continue to work on. And as is the case with anything else I write, any feedback would be appreciated. Also worth mentioning is that this script only requires a few slight modifications for making it so it can search other sites. I’m not sure how many members of Greasemonkey’s userbase might be willing to make these slight modifications to the source code, even though in the source, it is documented where changes need to be made to make it search different sites. It is quite possible that those who use Greasemonkey can often be expected to make those kinds of changes, as Greasemonkey users may tend to be advanced Firefox users. However, I am not quite sure of this, but the topic of the level of knowledge of Greasemonkey users can be a topic for another blog entry.