Siu Lun

So I was telling you how great a image text replacement library Facelift is. However, I’ve been dealing with it in the past couple of hours as there was bugs in the beta files.

After taking a look at the codes and also at the forum over at Mawhorter.net, I don’t mean to be prejudice but the code is not great and the creator doesn’t seem to be fixing much of the bugs in good time.

A huge amount of coding has problems with it and a lot of people have contributed fixes.

Anyway, it’s a project that seems to be maintained when I feel like it.

Not to mention, this is the killer part, that Facelift is licensed under GPL v3. I don’t think GPL is suitable for any web programming libraries, it needs to be LGPL or lesser restrictive and viral ones. AFAIK it means if you use Facelift you have to also make ‘avaliable’ the rest of the coding. Which just doesn’t work well.

Someone should do a better version.

Later

Facelift, it’s nothing new, been out for a while now, but why blog about it?

For one, I just want to give it more coverage, because it is a great alternative to SIFR, the other font replacement technique used in today’s websites.

I don’t think I need to advertise it more, if you want more information I’m sure you can look it up yourselves.

I do want to document a problem however with Facelift as I’m using it for a project at the moment.

Facelift currently does not work with PHP 5.3. This is because PHP 5.3 has a bug that prevents it from operating properly. More specifically it is to do with the bounding box calculation used in the GD library. This bug is supposedly fixed in the latest SVN but PHP has not yet released a production ready fix yet. So we have to spray and prey for now.

Later

I can almost garuntee you that most if not all, web development house do not perform security testing as part of the service to customers.

And

The reason being that this would drive the cost of the site up, and it is passed on to the customers. This means it would make their quote less attractive to potential customers.

But to be honest, unless you’re doing a simple html based website. You have to test for security. I know, a lot of it is actually down to the quality of developers to get it right first time.

The use of automated scanners are more and more common, but can they be relied upon? No. How would automated scanners be able to differentiate an unsuccessful $_POST / $_GET request? They can’t, they’re just programmed to do the testing based on most common methodologies. Therefore they’re not reliable.

Security scanners used in e-commerce sites like mcafee secure does help in detecting breaches of security, but does not prevent it from happening in the first place. It tries to by informing the administrators of potential security issues with software versions etc… used on the host, but if it happens, it happens.

Real security audit can only be done by the developers themselves having gone through or know of hacking methods. Even then, it is not 100% bullet proof. I guess that’s why there are companies out there that are basically formed by a group of hackers whom sole job is to attempt hacking everything.

These people unfortunately are far and few between.

The only thing that we web developers that cares can do is to quote like the nubins, then advice clients to take on security audits. There is so many security holes on the web. It’s practically a treasure trove for data theifs/pirates.

One common example: A member’s login/registration should always use SSL, but the number of websites that don’t do that is phenomenal. This means member’s passwords can be easily sniffed by intercepting network traffic.

Another example of the same problem: E-mails, e-mails are sent over the net in plain-text, unless you’ve encrypted it. Therefore they’re always interceptable. I have set up a PGP, but none of my clients know of it or would be able to handle using it, which means, I can’t use it.