The results are in. A big thank you to all those that provided details. To summaries the results I have taken a rough average for various part so the world and come up with the following list.

Results are listed in order of access time, so don’t email to tell me that the UK is nearer to San Francisco than Belgium!


53ms USA - West Coast
80ms USA - Mid / Canada
83ms USA - East Coast

300ms Asia - Australia
1000ms Asia - Thailand

Overall I am very happy with the results. Most of my customers will be in North America closely followed by the number from Europe. That being the case I am getting great access times for all of North America and acceptable times from Europe. Not sure what is happening in Thailand, maybe that user needs to upgrade from the current carrier pigeon service!

Now the dedicated server is up and running I would like to get an idea of how well it is responding to users. Over here in Australia it takes a whopping ~375ms to ping the server. This is mainly because of a routing problem with the Telstra internet service.

All packets are being sent from Sydney to the West coast of America. The server is located in San Francisco and so the packets should then be routed straight over to the data center. But no, instead they are going all the way to the UK!!! Once they get to the UK they are sent straight back again to the West coast and only then are they sent on to the server. This is usually around 22 hops and so it’s not surprising the ping is so slow.

Could I ask people to spend 30 seconds using the ping command to see how long it takes to reach my new server. If you could post a comment with your location (city, country) along with the ping time that would be great. Just using the following command prompt…

ping www.componentfactory.com

Thanks!

The new website had a problem with entering comments onto the blog. In fact it rejected all attempts to add comments even from me. This is now fixed so the blog is fully functional again.

Break out the Champagne!
For everybody else this is just another day on the Internet. For for me it’s the culmination of two months organization to get a new web site up and running. I have to say I am really pleased with the result. Obviously I am biased but I think it strikes a nice balance, combining a professional image with a little design flair.

Micro-Outsourcing
Two months might sound a long time to create a site that only has a dozen mostly static pages. But this is the inevitable result of micro-Outsourcing. My web designer lives in the USA and works on the project only in her spare time. So each iteration of feedback takes a couple of days to be processed if not longer. Then my flash designer lives in Italy and cannot work on the flash animation until the final design of the website is completed.

So the down side of micro-Outsourcing is the longer time frame that projects take, especially when the project involves many cycles of feedback. The up side is that it costs much less because you are only paying for the hours worked and not a fixed contract fee to a web design company. I once worked at a company that paid £60,000 (~$120,000 USD) for a couple of marketing consultants to create their site. Admittedly they wrote the copy as well as creating the actual site but even so, their site was only about the same size as this. Well, I only paid about 2% of that figure and I am happy to spend the time needed organizing the project when it results in a saving of 98%! That does not include the cost of the dedicated server that I am now using for the hosting.

Dedicated Server
Until today the web site was hosted on a shared hosting plan with one of the large American hosting companies. As a result you may have noticed that the old website was not exactly fast. You will also have noticed that whenever a new Krypton release occured the machine was bogged down serving out the installation file. Well no more, the new site is on a dedicated server and there should be enough bandwidth and performance to handle any likely load. This means I can go ahead with another feature I have wanted to add for quite some time, screencasts.

Screencasts
Currently there are only 3 screencasts on the website. I intend creating several more this week and hope to keep adding new ones over time. As a developer it is much much easier to learn how to do something from a screencasts than from documentation or from reading code. When you listen to someone walking you through the process it all makes sense in a way that a tutorial in the help never can. With the extra bandwidth on our dedicated server it is no longer a problem to host large screencast files.

If you have any particular requests for screencast topics then please let me know in the comments. I cannot promise to create them all but if there is enough demand for the same idea then it stands a good chance of making the list.

What is the difference between a strong signed assembly and a publisher certified assembly?

Strong Signed
To strong sign an assembly you need to generate an encryption key and use this key to sign the assembly. The signing process generates a hash of the generated code and attaches this using the key to the end of the assembly. Whenever the CLR loads the assembly it notices the signing information and uses it to check that the code generates the same hash code as when it was originally compiled. If the hash code no longer matches then the assembly has been tampered with and so the CLR refuses to load it.

Placing an assembly into the global assembly cache (GAC) requires you strong sign the assembly. This is a reasonable precaution because there might be many different applications that are using the GAC assembly and you want to be sure it has not been modified to inject some malicious code.

However, just signing the assembly is not very secure. Anyone can remove the signing information from an assembly, modify the assembly and then sign it again. They cannot sign it with the same original encryption key because, hopefully, that is safely tucked away at the publishers. But they can generate a new key and use that is sign it with instead.

So the second half of the equation is the reference in the calling assembly. When the calling assembly was compiled it embedded a public token for the signed assembly into its reference information. So now when the application loads it not only knows the name of the assembly it wants to load but also it knows that it should be signed with a particular key.

This prevents the attack just mentioned. If someone takes the System.Windows.Forms assembly in the GAC, injects some dodgy code and then resigns it your application is protected. Your application starts up but the CLR loader says the GAC assembly is not signed with the right key to match the one you expected from compile time. Hey presto the load fails and you know something is wrong.

Publisher Signing
The internet adds a whole new level of threat to your machine. Any bored developer could write a Trojan horse application and offer it for download from a benign looking website. That free Spyware Remover application actually installs a key logger to grab your bank account details. They have signed all the assemblies in the application so it looks well behaved. But all the signing does is tell you the Trojan horse application is intact and in the original condition intended by the nefarious developer!

This is where the trust based security model comes into play. Whenever you download an application, or installer, from the internet and then try to run it Windows will tell show you a warning. Asking you if you really want to run this software and then present you with information about the publisher of the software. If you trust the publisher then you would let it run, it you don’t trust the publisher or if there is no publisher details at all then you should not run it.

As a publisher you can get hold of a publisher certificate from one of the big providers such as VeriSign and use that to sign the application/installer. Then the downloader gets shown you publisher details and can be sure it is from a trusted source and has also not been tampered with since it was created.

Component Factory has its own certificate from VeriSign and we sign all our installers so you can be sure it is in the original intended state and has not been tampered with.

Publisher Signing Assemblies
As well as publisher signing your application/installer you should also publisher sign all of the individual assemblies as well. This has a couple of benefits.

First of all the end user can right click any of your assemblies and see that it is signed and examine the certificate details. This should give them a nice cozy feeling and allow your support people to show that it is not your assembly that has been hacked on your end users infected machine.

But the most important benefit is that it allows your assemblies to be used by an application that is undergoing Vista certification. The certification requirements to get the Vista logo require that your application, and crucially all the assemblies that it references, be publisher signed. As a component vendor it is essential that our own assemblies are therefore signed so that applications built by our customers can pass the logo requirements.

Component Factory Assemblies
This requirement only came to light today when a customer needed publisher signed copies of the Krypton 2.5.1 release so they could progress with Vista logo certification. If you also need them just fire off an email to use and we can provide them on demand. All future releases of Krypton will have them signed automatically as part of the build process.