June 19, 2009
Welcome to my blog. I don't really blog per se, but you might find some interesting things over at my website.
June 18, 2009
Remove the 'Security Warning' on files downloaded with Firefox 3.0 and 3.5
First, the workaround:
To remove the 'Security Warning' dialog that comes up when launching a file downloaded with Firefox 3.0, set the browser.download.manager.scanWhenDone preference in about:config to false. To read about why this dialog is used, what causes it to be shown, and how this workaround was discovered, read on.
Update for Firefox 3.5:
If you are using Firefox 3.5, you will notice that setting this preference no longer bypasses the security warning. I have found that Firefox 3.5 users who wish to bypass this warning must instead set a new preference named browser.download.manager.alertOnEXEOpen to false. The browser.download.manager.scanWhenDone preference now only controls whether the OS is asked to invoke the virus scanner when the download completes, so for security reasons, if you had turned this off previously you should probably set it back to true.
The browser.download.manager.skipWinSecurityPolicyChecks preference previously mentioned here is not needed; its purpose is to allow a user to override the "Launching applications and unsafe files" setting in Windows Internet Options.
Good news for Firefox 3.6:
In Firefox 3.6 and above, a Zone.Identifier stream will no longer be added to downloaded files. Additionally, the browser.download.manager.skipWinSecurityPolicyChecks and browser.download.manager.alertOnEXEOpen preferences will be removed entirely.
Now, the story:
One of the new features of Windows XP SP2 was an enhanced security mode for downloads. When a program used one of the new APIs to save a file, Windows would automatically initiate a virus scan with the any installed antivirus software (provided that the antivirus software also used the new APIs). The new save API also flagged the download as having come from the internet, and when launched, if the download was not digitally signed, Windows would present the user with a warning box.
Prior to version 3.0, Firefox users were not invited to this party because Firefox did not use these APIs. In contrast, Microsoft updated its Internet Explorer browser in SP2 to use these new APIs so that IE users would be protected from the potentially 'dangerous' files they were downloading. In practice, however, the only software that was ever digitally signed was Microsoft's own programs. This meant that Windows would consider any other download potentially dangerous, and would annoy (or perhaps frighten) the user with the above dialog box.
Windows Vista took this mechanism a step further. In addition to downloaded applications (.exe files and scripts), Windows Vista also alerts the user with the following (somewhat cryptic) dialog if they attempt to extract files from an archive such as a .zip file:
What's worse, is that 'No' is the default action, so simply hitting enter will cancel the extraction operation. In Windows Vista, the security settings are also inherited for all files extracted from the archive. This means that if the user extracts a setup application from a .zip file they downloaded and then runs it, they will not only encounter the above dialog during extraction, but will also be shown the 'Security Warning' dialog when they try to run setup. The user could, of course, clear the 'Always ask' checkbox, or click the 'Unblock' button in the file's properties window. This would prevent Windows from bothering the user about this particular file, but there was no obvious way to stop Windows from doing this to every other file that was downloaded.
In seeking to disable this functionality, one might discover that there is a setting hidden within the Internet Options control panel's Security tab which can control the new behavior. To access it, the user would have to select the Internet Zone, and then choose "Custom" to access the list of security preferences. Changing the value of the "Launching applications and unsafe files" preference to "Enable" removes these prompts, but as the dialog box notes, is considered 'unsafe'. This setting also has the disadvantage of being a system-wide change, which is overkill if the user only wants to return Firefox's download behavior to its pre-3.0 state.
Returning to the search, one might wonder, "How does Windows know that a file has come from the internet?". A little investigation turns up the answer. On Mac OS X, downloaded files are flagged with an extended attribute, which the operating system reads and uses to determine whether it should take certain actions. As it turns out, a similar system is used in Windows. Windows does not support extended attributes in its NTFS filesystem, but it does support what are known as alternate data streams (ADS). These are hidden pieces of data that can be attached to any file stored on an NTFS-formatted drive. Using my NTFSADS tool for viewing alternate data streams, we can see what data streams are attached to a file that was just downloaded with Firefox 3.0:
A quick search for information about Zone.Identifier shows that this is an ADS that is added to files saved from the internet by Internet Explorer or Outlook. It seems that Firefox 3.0 is now doing this as well. Additionally, researching the contents of this ADS entry turns up that Zone ID 3 corresponds to the Internet Zone. This same link also gives some more information on how this ADS is added to the file:
“AES-participating applications call the Save method of IAttachmentExecute interface to add a Zone.Identifier alternate data stream to store the zone from which the file came.”
A search for this interface in the Firefox 3.0 code come up with a reference to bug 408153 which changed the save mechanism to use the IAttachmentExecute.Save method to save downloaded files so that they would be scanned by the installed antivirus software. This is what is responsible for attaching this Zone.Identifier ADS and ultimately causing the security warnings.
Reading through the comments turns up another bug, bug 412204 which contains a patch that adds an about:config preference to disable the new save behavior. Bingo! Looking at the patch, we can see that the new preference is named 'browser.download.manager.scanWhenDone'. After visiting about:config and setting this preference to false, I downloaded a .exe file and verified that Windows no longer displays its security warning. Checking out the file with NTFSADS shows no alternate data streams.
July 15, 2008
Congestion Control Algorithms for a Wireless Router
This post came out of research I did while trying to determine whether there was any advantage to switching TCP congestion control algorithms on my home wireless router (Linksys WRT350N). It turned out to be a fairly interesting topic, though it may not be applicable to anything aside from wireless routers (or other devices that concentrate traffic from both wireless and wired devices, both between each other and the Internet). If you are still interested, by all means read on.
TCP Vegas is what I would call a successor to TCP Reno/NewReno (which are the most commonly used congestion control algorithms on the net today). It uses a new method to estimate the bandwidth of the link in order to better reduce congestion and increase overall link utilization. In theory, this would be great and we would all enable Vegas right away. However, there are two issues which should be considered.
First, when a TCP Vegas connection shares a link with a TCP Reno connection (which as I said above was the most common algorithm currently in use), the Vegas connection will mistakenly detect much more congestion than actually exists, due to its interaction with how the Reno algorithm uses buffer space. The result is that the TCP Vegas connection backs off, and gets an unfairly small slice of the total available bandwidth.
Second, Vegas inherits Reno's problems when dealing with wireless networks. Basically, all these different algorithms are designed to allow many machines to communicate over TCP without overloading the bandwidth of the link between them. They watch out for packets that are never received, and interpret those missing packets as a sign that the link is congested. They then throttle down the rate at which they exchange packets so that packets are no longer being lost.
The problem with doing this over a wireless link is that, often times if a packet is lost it is not because there is congestion. Instead, it is more likely to have been a channel error (such as wireless interference, echos, etc). Westwood measures the bandwidth of the link in a way such that it is able to maintain high transfer rates when a channel error causes packet loss, but handles congestion-based losses similarly to Reno. Vegas does not have the ability to distinguish between different sources of packet loss, and so, like Reno, has significantly reduced performance on typical wireless links.
If you need to manage bandwidth between many sources on your network and assure better fairness, Vegas is excellent. However, while it may be excellent at supplementing or even replacing QoS, it will incur a penalty in available bandwidth (actually, link utilization) between your network and the Internet, and will significantly degrade overall wireless performance.