Last month I described the ability to track users sessions with browser data. A recent posting on IT Law in Ireland highlighted a series of blog posts elsewhere that give further insight into what is possible.

Well, I just got round to reading them properly. The posts on Freedom to Tinker by David Robinson and Harlan Yu are:

• Identifying John Doe: It might be easier than you think
• What Third Parties Know About John Doe
• The Traceability of an Anonymous Online Comment

The conclusion? It is possible to trace and identify individuals easier than you may think. We are dropping evidence like dead skin cells as we traverse the internet. Fact or fiction? Well the US Defense Advanced Research Projects Agency (DARPA) are taking it seriously with a recent call for research into cyber genetics, cyber anthropology and cyber physiology in its Cyber Genome Program. DARPA hopes to develop advanced methods to fingerprint or identify the origins of a cyber attacks by examining digital artifacts, and presumably other criminal activities utilising computer technology.

Getting a bit more down to earth, web site owners need to consider what information is being gathered and why, ensure this is legal, check that consent is implied or has been explicitly given for the purposes and what monitoring and analysis is performed on the data. It could be easy for system developers to carried away with tracking and tagging. Contracts with third parties should state clearly what the expectations are about the security and privacy of information, to protect web site users (employees, customers, clients, citizens) and the business.

Testing a web site is important, and smoke/regression testing would normally be undertaken each time the web site's code is updated or extended. But what about third party code and data on your web site? I was using a shop's store locator and it wrongly identified the two closest store locations to Farringdon Station in Clerkenwell, EC1M. Both Euston Station NW1 and Canary Wharf E14 are further away than the third result, Cheapside.

Intrigued, I zoomed in on the map and the ordering of the first two results swapped. And the data point for Canary Wharf seems to be located in the centre of the City of London, instead of its actual location downriver on the Isle of Dogs. The data point for the first result wasn't even displayed.

So is this a third party problem, or something else? Well, without investigating further you can't really tell, but it's the concept that matters.

This inaccuracy is worrying for a number of reasons:

• Customers may have difficulty locating shops.
• It undermines customer confidence and therefore trust in the brand.
• It indicates a lack of care in the web site's development and may put off online shoppers.
• It could indicate the presence of a security vulnerability which could be exploited to damage the site, its data or its users.
• The same geo-location code may be used for other internal calculations such as marketing data processing that affect business decisions.

If you are including functionality or data from third parties, you need to know when that system or service is updated. This notification requirement should be built into contracts. In this case, the data being returned may be inaccurate, formatted in an unxpected manner or be exposing a fault in your own processing of the data. Undertaking input validation on the data provided by the third party and output validation on what you are about to send back to the web site user need to test for reasonableness as well as more technical checks. Why not cross-check that the first result's postcode is closer than the second and the third?

It may just be a problem with the company's own data, but that's even more worrying.

Following on from Tuesday's topic of terms and conditions for interactive advertising, the US Network Advertising Initiative (NAI) has just released their 2009 compliance report.

The NAI is an association of 35 US advertising networks, data exchanges, and marketing analytics services providers including Advertising.com, Google and Yahoo.

The NAI Compliance Report 2009 discusses compliance by its members with its self-regulatory code of conduct governing the collection, use, and disclosure of data for online advertising services by its member companies (the NAI Code). The NAI Code has its own definition of personally identifiable information (PII) and sensitive information and its own protection principles. The NAI found its members to be broadly in compliance with the code, apart from ten members that did not disclose specific retention periods for data collected.

Whatever your views of behavioural advertising, industry initiatives like this to improve, and report on, standards are a welcome contribution. No doubt the code will evolve over time, but it is a good starting point. The code perhaps lacks requirements for measuring the accuracy of data or requiring ways for consumers to correct information about themselves, and it would be useful to know what checks are being undertaken as part of the audit. For example "Reasonable security is determined in light of several factors including, but not limited to, the sensitivity of the data, the nature of a company's business operations, the types of risks a company faces, and the reasonable protections available to a company" could be interpreted in a number of ways and some guidance on what is "reasonable" both from the organisation and individual's points of view would be welcome.

P.S. Happy new year.

Britain has some snowy and cold weather at the moment causing difficulty for people getting to shops or going on holiday, and web retailers are likely to be doing brisk trade if they can still deliver before Christmas.

E-commerce sites are often associated with HTTPS (a combination of HTTP with the SSL/TLS cryptographic protocol). There was a time when HTTPS was used only where absolutely necessary due to the additional encryption/decryption overhead it placed on a user's browser (client) and the web application (server). But what's the situation today?

N.B. the padlock symbol or green/blue coloured address bar (depending upon the type of certificate in use) indicating the use of a "secure" web server, does not mean your data is safe; it shows the server identity is verified to a certain extent and that data in transit between your web browser and the web server is probably safe from interception, if it is configured correctly on the server, the certificate has not expired or been revoked, and you can ensure the content you see is on the site the address bar says it is. It also says nothing about how the organisation and partners that handle the data once it has been received by the web server—they might forward it by email, allow third parties to have access to the server, print the data and leave it unprotected, etc.

Almost all web sites have some aspects that should only be accessible over HTTPS. Any sort of data entry form is likely to include personal information and therefore HTTPS should be used to at least protect the confidentiality of the information in transit. User registration, authentication (log in) and any pages that contain confidential information would also be included. Previously, many search engines did not index HTTPS addresses, but since its use was mainly restricted to content protected by some type of authentication and authorisation, this was never much of a concern.

But nowadays, search engines are indexing HTTPS content and a few web sites are only available using HTTPS. Is this a configuration worth following? In a discussion Ivan Ristić described the additional benefits of HTTPS (HTTP over SSL):

Issues

So while there are benefits relating to authenticity and integrity, in addition to confidentiality, and dangers to mixing HTTP and HTTPS on the same site due to badly designed authorisation and session management systems, what other issues are there?

Search engines

The most popular search engine robots no longer discriminate whether the content is HTTP or HTTPS, so this is no longer a concern. I am not aware if any adverse effect on search engine optimisation (SEO), other than the effects of changing from HTTP to HTTPS or vice versa which would have to be managed carefully and appropriate permanent redirects set up (also called 301 redirect due to the HTTP response status code of 301 for "moved permanently").

Note that Google, and apparently Yahoo and Microsoft, support the "rel='canonical'" link element and state it can be used for indicating a preference for HTTP vs HTTPS, or vice versa, when pages are available by both. There is also a setting for this choice in Google webmaster tools if you are a site owner. But be careful with allowing both HTTP and HTTPS access to the same page, since this quite often is implemented in a way that adds vulnerabilities to user authentication and session management.

Resources on the server

The server is affected by two aspects—the increased number of requests (see also resources on the client, below) and the overhead of encryption/decryption/building SSL connection. Intermediate proxies should not cache the content and therefore a greater number of requests is to be expected. The additional resources required to serve content using HTTPS are discussed extensively here and in a research paper, i.e. there will be a performance hit, but whether this is a problem depends on your traffic profile, architecture, server utilisation and site's design.

Server side processes

It is possible that any server-side indexing or reporting systems may not support HTTPS and they may need to be updated or configured to work with the different protocol. If you syndicate data to other systems via XML, RSS or web services, these processes will also need to be checked for compatibility.

Traffic management

Network devices that inspect and route internet traffic must be SSL-aware to be able to read and analyse the content. Most modern devices will be able to support this mode of operation.

Client device support

Some devices (e.g. mobile) may not support HTTPS, or HTTPS may not be allowed through firewalls but this is probably less of an issue now. Check if these are issues with your expected users and the devices your site supports.

Address familiarity

Most people will not recognise (or type in) HTTPS addresses and use the common shorthand of the host name (e.g. www.clerkendweller.com) or an alias (e.g. clerkendweller.com) rather than the protocol followed by the full host name. So this would require a redirect from the HTTP address to the HTTPS one, and for many web sites this will be acceptable. For sites of a more sensitive nature, this would have to be handled carefully to protect any session identifiers and still leaves the user potentially vulnerable to a man in the middle (MITM) attack. These are where the redirect is amended and the user taken to a malicious web site instead. If you can rely on users using only the SSL address, perhaps by bookmarking it, you are on safer territory.

Resources on the client

Again there will be a performance hit on the user's client device (e.g. browser of a desktop computer). Much of the time this will not be a problem unless the device already lacks resources (e.g. a mobile device). Then again, due to the lack of caching, more requests will have to be made directly to the server, creating additional lag to download and build content.

Mixed content

Even if all the content from your own site is sent using HTTPS, you may have embedded content such as:

• client-side web analytics
• advertisements
• news feeds
• widgets
• images, videos, scripts and other content hosted elsewhere.

These must also all be provided using HTTPS, otherwise the benefit of being HTTPS-only will be lost and users may see "mixed content" warning. But this can be a problem as much third-party content is not available using HTTPS (SSL), notably including Google AdSense, Amazon Affiliates and YouTube. However, Google Analytics does support SSL.

Conclusions and further reading

An all-HTTPS web site provides additional security benefits, but user acceptance and server constraints need to be considered in the site's design and architecture decision making processes. The partial, or full, use of HTTPS (SSL) in a web site needs to be considered carefully during design and development to ensure weaknesses that could be exploited are not built in, and then verified by thorough testing. If you have a heavily consumer-focused web site or include third-party content, some of the choices may have to be on the side of ease of use rather than with the lowest security risk.

"Whole site SSL" should be a serious consideration for "green field" web sites, especially where user authentication is required for any part of the content and for sites where phishing is a major risk (e.g. gaming, web mail, banking). User knowledge and acceptance may be difficult until we see the likes of major banks or large consumer-orientated sites (Google Mail, Google Docs, Twitter, Facebook) use this configuration and and display a warning/educational message to people who go to the non HTTPS site, rather than a redirect.

It seems a missing full stop brought down every web site hosted on a domain ending with .se (the top-level domain for Sweden) on Monday evening.

The .SE registry had apparently performed an incorrect software update but actually a script (program written by a human) had failed to add a terminating full stop (.) to the DNS records in the .se zone. Tested? I guess not.

It reminded me of Google's mishap in May when it flagged every site as potentially harmful by simply adding an extra forward slash (/) character to a file.

And, simple punctuation mistakes can invalidate the HTML of your web page, or stop your application's scripts from running. In July Microsoft created a security flaw in Windows by the addition of an extra ampersand (&) character.

Tim Berners-Lee is still wishing he hadn't put two forward slashes in every URL.

The mighty power of a punctuation mark.

Many organisations like to do land grab with domain names by purchasing the same name with different generic top-level domains (e.g. .com, .net, .info), country code top-level domains (e.g. .uk, .es, .fr), and multiple second-level domains (e.g. .co.uk, .org.uk). Then of course there are mis-spellings, similar sounding words, brand names and trademarks.

Well all that leads to complexity, and it's not uncommon for many domains to be aliased to the same site in a way that any of them can be used to access the complete web site.

But it can get especially messy when SSL is enabled on some or all of the site too. Inevitably there end up being certificate warnings. Some organisations should know better. So when I was searching for providers of online and business privacy "seals",

I was very surprised to click on the link to an SSL page which was reported as using an invalid certificate.

Actually the certificate was fine, it just wasn't valid for the .ORG domain. Perhaps they had hoped the wildcard SSL certificate *.trust.com would somehow cater for *.truste.* - no.

Identity theft? Privacy? But apart from these configuration issues, isn't it just very confusing to have many different domains appearing in search engine results? How does this duplicate content affect their search engine ranking? Does it undermine trust in the brand? Should the SSL part of the site be indexed at all? Perhaps. Who makes these decisions? Is it the developers, the person who configured the site or does the business have a viewpoint?

I overheard a (loud) mobile telephone conversation this week in which a marketing manager* was apologising for a problem but they "did not know any of the technicalities". Mmmm, who is accountable? Make it your business to know.

[* Security and technology managers should also understand their organisation's business objectives.]

It's common for access to some web sites to be restricted to users from particular Internet Protocol (IP) addresses. This is usually in addition to some other identification and authentication method. But other IP addresses are often added to this "allow list" and these should not necessarily be trusted in the same way.

In a typical scenario, a web site hosted on the internet that is used to administer another web application might be restricted to the company's own IP addresses. Then the developers say they need to check something on the live site, or another server needs to index the content, or someone wants to work from home for a while, or the site needs to be demonstrated at a client's location. All these additional IP addresses are added to the "allow list". These restrictions may be being applied at a network firewall, traffic management system, at the web server, in the application itself, in intrusion detection systems or in log analytical software, or in many of these. These are difficult to manage and in time there will be many IP addresses that no-one knows why they are allowed unless they are carefully documented, and subject to a fixed time limit when they are confirmed again by an appropriate person or removed. These extra addresses are quite often hard for someone else to guess.

However, there is another area where IP addresses are added to "allow lists", and this is for remote monitoring and testing services. These might be checking uptime, response times, content changes, HTML validation or security testing. The service providers publish the IP addresses of the source systems so that companies can specifically allow access to their web sites. Since the number of these services is relatively small, it's not too difficult to find which one might give access to areas of a web site or web application that the public (and malicious people) should not be able to get to. The particular danger here is that the IP addresses might be excluded from monitoring and logging, and therefore even a diligent web site manager might not realise for example the uptime monitoring service is making unusual, or excessive, requests.

Although it is not likely a malicious person is using this "trusted" address unless routing has been compromised as well, problems can go undetected, from what might seem to be a legitimate source. The IP address may have been typed incorrectly, or worse, the restrictions/exceptions may not have been implemented correctly allowing more addresses to have the privileged access than intended. Not logging a user's session is privileged access.

Allow traffic through, but be very specific what is allowed and monitor what's going on. Review all the exceptions periodically. Be especially careful about anything that bypasses authentication (such as allowing a search engine to crawl restricted-access content) on an otherwise public site.

Phishing attacks are often targeted at organisations where login credentials can be used to gain financial reward, and these web sites almost always use SSL to allow users to authenticate the identity of the site and to protect data in transit from alteration or copying.

A recent paper Crying Wolf: An Empirical Study of SSL Warning Effectiveness from Carnegie Mellon University discussed the results of a survey of over 400 internet uses. The conclusion - users ignore warnings about invalid SSL certificates.

The subject of trust user experience (TUX) was discussed during the Workshop on Security and Human Behaviour (SHB 2009) at Cambridge University this summer, and summarised here. This included a discussion on how users, who are trained to be sensitive to warnings, become more susceptible to picture-in-picture attacks. These are where an image of a (fake) browser, perhaps with a graphical representation of a green extended validation address bar is displayed inside the user's real browser window, such as in the example mock-up below. This is most effective when the real browser is displayed at the full screen resolution.

Therefore I was interested to read about how web designers can use CSS to access operating system style settings (the "chrome" of Linux, Windows, Mac, etc) and use these to apply matching fonts and colours to web design elements. This means if users have a customised desktop colour scheme, the fake browser in the picture-in-picture attack doesn't need to be in standard desktop colours, but could pick up on the user's own settings, to confuse them further.

See also my comments about Colour Overload with IE8 Tab Grouping.

The results of the Internet in Britain 2009 survey by the Oxford Internet Institute highlights people's usage and concerns about the internet and web sites.

Some aspects of the report relating to e-commerce, trust, fraud and privacy are summarised below.

• Confidence in the Internet and the commercial services that it offers remains high.
• Use of the internet is leading to greater trust in the technology as a source of information and medium of communication and services.
• Since 2007, people are now just as concerned about credit card fraud, and the right to anonymously express opinions, but less concerned about the threat of computers and the internet to privacy.
• Negative experiences of the internet are not as great as portrayed in the media.
• The survey examined what personal information people are willing to provide when registering on websites.
• A general desire for greater regulation of the internet.

Read the report for the methodology, full information and detailed analysis. The report also provides useful data on internet penetration and usage patterns such as for web 2.0 and mobile technologies.

This week a friend contacted me about his business website. It seemed his company had paid for both a .co.uk and .com domain name, but the latter was not currently mapped to her site.

It seems the web developer wasn't being co-operative and she was asking for some advice. It appeared that neither domain were registered in my friend's company's name—both named the developers. This makes things much more difficult if the developers are slow to respond to change requests, or fail to renew your domains, or you fall out with them or they go out of business.

But I came across another example on Wednesday. I had to drive through London and later in the day I went to pay the £8.00 charge using the congestion charge online payment service from Transport for London.

I looked at the SSL certificate's details and was very surprised to see the organisation named on the certificate (known as the distinguished name field for organization) was not "Transport for London" but "Cobweb Solutions Ltd", presumably this company.

Whilst this may not be contrary to the SSL Protocol Specification, it is contrary to expectations and good practice. If this were a retail website (where you choose to buy rather than being obligated to pay!), would a cautious potential customer trust the site? The information has also given away vital clues to a malicious user on the software development company and thus perhaps possible approaches to breach the system. Cobweb Solutions' own site has a shopping basket/e-commerce system that has a similarly attributed secure certificate:

Like domain names, your own website SSL certificates, regardless of SSL certificate type should be in your own organisation's name, not anyone else's. In fact this also usually makes the proces of purchasing a certificate simpler.

On my friend's domain name issue, she has contacted the relevant domain name registrars using their disputes process to ask for the details to be updated. She is also checking whose name is on the web hosting contract.