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.

The Interactive Advertising Bureau (IAB) and Association of American Advertising Agencies (4A's) have published a draft revised Standard Terms and Conditions for Interactive Advertising. Whilst this is principally aimed at the USA market, due to the international nature of the Internet, I thought it worth a mention here.

Use of the template (full title "Standard Terms and Conditions for Interactive Advertising for Media Buys One Year or Less") is voluntary and open to negotiation between media companies and advertisers. However it does discuss data usage and privacy. This is important if you have advertising on your own web site and need to write a privacy notice. Without knowing the agreement between the advertiser and media company, how can you inform your web site users what will happen to their personal information? Although this is only an example template, it probably contains most of the likely issues you will come across in other ones. The definitions of "user volunteered data", "performance data", "site data" and "use of collected data" probably need careful reading and advice from a lawyer! The education version provides some further explanation of terminology and the changes since the previous version.

The template also describes the "special situation of User-Generated Content (UGC) pages" on advert placement and positioning—there could be an interesting discussion if the actual content was neither that intended by the site owner, nor that added by the user, but instead was the result of some malicious injection.

There doesn't seem to be any reference to malware on the site or malware delivered by the advert.

Of course, including third party content is a risk that should be considered in itself.

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.

You may have heard some news about cookies, consent and the Council of the European Union in the consideration of the confidentiality the communications. Well, the legislation has been passed and the regulators is each nation have until 26th April 2011 to implement it.

The legislation amending Directive 2002/22/EC on universal service and users' rights relating to electronic communications networks and services, Directive 2002/58/EC concerning the processing of personal data and the protection of privacy in the electronic communications sector and Regulation (EC) No 2006/2004 on cooperation between national authorities responsible for the enforcement of consumer protection laws, will require that prior consent is required before cookies are set:

What will this this mean for authentication and authorisation cookies that use cookies for session management? If the cookies are a mandatory part of the purpose for which the user is undertaking (i.e. requested access to an area that requires authentication), there is an exception:

Note that there is no exception for cookies for advertising, web analytics software, security logging, usability testing etc., and it would seem that prior consent will be required for those. Although 2011 may seem a long way off, new applications in development and changes to existing applications should certainly be considering the implications, and owners of existing web applications should be assessing the possible effects and make plans once UK legislation is passed and guidance issued.

Additional discussion:

• Telecoms package conciliation: MEPs and Council representatives agree on internet access safeguards
  Press release, Euroepan Parliament, 6 November 2009
  http://www.europarl.europa.eu/news/expert/infopress_page/052-63798-309-11-45-909-20091105IPR63793-05-11-2009-2009-true/default_en.htm
• An Analytics Problem for the UK Public Sector
  The Pickards, Blog, 25 October 2009
  http://www.thepickards.co.uk/index.php/200910/an-analytics-problem-for-the-uk-public-sector/
• Consent will be required for cookies in Europe
  Out-Law News, 9 November 2009
  http://www.out-law.com/page-10510

I don't feel as pessimistic about this as Out-Law seem to be. Perhaps we'll see opt-in services being provided by the advert distribution agencies, rather than by each individual web site.

This weekend the clocks change as we revert from British Summer Time (BST) to Greenwich Mean Time (GMT) at 02:00 BST on Sunday 25 October 2009 and the clocks go back, giving an extra hour.

What does this mean for web site security? Does running 01:00 to 02:00 twice matter? Well some brave web application owners will be disabling their systems like this online bank:

And, I don't think it's just being done as a finale to the current Energy Saving Week. Most people, quite rightly, won't be taking this rather severe step. Another millennium bug anyone? The date/time should be considered rather like other untrusted user input. Most problems will probably fall into the "business logic" category such as:

• Failure of time-based logic where dates are being compared.
• Assumptions of uniqueness in time-stamped output (e.g. by a single-threaded process).
• Running tasks again leading to possible:
  • loss of data due to overwriting
  • duplication of exports or emails
  • creation of inaccuracies in management information.
• Chronological ordering anomalies leading to other faults.

It's not just banks and other financial organisations that may have difficulties.

The time change may expose some other vulnerabilities that only exist at changeover time and/or during the next overlap hour.

• Circumvention of brute force attacks on user authentication mechanisms.
• Increased risk due to extension of a session's validity where local time is recorded.
• Failure in data validation routines for time-related comparisons.
• Incubated vulnerabilities where a time-related aspect causes the attack to be possible.
• Denial of service due to extension of account lock-out.
• Using time as a loop counter.
• Additional errors caused by any of the above leading to information leakage.

Recording the offset of local time to GMT/UTC and synchronisation should certainly be done, but may not resolve the time overlap issues. The effects on long-running "saga" requests might be especially difficult to determine. Time dependencies need to be specified and considered through the development lifecycle. Perhaps the bank is right after all?

If you are considering undertaking customer monitoring, offering personalisation, providing targetted recommendations or even just appointing an advertiser that uses online behavioural advertising, reading guidance from the Internet Advertising Bureau (IAB) is a good starting point.

The IAB have developed a consumer-orientated website Your Online Choices, a guide to online behavioural advertising and online privacy.

However, more useful reading matter is the IAB's Good Practice Principles for Online Behavioural Advertising. The principles are self-regulatory and prospectively binding on each member in respect of their UK operations. Also remember the principles I discussed last month in User Analytics and Tracking. Whether your company, or advert network, is a signatory or not, it makes sense to understand the issues and apply them in your own online provisions. Consider what data are really necessary and ensure compliance with all internal and external mandates, including legislation.

A recent proposed revision of the policy on web tracking technologies for US federal web sites by the Office of Management and Budget set out four principles regarding user analytics and tracking.

• Adhere to all existing laws and policies (including those designed to protect privacy) governing the collection, use, retention, and safeguarding of any data gathered from users.
• Post clear and conspicuous notice on the website of the use of web tracking technologies.
• Provide a clear and understandable means for a user to opt-out of being tracked.
• Not discriminate against those users who decide to opt-out, in terms of their access to information.

The document recommends avoiding outsourced tracking and outsourced data analysis—issues not thought about by many organisations. Just because a third-party service is cheap, doesn't necessarily mean it's the appropriate method to use. I'm less convinced about the example of using cookies to record opt-outs.

The proposed revision attracted a well-considered joint response from the Center for Democracy & Technology and the Electronic Frontier Foundation. They suggested three additional principles.

• Limit use of tracking data.
• Limit retention of tracking data.
• Obtain third-party verification.

The response also referenced their May 2009 Open Recommendations for the Use of Web Measurement Tools on Federal Government Web Sites which recommended the following:

• Use data only for measurement.
• Prominently disclose.
• Offer choice.
• Limit data retention.
• Limit cross-session measurement.
• Obtain third-party verification.

Whilst none of the final guidelines will be mandatory outside the US federal sector, the issues raised are worth consideration by all commercial and non-commercial web sites. For example, the recommendations and principles above could be used to help guide a privacy impact assessment of an organisation's own use of web analytics and tracking technologies.

Version 3 of the Open Web Application Security Project (OWASP) Testing Guide has been released after a 6-month period of addition, enhancement and review.

The OWASP Testing Guide is an ideal reference for both developers and testers—version 2 was fantastic, and this new version is even better. The testing framework now covers 66 controls and, like in the previous version, each control has a brief summary and is described in detail followed by black box (no additional knowledge) and grey/gray box (partial knowledge) testing methods and examples where appropriate.

The controls and testing methods are fully referenced to provide additional guidance and explanation.

The controls are grouped into ten categories, including new separate categories "Authorization" and "Configuration Management". I'm especially pleased to see the latter broken out on its own, since even a perfectly coded application can have vulnerabilities introduced during deployment and changes to the application.

The OWASP Testing Guide now also includes a "best practice" penetration testing framework and a "low level" penetration testing guide that describes techniques for testing most common web application and web service security issues. More information is available on the Testing Project pages.