Brilliant Thinking

Back in August 2005 I wrote a piece on the relative security of Linux versus Windows (ie open source versus proprietary) systems in an article entitled “There are no pickpockets in the desert“. The premise of the article was that open source systems appeared to be more secure because they had not yet had the attention that proprietary systems had had for hacks and cracks. In other words, the hackers had not ventured out en masse into the untapped desert of open source systems.

In November 2005, the Lupper Worm (a significant Linux security vulnerability) was revealed (see “The tip of the iceberg“) and in February 2006 I wrote about “PHP Apps a growing target for hackers“. The trend was clear that open source systems, and particularly PHP applications, were less secure than first thought.

In an article dated 21st December 2006, The Register scrutinised PHP Security to attempt to better understand why this trend is happening and why PHP is less secure that once thought. So it appears now that the hackers have ventured en masse into the desert of PHP applications.

The article raises a number of key points which need to be understood to dispel any myth or bad press that PHP may well receive through misquoting. The main point is:

The majority of security flaws detected in applications written in PHP are not as a result of the language itself, but how it has been used by the developer to build the application.

To quote from the article:

A search of the database, maintained by the National Institute of Standards and Technology (NIST), found that web applications written in PHP likely account for 43 per cent of the security issues found so far in 2006, up from 29 per cent in 2005. While flaws in the language itself account for a very small percentage the total, the problems with PHP underscore the difficulty that developers - many of them amateurs - have in locking down applications written in the language, said Peter Mell, senior computer scientist for the NIST and the program manager for the National Vulnerability Database.

The message to clients is very clear - security is paramount on the Web and it is more complex to build better security in a web application than it is in a standalone desktop application by the virtue that the website (application) is exposed to anybody and everybody 24 hours a day, 7 days a week, 365 days a year.

So, is ASP or .NET inherently any more secure? Some would argue that this is the case, but it is actually the Web environment itself that creates many of the security issues and not the language itself. Here are some of the top security issues that affect a Web application:

• Cross Site Scripting (XSS): This is where a hacker uses a script to auto-complete forms on your site to add information to your web site. This is a common technique that hackers use to post spam to forums or via your “contact us” form.
• SQL Injection: This is where a hacker abuses a form on your website (often login forms) to append database code to the script and reveal information about your users, and/or change or delete data.
• Data Validation: Any information input into a form or appended to the query string needs to be checked and double checked. If it’s not in the range that’s expected the application will have undesirable reactions (see SQL Injection above for example).
• Don’t store passwords as plain text: This may be “nice” because it’s easy to look up a password, but it’s also easy for hackers to do this. Always encrypt passwords.
• Encrypt sensitive data: Even outside of the database! Any sensitive data should be encrypted (or at the very least obfuscated) to avoid discovery or abuse. However, on virtual hosting systems (see “Types of Hosting“) this is not always possible due to the security restrictions that ISPs impose on you to prevent their systems being hacked.
• Do some server housekeeping: Check the settings and make sure the server is set up securely - for example turn “safe mode” on (for PHP) and restrict other unnecessary services.
• Use sessions: If you need to store data securely, use server-side sessions to handle this. However, don’t use cookie-less sessions as this exposes you to session hijacking. A standard cookie-based approach is recommended as no sensitive data sits on the visitors machine, but the session is secured to their visit only. A cookie-less session means that the session data can be easily exposed.

The key thing to ensure is that any web application development takes into account these security issues (and any others the client’s particular application requires) and builds in a secure architecture. Remember that integrating any third-party applications (such as phpBB, the open source forum system) may expose you to unexpected security vulnerabilities and/or require constant upgrades to keep ahead of the security problems that may be found with such applications. For PHP, the book “Essential PHP Security“, written by the internationally recognised PHP security expert Chris Shiflett and published by O’Reilly, provides an excellent synopsis of the key security issues affecting PHP applications and their hosting environment, as well as a recipe book of methods for how to deal with them.

You may initially be shocked at the cost of what appears to be a small web system, but the cost of a lack of security for your business may prove to be more expensive in the long run. Once you get beyond a basic Level 2 marketing site (simple meaning not requiring a database or forms) on our Internet Maturity Model, you need to consider security seriously.

It’s been everywhere for a long time, but in places other than the desktop the Web has been an elusive medium. The main reasons behind this are the varying support of the myriad devices used to access it (e.g. mobile phones, hand-held devices such as palmtops) and the lack of availability of a suitable connection.

As we sit on the cusp of 2007 we can look forward to the Web being more readily accessible on our old friend the television (see also “battle for the living room“). With Microsoft’s Xbox 360 already capable of Internet access and bundled with an Ethernet port ready for high speed web access, Nintendo’s Wii gaining a variant of the Opera browser and Sony’s forthcoming Playstation 3 also being web enabled, we can look forward to more people using their entertainment console and their TV to access the Web.

While most of this access will be for game, video, film and on-demand TV content initially, the capability and bandwidth is now in place to make using the TV a viable mechanism to access the Web. Add to this the growing number of Portable Media Players (PMPs) which are becoming web-enabled with built-in browser software (such as Archos) and we have a wider array of devices capable of connecting to the Internet. The growing ubiquity of wireless access also allows these new devices more freedom to roam and encourages people to make use of the Web wherever they are and on whichever device they choose.

Fortunately the technological barriers that many of what used to be called “edge” devices (because they were on the “edge” of the network or the “bleeding edge” of technology) are also being removed making it easier to get access without needing a PhD to figure out how to configure the settings. Mobile networks such as 3 (three.co.uk) have also introduced flat-fee Internet access meaning you don’t pay extortionate charges for surfing the web with your mobile.

The end result: ease of use and practical access from anywhere.

But does it mean we will?

We will see a growing trend in access from devices other than the desktop, with wireless and mobile access from a laptop leading the field (as it has been) for true Web access. New portable devices such as Nokia’s E61, Archos and Sony’s PSP will start to feature as Internet devices, although the latter 2 will be more media surfing machines rather than devices people might use to go shopping, check the next train home or check the latest news. Home entertainment consoles will lead the foray into making the home a networked environment with access to the Web, but again it will be media led rather than general surfing.

However, with the ability to contextually link content within media streamed to the home entertainment system to content on the Web, it won’t be long before we are buying the products we see placed in our favourite TV programmes with just the touch of a (red) button in much the same way that we can access additional content via the (red) button on our remote today.

The technological tipping point is already here, but the cultural one is some way behind - people will need to have (or be influenced to have) the desire to surf the web using devices other than the desktop before they actually do. The networked future portrayed in films such as The Truman Show, Demolition Man, and Minority Report is not far ahead of us and we should look to steer our Web presence towards the inevitable future.

Shoppers are likely to abandon a (shopping) website if it takes longer than four seconds to load, a survey suggests. The research published by Akamai in November 2006 revealed users’ dwindling patience with websites that take time to show up. The time it took a site to appear on screen came second only to high prices and shipping costs in the list of shoppers’ pet-hates.

Akamai consulted those who shop regularly online to find out what they like and dislike about e-tailing sites. About half of mature net-shoppers - who have been buying online for more than two years or who spend more than $1,500 (£788) a year online - ranked page-loading time as a priority.

Of the 1,058 people interviewed in the first 6 months of 2006:

• 75% would not return to websites that took longer than four seconds to load;
• One-third abandon sites that take time to load, are hard to navigate or take too long to handle the checkout process;
• About 30% said they formed a “negative perception” of a company with a badly put-together site and would tell their family and friends about their experiences.

The last finding is important because the research found that the experience shoppers have on a retail site colours their entire view of the company behind it. In other words, if your site is poorly constructed, badly designed and loads slowly, you’ll guarantee yourself less sales and have a hard job convincing people to come back due to the negative PR you’ll generate.

Companies in the UK must include certain regulatory information on their websites and in their email footers before 1 January 2007 or they will breach the Companies Act and risk a fine.

Every company should list its company registration number, place of registration, and registered office address on its website as a result of an update to the legislation of 1985. The information, which must be in legible characters, should also appear on order forms and in emails. Such information is already required on “business letters” but the duty is being extended to websites, order forms and electronic documents.

The change is being made by a Statutory Instrument to implement a European law, the First Company Law Amendment Directive, into UK law. According to a Department of Trade and Industry spokesperson, the law will take effect on 1 January, one day later than the Directive requires.

The information is expected to appear in the footer of every email sent from a company, to avoid having to decide whether each email amounts to a “business letter” or not. Many companies do this already because the term “business letters” was thought likely to include emails even without this new clarification.

For websites, contrary to the fears of some, the specified information does not need to appear on every page. Again, many websites will already list the required information, perhaps on their “About us” or “Legal info” pages.

The Ecommerce Regulations, passed in 2002, require that certain information is listed on a website, including, “where the service provider is registered in a trade or similar register available to the public, details of the register in which the service provider is entered and his registration number, or equivalent means of identification in that register”.

That has been understood as including the company registration number and place of registration. The Ecommerce Regulations also required a note of “the geographic address at which the service provider is established” – which many have taken to mean the registered office address.

However, the wording in the Ecommerce Regulations is ambiguous compared to the new provisions. Further, many organisations’ sites currently omit the information, perhaps making the mistake of thinking that the Ecommerce Regulations do not apply to websites that do not sell online (in fact they apply to almost all websites).

Information that must be on your website
The following is the minimum information that must be on any company’s website (from OUT-LAW’s guide, The UK’s Ecommerce Regulations).

• The name, geographic address and email address of your company.
• The name of the organisation with which the customer is contracting must be given. This might differ from your trading name. Any such difference should be explained – e.g. “XYZ.com is the trading name of XYZ Enterprises Limited.”

It is not sufficient to include a ‘contact us’ form without also providing an email address and geographic address somewhere easily accessible on the site. A PO Box is unlikely to suffice as a geographic address; but a registered office address would. If the business is a company, the registered office address must be included.

• If a company, the company’s registration number should be given and, under the Companies Act, the place of registation should be stated (e.g. “XYZ Enterprises Limited is a company registered in England and Wales with company number 1234567″)
• If the business is a member of a trade or professional association, membership details, including any registration number, should be provided.
• If the business has a VAT number, it should be stated – even if the website is not being used for e-commerce transactions.
• Prices on the website must be clear and unambiguous. Also, state whether prices are inclusive of tax and delivery costs.

Finally, do not forget the Distance Selling Regulations which contain other information requirements for online businesses that sell to consumers (B2C, as opposed to B2B, sales). For details of these requirements, see out-law.com’s guide, The Distance Selling Regulations - An Overview.

For help with email notices, such as disclaimers, see OUT-LAW’s guide on Email notices.

I have been reading the Transcending CSS book mentioned in an earlier post - it’s an excellent book - and it’s nice to know it’s not just me that struggles with the outdated ideas of some clients that the presentation of a website should be identical across the main browser platforms (including Mac IE5.5, although this is largely considered an obsolete platform by most agencies). My own view is that the presentation should be as close as possible, but, with so many browser variants and no actual control of how the site visitor sets up their viewing configuration (using their own fonts, different screen widths, etc, etc) we need to accommodate this fluidity and not attempt to override it. Writing on this subject back in February, Nate Koechley of Yahoo! puts it very succinctly:

Support does not mean that everybody gets the same thing. Expecting two users using different browser software to have an identical experience fails to embrace or acknowledge the heterogeneous essence of the Web. In fact, requiring the same experience for all users creates a barrier to participation. Availability and accessibility of content should be our key priority.

– Nate Koechley
http://developer.yahoo.com/yui/articles/gbs/gbs.html

Koechly’s article makes it clear that it is neither possible nor desirable for people accessing Web content using different browsing technologies or devices to expect the to receive the same design. After all, a person will have a different experience browsing the Web using a large desktop monitor than someone using the small screen of a handheld PDA or mobile phone. Extending that notion to browser versions is only one small step.

The challenge when creating a brief for a project is to be as inclusive as possible, but also realise that the range of support provided for various devices is something that needs to be defined and not an assumption that all devices will be supported by default once the site is developed. Each viewing platform will require its own considerations in the CSS and mark-up to ensure suitable presentation, and assuming that a potentially infinite array of viewing platforms will all be supported is unrealistic (not to mention expensive). Most of our clients work on the basis of “it should work on Macs and PCs” which often includes FireFox and Internet Explorer (on the PC) and Safari and IE5.5 (on the Mac). But what of Opera? And which version of IE on the PC (now that IE7 has been released and is a mandatory download)?

Fortunately, the major browsers listed above are similar in their interpretation of the fundamental styling capabilities of a web page and this can allow us to create the client’s desired homogeneity across the platforms, but the CSS specification goes much further and allows us to create a better experience for people with more compliant or capable browsers. Unfortunately, these features are rarely used as clients are often looking at the lowest common denominator instead of a graceful degrading approach that allows us to create the preferred experience which also degrades nicely so that people using other configurations can still access the content.

If you want the best solution, make sure you find an agency or freelancer who understands the principles of CSS from both a visual and a technical viewpoint. It’s one thing to be able to recreate a design using CSS from a technical standpoint, but it’s another to be able to understand the visual goals and bridge the gap between concept and representation. Remember that even the design itself should encompass the capabilities of the underlying (CSS) technology and not simply assume that the design can be translated.