Google homepage now also reads ""New! Download Chrome (BETA) - the new browser from Google"





The web browser with no chrome is Google's fresh take on the browser. It does however have a chrome, but it doesn't try to stand out and get in your way.

This browser has been built from scratch; the Google Chrome comic strip explains the concepts that lay behind it and how and why things were done. Its a is a quick and easy way to understand what is different about Google Chrome.

Although Chrome may not have set any world download records today, I'm sure it's not going to be long before we start seeing this Google Chrome user agent making significant inroads into website stat logs.

It's probably safe to say that the browser wars have becoming really intense with Google joining in. So I guess the next question is, for how long will Google continue its funding of Firefox?

Those nasty SQL Injection attacks have not stopped. They’ve probably just started!

If you’re still in the process of going through your SQL code and making sure it’s not susceptible to SQL injection attacks that means your websites are still wide open to the attack.

However not to worry, the Microsoft IIS team has come to the rescue with the announcing of the shiny new Microsoft Urlscan Filter v3.0 Beta release. It includes a GoLive license, so you can deploy it on your production servers.

Here are some of the cool new features:

• Support for query string scanning, including an option to scan an un-escaped version of the query string.
• Change notification for configuration (no more restarts for most settings.)
• UrlScan can be installed as a site filter.  Different sites can have their own copy, with their own configuration.
• Escape sequences can be used in the configuration file to express CRLF, a semicolon (normally a comment delimiter) or unprintable characters in rules.
• Custom rules can be created to scan the URL, query string, a particular header, all headers or combination of these.  The rules can be applied based on the type of file requested.

One thing important to remember is although this will protect websites against this latest form of SQL injection attack, any poorly written code still needs to be fixed. No escaping on that.

 

 

Firefox Download Day is here. Download Firefox 3 today! Help set a World Record and make history!

Is your free disk space gradually vanishing after installing Symantec Endpoint Protection (SEP)?

If you have noticed this, check out the following locations on your hard drive

on Windows Vista:
[installed drive]:\ProgramData\Symantec\Definitions\VirusDefs  

or on older Microsoft OS versions such as Windows XP Windows 2000:
[installed drive]:\Program Files\Common Files\Symantec Shared\VirusDefs

If it looks like this:

you may need to update your Symantec Endpoint Protection installation to Maintenance Release 2 (MR2).

I came across this problem while rolling out Symantec Endpoint Protection 11.0 on a portion of our network. Oddly enough the client PC's SEP installation (after updating to the latest virus definitions) had taken upto 2~3 GB of hard disk space! Something was wrong or at least I thought so. After a quick check with SpaceMonger my suspicions were justified. It showed the culprit being the virus definitions folder, which contained hundreds of tmp*.tmp folders taking up more than a GB of disk space!

A quick look in the Symantec knowledge base told me that this was a common problem and that Symatec Endpoint Protection had just released its MR2 which has fixed this and many other issues according to the release notes.

You can check your installed version by clicking on "About" in the "Help and Support" icon on the SEP client interface. If the version number is lower than 11.0.2000.1567 you don't have SEP MR2 so you'll need to upgrade.

Upgrading is pretty straight forward. There is even an easy to follow step-by-step migration guide available. So start you upgrade now.

However, upgrading will not get rid of all the tmp*.tmp folders that already exist, you'll need to delete them on your own.

Recently a friend of mine complained that he was unable to login into his PC. Windows kept logging him out just after validating the user name and password.

In summary this is what happened (Windows XP Professional)
-Booted up the PC. The Windows login screen appears without any problem.
-Entered valid domain accounts/local accounts with and without administrative privileges
-Credentials got validated.
-Immediately after, Windows started logging out.

Booting up in "Last Known Good Configuration", "Safe Mode" and "Safe Mode with Command Prompt" or remotely connecting via "Remote Desktop" all had the same problem.

Since this PC was connected to a LAN, it was possible to remotely connect to the Windows "Event Viewer" to see what could be happening, but unfortunately it didn't reveal any secrets. Connecting remotely to the Windows "Registry" of the effected PC was however much more productive; after a little bit of looking around I found an empty value for the Userinit entry. Adding it back solved the problem. If this happened on a PC that is not connected to a network, there is another way to fix the missing entry by getting windows to add the missing "userinit.exe" entry while booting up.

---
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"Userinit"="C:\\Windows\\system32\\userinit.exe,"
---

This is what was happening: When a user presses CTRL+ALT+DEL and enters their username and password, the Windows Graphical Identification and Authentication component (GINA) will get an authentication package to verify the credentials and establish a session. Then GINA passes on the job of setting up the user environment to the programs specified in the WinLogon's registry key for "Userinit". Usually that would be "C:\WINDOWS\system32\userinit.exe,". So, with no program specified to do the setting up, you immediately get logged out again.

The Sri Lanka Telecom (SLT) website www.slt.lk has been infected with a Trojan Virus Trojan.Maliframe!html. If you don't believe that the telecoms giant is compromised, here is a screen-shot showing the Trojan virus infected web page.

The risk level of this particular virus has been rated as a very low by Symantec, however considering the number of Internet users in Sri Lanka that visit the SLT website the risk may be a little bit higher than that for us Sri Lankans. I hope SLT doesn't think otherwise. I've emailed them, lets see.

This incident reminded me of something I had read sometime ago. It was about Google notifying its users of potentially dangerous websites on its search results page. I had to find out if it worked; so I typed "Sri Lanka Telecom" on Google. Surely enough Google was on the ball. 

What about Microsoft's live search or Yahoo!, will they do the same? I typed in the same search in them; sadly they were still unaware of the danger.

However this problem of preventing websites from harming its visitors isn't fully solved yet. Although the search results indicate the potential harm, almost all Internet users in Sri Lanka know the SLT Telecom website URL by heart and don't need to search for it. They will never see this warning. Virus guards are good. But they will only let you know only after something tries to harm you.

This is where something like the Google toolbar could improve. Google can take it to the next level by improving its "Safe Browsing" feature to not only warns us against Phishing attacks but to also warn against potentially dangerous websites by alerting us before taking us to the website.

Have you ever run command line programs that claimed to be "too big to fit in memory"? I have.

Recently when I ran the cmd line tool gacutil.exe (Global Assembly Cache Utility) to install a .NET assembly I came across a message saying "Program too big to fit in memory". It was strange because the error came on a machine that had enough free RAM (~2GB) and HD space on it. Surely the gacutil.exe doesn't need that much memory!

Microsoft kb 316573 article says that this kind of error could happen for a Visual Studio .NET product installation file from the MSDN Web site if the installation file was corrupted during the download or the installation file is not complete.

A quick look at the file properties of the gacutil.exe showed that the one I was trying to run was corrupt. So the problem was easily fixed. But the question remained as to why the error message said what it did. It should have said the program may be corrupt?

A quick search on Google solved the mystery. The "Program too big to fit in memory" error comes if any one of the following is true
1) The part of the program header that should tell the memory requirements where indicating absurd values 
2) The header contains no memory requirement; in which case the program should fit in a 64KB chunk of memory.

More details here http://blogs.msdn.com/oldnewthing/archive/2006/01/30/519388.aspx

We can easily check out the second case by renaming a file (say a text file) to .exe. If the file is larger then 64KB you'd see the "Program too big to fit in memory" error and a "...is not a valid Win32 application" error if it were less.

 

I've been running the released version of DasBlog 1.9 [DasBlog 1.9.6264] from just about the time it was released (on the 264th day of 2006). It’s been more than six months and I finally do have my SLT ADSL connection, so I upgraded my blog to one of the more recent DasBlog daily builds.

One of the more attractive new features I noticed at once was under the “Spammer Settings“. It is that DasBlog now supports the comment spam killer Akismet.

What’s cool about it is that its free for personal use, so to get this working in DasBlog all you need to do is get yourself something called an "API key" to activate and use it.

To get a key:
 1) Logging to your WordPress.com account or Create yourself an account (creating an account only would do, without creating a blog).
 2) Go to "Your profile" (“Your profile” is located under "Users")
 3) Copy your WordPress.Com API key from it.

So, after you have your key in the DasBlog Akismet configuration and have things working; when a comment is made DasBlog will submit it to the Akismet web service which in-turn will tell DasBlog if its spam or not.

After having it setup I tried it out by entering a “spammy” comment. After submitting the comment I saw a message saying “Your comment has been received and is under review for potential violation of site guidelines. Do not re-submit.”, so I guess its all good. 

On the other-hand spammers will keep re-submitting till one gets through; because its not like they will listen just because we say to what we say "Do not re-submit"! However Akismet sounds very confident when it says:

"...without giving too much of the secret sauce away, we can safely say that it would be pretty difficult to poison Akismet. We use dozens of factors to determine the spamminess of a submission, and we also have an identity attached to everyone using and contributing to the system, which allows us to do some interesting things with weighting and clustering activity."

Very feisty, I love it.

Google shifted gears to venture a little deeper into the desktop by launching Google Gears(Beta), an exciting and new open source project that will bring offline capabilities to web applications via a browser extension. Google Reader was the first to put this new technology into use with an offline mode.

"Google Gears builds on the web's existing programming model by introducing new JavaScript APIs for sophisticated data storage, application caching, and multi-threading features. With these APIs, developers can bring offline capabilities to even their most complex web applications. Google Gears works with all major browsers on all major platforms: Windows, Mac and Linux." - Google Press Center

Google Docs and Gmail seem to be the other obvious candidates to enable offline capabilities. This also means a "Google Office" product could be just around the corner. However, even if there eventually is such a product I don't think its going to compete with the likes of MS Office but instead cater to a different section of end users with different needs.

Recently I had some time to look into the built-in HTTP compression abilities that IIS6 has. I was impressed to find that IIS6 is very much capable in handling compression than what meets the eye. So be deceived by the 2 checkboxes that the IIS management GUI shows for HTTP compression (screenshot below); it is nothing but a hint of what can be done.

There seemed to be too much incorrect/misleading information floating around on this subject, especially about things like needing "Web Service Extension" and about dynamic compression not working without enabling static compression and so on, so let’s try to clear things up a bit.

When we make a request for a web page, our browser needs to tell types of compressions schemes it understands and accepts (if any) via a header such as 'Accept-Encoding: gzip' [or 'Accept-Encoding: gzip,deflate' if it supports both gzip and deflate and so on.]. If the browser does not tell IIS this, IIS will only send the raw files as they are. It's the same for any client application that requests for content from a web server.

Now, assuming a request has been made from a client that supports compression, let's take a look at a simplified summary of what happens with IIS.

If the requested page was for dynamic content:
IIS compresses the response and sends the compressed response to the client if the following are true
* If 'Compress application files' is enabled [HcDoDynamicCompression="TRUE" at server level or DoDynamicCompression="TRUE" at file/folder level] 
* If IIS is able to compress the requested file type using the particular compression scheme the client supports  ['HcScriptFileExtensions'] 
It's also important to note that a copy of the compressed file will not be cached, so the compression has to take place for each request which costs CPU resources of the server.

If the request for static content:
IIS will send a compressed responce only if the following are true
* If 'Compress static files' is enabled [HcDoDynamicCompression="TRUE" at server level or DoStaticCompression="TRUE" at file/folder level]
* If IIS is able to compress the requested file type using the particular compression scheme the client supports ['HcFileExtensions']
* A valid compressed version of the requested file is already available in the 'Temporary directory' [HcCompressionDirectory].
If a valid compressed version of the requested file is not available, IIS will send a uncompressed version of the requested file to the client, after which it will check if the compresssion scheme is to compress static content on demand [HcDoOnDemandCompression="TRUE"]. If it is, IIS will start a background thread to compresses the requested file and store in the 'Temporary directory' to serve for future requests.

Now let's look at how we can configure all the stuff we talked about above. We can't do much with the GUI we have got with IIS6 for configuring compression.

GUI for the IIS6 HTTP compression configuration
[Web sites -> Properties -> Service tab]

This means that we'll need to get into the configuration settings inside the Metabase.xml file located at "%windir%\system32\inetsrv\Metabase.xml" to get compression working properly.

There are a couple of ways to edit this file; we could use the adsutil.vbs, or directly open the file in a text editor and edit it. However, before directly editing this file while IIS is running, we have to make sure that we've enabled direct metabase edit.

Like we talked about earlier, the client must first let the server know what compression methods its cable of handling, if the server also knows how to compress in a method that the client understands compression can happen. IIS by default supports both gzip and deflate compression schemes.

The following nodes in the Metabase.xml file is where you can configure how each of these compression schemes work.

<IIsCompressionScheme Location ="/LM/W3SVC/Filters/Compression/deflate"
     HcCompressionDll="%windir%\system32\inetsrv\gzip.dll"
     HcCreateFlags="0"
     HcDoDynamicCompression="TRUE"
     HcDoOnDemandCompression="TRUE"
     HcDoStaticCompression="FALSE"
     HcDynamicCompressionLevel="0"
     HcFileExtensions="htm
            html
            txt"
     HcOnDemandCompLevel="10"
     HcPriority="1"
     HcScriptFileExtensions="asp
            dll
            exe"
    >
</IIsCompressionScheme>
<IIsCompressionScheme Location ="/LM/W3SVC/Filters/Compression/gzip"
     HcCompressionDll="%windir%\system32\inetsrv\gzip.dll"
     HcCreateFlags="1"
     HcDoDynamicCompression="TRUE"
     HcDoOnDemandCompression="TRUE"
     HcDoStaticCompression="TRUE"
     HcDynamicCompressionLevel="0"
     HcFileExtensions="htm
            html
            txt"
     HcOnDemandCompLevel="10"
     HcPriority="1"
     HcScriptFileExtensions="asp
            dll
            exe"
    >
</IIsCompressionScheme>

We need to tell the types of extensions that each scheme is to support and compress. The static types need to go under the 'HcFileExtensions' and the dynamic under 'HcScriptFileExtensions'. You'd probably want to get aspx, and asmx extensions also under 'HcScriptFileExtensions' in addition to the defaults. xml, css and even consider adding 'deploy' files if you have clickOnce under the 'HcFileExtensions'. We need to add this for both gzip and deflate compression schemes (or you could add it to only one if you don't want a particular compression scheme to support that extension.

If you'd like to use the adsutil.vbs to set these values here is an example to add static file types css, xml, htm, and txt to the gzip compression scheme:

cscript adsutil.vbs set /w3svc/filters/compression/gzip/HcFileExtensions "css" "xml" "htm" "txt"

to view the change:
cscript adsutil.vbs get /w3svc/filters/compression/gzip/HcFileExtensions

The level of compression for dynamic content is set to 0 by default. This could be increased to a maximum of 10 depending on your available CPU resources. Generally setting it to 10 is bad; in most cases it will have a negative impact on your throughput. This is something you'd need to do some test to figure out what works best for you. It's also worth noting that setting it to 0 does not mean no compression, it just is a lower compression (which also means it will be the fastest).

Now that we've got the two compression methods configured let's take a look at the 'IIsCompressionSchemes' node, this is what basically sets up the server-wide HTTP compression configuration settings.

<IIsCompressionSchemes Location ="/LM/W3SVC/Filters/Compression/Parameters"
    HcCacheControlHeader="max-age=86400"
    HcCompressionBufferSize="8192"
    HcCompressionDirectory="%windir%\IIS Temporary Compressed Files"
    HcDoDiskSpaceLimiting="FALSE"
    HcDoDynamicCompression="FALSE"
    HcDoOnDemandCompression="TRUE"
    HcDoStaticCompression="FALSE"
    HcExpiresHeader="Wed, 01 Jan 1997 12:00:00 GMT"
    HcFilesDeletedPerDiskFree="256"
    HcIoBufferSize="8192"
    HcMaxDiskSpaceUsage="100000000"
    HcMaxQueueLength="1000"
    HcMinFileSizeForComp="1"
    HcNoCompressionForHttp10="TRUE"
    HcNoCompressionForProxies="TRUE"
    HcNoCompressionForRange="FALSE"
    HcSendCacheHeaders="FALSE"
   >
</IIsCompressionSchemes>

If you'd like to enable compression server wide, we can change HcDoDynamicCompression="FALSE" to "TRUE" for dynamic content and HcDoStaticCompression="FALSE" to "TRUE" for static content. However, if we don't want to enable http compression server wide, we simply leave these as "FALSE" and add a property DoStaticCompression="TRUE" and/or DoDynamicCompression="TRUE" to the specific file or folder properties in the metabase where you'd like to enable compression.

For example if you we want to enable http compression on a virtual directory called "CompressMe" under your "Default Web Site", we'd simply locate the following node in theMetabase.xml file:

<IIsWebVirtualDir Location ="/LM/W3SVC/1/ROOT/CompressMe"
  AccessFlags="AccessRead"
  DirBrowseFlags="DirBrowseShowDate | DirBrowseShowTime | DirBrowseShowSize | DirBrowseShowExtension | DirBrowseShowLongDate | EnableDefaultDoc"
  Path="C:\Inetpub\CompressMe"
 >

and add the property DoStaticCompression="TRUE" as follows:

<IIsWebVirtualDir Location ="/LM/W3SVC/1/ROOT/CompressMe"
  AccessFlags="AccessRead"
  DirBrowseFlags="DirBrowseShowDate | DirBrowseShowTime | DirBrowseShowSize | DirBrowseShowExtension | DirBrowseShowLongDate | EnableDefaultDoc"
  DoStaticCompression="TRUE"
  Path="C:\Inetpub\CompressMe"
 >

If a node does not exist for the folder you're trying to configure, you could simply add a node manually, or make IIS add it for you using a small trick. What we do is change a property for the required file/folder and then undo the change. For example for a folder we could just enable "Directory browsing" and then disable it again. Restart IIS and it would have created a node for you in the Metabase.xml file.

Well that should get compression to work, but as you can see lots of other configuration parameters that you could configure to get the best out of your server.

A lot of the above has changed with IIS7. Static compression is even enabled by default!

Happy compressing!