Tuesday, 23 March 2010

Website images that suck!

I don't know how much longer I can take this. Why can people not learn to use the correct image formats for the type of picture they are displaying on a web site (or any other media for that matter)?
I just visited a web site with a solid coloured logo all covered in strange artifacts because it was saved as a jpeg - it looked terrible and even the uninformed should know that it is wrong. It is then a matter of finding out why and fixing it. I also saw an advert for, amongst other things, a printing company whose graphics were messy and again covered in jpeg artifacts and when I had some business cards printed, they managed to make the small font look messy because obviously they converted the image I sent them to a jpeg and made the nice sharp card look stupid.
Right, here it is, a simple introduction to what image formats you should use and why.
It all comes down to compression or making an image take up less space by cleverly reducing the amount of information stored on your computer. Why? Well, although your computer might have loads of space, an uncompressed image (called a bitmap) can be, lets say of the order of 5 to 10 megabytes in size. While this is not massive, when this is being downloaded onto a web browser, it can be very slow and doesn't need to be this large.
How do we compress? There are two ways. The best way is called lossless compression and involves looking at areas of the same colour and rather than storing every dot (or pixel), we simply save something like '20 dots of black' (obviously not in readable text like that but in 1s and 0s), the reason this is lossless is that when we uncompress the image to print it on the screen, we get back exactly the same image we started with. Sort of like deflating a football and pumping it back up again. Logos with big solid colours will compress really well using lossless compression. Unless you have other reasons not to, use the PNG format. This handles millions of colours and can even store transparency so your image can go over something else and you can see through it!
So what else is there then? If this all sounds too good to be true, unfortunately it is when it comes to photographs. Quite simply there are not enough of the same colour pixels to compress it well using lossless compression e.g. PNG (it will save but won't be very small). For this reason, a Joint Photographic Experts Group worked out how you could compress photographs even though they have millions of dots. The result is the famous jpeg format. This format is lossy. In other words, if I compress using jpeg and then uncompress, I do NOT get the original picture but something that is acceptably close - it is a compromise. In fact, you can set the quality level so that poorer quality makes for a smaller image. This might be used for thumbnails. The main thing to remember here is that jpeg is for photographs NOT solid colour logos. If you save a solid image using jpeg, when it is uncompressed, you get those horrible feathered edges and dotty artifacts in the empty areas - something that wouldn't be noticeable on photos.
You now have no excuses:
photos = jpeg/jpg and solid colour images = png

Monday, 22 March 2010

Unable to start debugging the web server 500.19

My debugging in Visual Studio (VS2008) stopped working this morning, I think it was as a result of Windows Update on Windows 7 adding some "security updates". I run out-of-the-box VS2008 (SP1) and IIS7 built-in to Windows 7 and I didn't even get the browser, just some non-resizable window with what looked like the html source for a browser error and 500.19. After being annoyed, I decided to try it in a browser with no debugger and got some more useful information but still didn't understand what had changed (Invalid config data because I can't read it type error).
Anyway, eventually I added the IIS_IUSRS group to my code directories with read access (only) and it all started working again.
Not sure whether this permission was not required before or implied or whether one of the updates removed its permissions from everywhere but it was a bit of a pain and not obvious which 'user' the system was trying to access the data with. I assumed the debugger was running as me and I had full permission but obviously somewhere it gets changed from me to IIS_USRS!

Thursday, 18 March 2010

Prevention vs Detection

I read another story about government (or in this case the Police) adding audit trail functionality to the Police National Computer. This is being done to help detect abuse of the system.
Now audit trails are great and should be used in many databases to know actually who/what/when, however, what the government still fail to grasp is that prevention is better than detection. For instance, if you were running a banking system, you wouldn't rely on an audit trail to find out who transferred £10 million out of the bank to someone elses account, you would have a system that requires authorisation to make the transaction in the first place. Simply knowing who committed the crime will not help in the majority of cases (the accused has fled, money already spent, information already used to their benefit). This is as well as the fact that catching someone then requires legal action that may or may not work and will cost even more money.
This is a crucial principle and it is what needs to be recognised for databases that contain identity information. Saying that "we have training", or "we audit all access to the system" is quite bluntly not good enough. Once that information is stolen and sold (usually) it cannot be recovered, the damage cannot be undone, someone is left to pick up the pieces or a guilty person mascarades as an innocent person and can commit all manner of crimes.
Dear Government, this is Computer Security 101. Prevention is better than detection. If you can't prevent, don't deploy the system!

Monday, 15 March 2010

Why security is important on Intranet Apps

I have heard people say that security is not important when dealing with internal web applications, that is ones that exist behind a firewall and which are only used by employees, all of which will have a user login. The argument is that we trust our employees by and large and that the firewall means we do not have to concerned with annoymous hackers who might attack apps exposed to the www. Unfortunately this logic is ill-conceived and simply wrong. Here are some reasons why this approach is bad.
  1. Just because an app is behind a firewall doesn't make it unreachable from the net. Firewalls can sometimes be hacked, it might be disabled accidentally long enough to get to your web app at which point damage can be caused. It is like having a castle whose only defence is an outside wall. However hard it might be to penetrate, once it is, the castle falls.
  2. Although there is a general trust of employees in most companies, it is not correct to decide security policy based on this. Even employees can act maliciously or curiously and can do anything from deliberate damage to accidental damage so the system must treat them as untrusted, only giving them what they need. If something was to be changed then at least it can be narrowed down to the few people who have access to a certain part of the app. If a certain area has common access, audit all important operations so that you can tell quickly and easily who has done something. Maybe they acted ignorantly and need training, maybe they were trying to damage the system.
  3. Adding the security code to a reasonable degree is not massively difficult. Most of the information exists on the web and lots of code has already been written. Why leave it out and then potentially in the future, when exposing it to the www, would you try and retro-fit it with all the work and risk that involves. Why not put it in at the beginning. There are several reasons why an app might be exposed to the www so why base policy on the fact that it never will?
  4. Effective defence means defence-in-depth. It means you rely on several measures to protect a resource, like several walls in your castle, so that even if the outer wall is broken, you have time to counter the attack before the inner walls are broken - this is just common sense. Relying on a single defence and assuming that there is little chance of an attack is small consolation after such an attack occurs. This is worse if what you are protecting is valuable or covered by statute and where you might have to excuse your policy before a judge or enquiry.
Just think about it, read about it and do it!

Wednesday, 10 March 2010

Factory Method - Why use it? What is it for?

The factory method is a creation pattern used in software engineering. Like a lot of patterns, it is sometimes hard to understand why to use it, since it involves a little more code and doesn't seem to provide a great benefit. Here is a real-world example and a software example.
Consider the Bank of England, they produce money and distribute it to other banks/people who can then spend it at which point it will eventually end up back at a bank. Now suppose that we all had to make our own money. We would need the tools but even if it was easy, what would happen if the bank wanted to change a coin or introduce a new one? Everyone who produced coin would have to get the new tooling/instructions and this would be a headache. It would be hard and some people might carry on making the old coins and would only have a problem when they were spent. We don't do that. Money both originates from and ends up back at the banks. It is a factory method. If the bank wants to change a coin, it changes it and the new ones appear automatically. In this case old coins take time to be used up but it is relatively easy to do.
Now consider a software problem. A classic: database access. I want to call a function that calls a database function with parameters, how do I do this? The most trivial way is this:

DataAccess.CallFunction("nameOfMyProc", new SqlParameter("@Name", Value));

What is the problem with this? It assumes that we are using MS Sql Server and this will never change. It assumes that the SqlParameter constructor takes exactly 2 parameters and possibly these are valid assumptions but do not promote either re-use in other systems that might not use Sql Server and does not allow for using a different database without loads of code changes. If the SqlParameter constructor changed which is not unheard of, everything breaks. A little effort now and the factory pattern can give us the same functionality with none of these problems. We create a function in our data access class called CreateParameter and this can return an abstract base class of parameter (in my case DbParameter) so consider:

DataAccess.CallFunction("nameOfMyProc", DataAccess.CreateParam("@Name", Value));

Nothing here assumes Sql Server usage; if the 'shape' of the SqlParameter which we are actually returning from the CreateParam function changes, we can possibly keep this change hidden inside the data access layer (depending on what the new argument might be) and we can literally unplug a Sql Server layer and plugin e.g. a MySql layer instead with NO code changes outside of the DataAccess.
A lot of people would say, "we will always use Sql Server, it's not an issue" but there are many reasons why you might want or need to change in the future. Imagine someone releases a free and fully compatible database that gets rave reviews - save a few quid! Imagine for some reason that you have new database servers which are not compatible with Sql Server. Imagine you get bought out by a larger company who insists you use MySql. It would look really professional if you simply wrote another data layer and knew that it would all work!