Yes, had you forgotten it's Data Privacy Day tomorrow? See StaySafeOnline for events in the US and Canada. Not sure why it's a Saturday — maybe to give the weekend journalists a story they can prepare in advance, and then take the day off.

While there is a programme of events, data protection has been in the news this week following the publication on Wednesday of the European Union's proposed reform of data protection legislation, promoted under the banner of aiming:

There has been extensive documentation and justifications published to accompany the draft directive. There is of course plenty of coverage elsewhere, and I would recommend reading the following:

• Initial response from the ICO on the European Commission's proposal for a new general Data Protection Regulation, UK Information Commissioner's Office
• EDPS welcomes a "huge step forward for data protection in Europe", but regrets inadequate rules for the police and justice area European Data Protection Supervisor
• Pan-EU consistency in data protection reform welcome, but burden on business a problem, says expert, Out-Law.com

So, what does it mean? For now, these are just proposals, and what will eventually be made into law will be something very different. But it does indicate the way things are going, and is a reminder to website and application owners & developers of the need to take privacy considerations into their projects now, since the cost of changes later may be prohibitive. And, they should be doing this already, but there may be more obligations for those processing personal data in the future. There is potentially more complex functionality required for tracking consent, achieving data portability, handling withdrawal of consent and undertaking data removal.

And, there is the topic of mandatory notification of "serious" breaches.

Data Privacy Day might be a day of reading after all.

The proposed new European Data Protection Directive will be announced tomorrow.

Apart from the leaked draft document, there has been plenty of comment (e.g. here, here and here), Viviane Reding, Vice-President of the European Commission, has also been speaking up.

Meanwhile IAB Europe has been busy behind the scenes discussing online behavioural advertising (OBA) and IAB USA has been blogging about its self-regulatory programme. Lots happening then with privacy, advertising and online marketing.

We will find out tomorrow if the leaked document was representative of the final proposals.

Further to my previous notes about HTML 5 security, a superb reference document was published earlier this month.

Michael Schmidt (Compass Security) wrote his master's thesis about HTML5 security in May 2011 and has published an extract for everyone to access.

HTML5 Web Security describes issues, vulnerabilities, threat & attack scenarios and countermeasures across 80 pages including numerous well thought-out diagrams, and is backed up with detailed references and an appendix full of attack details.

The main sections are:

• 2.2 Cross-origin resource sharing
• 2.3 Web storage
• 2.4 Offline web application
• 2.5 Web messaging
• 2.6 Custom scheme and content handlers
• 2.7 Web sockets API
• 2.8 Geolocation API
• 2.9 Implicit relevant features of HTML5
  Web workers, new elements, attributes and CSS, Iframe sandboxing and server-sent events

If you are already developing HTML, or planning to, read this document as soon as possible and update your requirements documents, specifications, design documents, coding standards, and test plans to incorporate the knowledge.

The document would be worth buying if it were a book, but it has generously been made available publicly. Yes, I am still reading the document, and so far have only one very minor complaint — it would be good to have a content list. Maybe in version 1.1?

The UK's data protection agency Information Commissioner's Office (ICO) has updated the previous guidance on the use of cookies and similar tracking technologies, under the revised Privacy and Electronic Communications Regulations which came into force on 26th May this year.

In a press release today, organisations were warned they are not doing enough during the lead-in period to formal enforcement.

The updated Guidance on the Rules on use of Cookies and Similar Technologies provides concrete advice and practical guidance on the legal requirements, their interpretation and what are considered acceptable practices. The guidance was issued as a result of a review of progress to date which shows a lack of knowledge and action from web site owners. Of most concern are likely to be persistent cookies, cookies issued by third parties, cookies issued immediately a user visits a web site, are used for any sort of profiling or which span multiple website hostnames or multiple domains.

If you have any analytics, advertising, tracking or content provision by third party web sites, beware — you may just find the terms and conditions of service state you are responsible for obtaining and managing consent.

If you are a web site owner, take note and act now, if you have not already done so. From May 2012, the ICO will be accepting complaints from users, and will then contact web site owners to ask them to respond to the complaint and explain what steps they have taken to comply with the regulations. Therefore, document what you are doing and the decisions taken.

The W3C's Tracking protection Working Group has published two working draft proposals for implementing "Do Not Track" online.

The proposals will allow users to define whether or not data about them can be collected for tracking purposes. Thus the proposals include information on how consumers express their tracking preference, and also how the websites and related systems (e.g. affiliates) will acknowledge those preferences.

Tracking Preference Expression (DNT) (W3C Working Draft 14 November 2011) describes how users express their preference and how websites indicate whether they honour such preferences. The proposal is to utilise a new HTTP request header "DNT", a machine-readable web-accessible file defining the site's tracking policy and an HTTP response header for the site to communicate its compliance with tracking preferences.

Tracking Compliance and Scope (W3C Working Draft 14 November 2011) defines the meaning of a "do not track" preference and will set out practices for websites to comply with this preference.

These are very early drafts, with many unresolved issues. W3C hopes to have adopted standards by June 2012, but in the meantime is inviting review and comment. For websites hoping to adopt and promote compliance with this proposal, now is a good time to start defining a project with a view to firming up the requirements in April 2012 when a candidate recommendation will be published. The broad requirements can be seen from the current documentation.

Do you remember Lush Cosmetics' rather public payment card data and personal data loss announced in January 2011? After 4 months of being compromised, the problem was recognised, customers were notified and the web site was shutdown.

Lush had allowed people's data to be stolen via its own web site. We still await to hear what the fines and other penalties will be levied under the Payment Card Industry Security Standards Council (PCI SSC) Data Security Standard (DSS) if they are found to have been non-compliant at the time. However the UK's Information Commissioner's Office (ICO) became involved due to the related loss of 5,000 individual's personal data and confirmed in a press release on Wednesday this week that Lush Cosmetics had also breached the Data Protection Act 1998. Formed in 1994-1995, Lush Cosmetics has been a registered data controller (No. Z8189523) since late 2003.

As expected, no enforcement notice or monetary penalty has been issued, but Lush Cosmetics Limited's Managing Director, Mark Constantine, has signed an undertaking to ensure that personal data are processed in accordance with the seventh data protection principle concerning security, and in particular take the following measures to improve the protection of personal, and cardholder data:

1. Appropriate technical and organisational measures are employed, and maintained, to prevent the unlawful processing of customer data, particularly within web based systems;
2. Only the minimum amount of customer personal data is stored and that this is retained only for as long as a relevant business need exists;
3. Computer systems storing customer personal data must be subject of regular penetration testing , with activity logs retained for an appropriate period of time and frequently interrogated for evidence of malicious attack;
4. The processing of customer credit card data is conducted by a PCI compliant external service provider;
5. The data controller shall implement such other security measures as it deems appropriate to ensure that personal data is protected against unauthorised and unlawful processing, accidental loss, destruction, and/or damage.

...as long as the Data Protection Act, or succeeding legislation are in force. So correctly a focus on Lush's web systems, including penetration testing of systems holding personal data. But also other appropriate security measures as necessary. Let's hope Lush aren't left thinking penetration testing is the answer — security needs to be considered at all stages of acquisition, development, deployment and operation.

And yes, that's right, the ICO is insisting on compliance with PCI DSS. The ICO made it clear in the press release of its expectations for PCI DSS compliance by other online retailers, that will otherwise risk enforcement action by the ICO.

This seems to be a valid approach, since fines, investigation costs, etc may still be levied for lack of PCI DSS compliance too. But I have some concerns with how Lush are portraying their squeaky-clean new status in the web site's terms and conditions:

I'm not entirely sure that moving all cardholder data off-site to a PCI DSS compliant third party processor necessarily means much about the security of other data on the Lush web site and elsewhere at Lush, or much about systems outside the cardholder data environment. Is this just meaningless bubbly rhetoric to provide false assurance, or maybe Lush still does not understand what they are doing? Complying with regulatory and contractual mandates isn't the same as believing in "filling the world with perfume and in the right to make mistakes, lose everything and start again". Some of that "honest meaning" mentioned by Lush would be welcome here too.

Personally I think the PCI SSC should be a bit more strict about how their name can be used to endorse systems. Hey, clerkendweller.com meets PCI DSS compliance criteria too! There's no cardholder data to begin with...

European organisations that are telecoms operators and internet service providers are subject to personal data breach notification under the revised ePrivacy Directive (2009/136/EC) which was passed on 25th May 2011, and is part of the Telecoms Reform package. The European Commission is now consulting stakeholders to gather evidence about existing practices and initial experience of the new rules.

You might wonder if this has any relevance if your organisation is neither a telecoms operator nor internet service provider. Well, personal data breach notification could become more widespread in the future, and therefore I think it is important to get this right as far as possible for the "pioneer" sectors.

The public consultation ePrivacy Directive: Circumstances, Procedures and Formats for Personal Data Breach Notifications as the name suggests is seeking input on three issue areas:

• Circumstances: how organisations comply, or intend to comply, with the new obligation under the telecoms rules; the types of breaches that would trigger the requirement to notify the subscriber or individual, and examples of protection measures that can render data unintelligible
• Procedures: the notification deadline, the means of notification and the procedure for an individual case
• Formats: the contents of the notification to the national authority and to the individual, existing standard formats and the feasibility of a standard EU format.

The information already gathered by ENISA will be very useful here together with the Article 29 Working Group's Opinion 01/2011 (WP 184).

The consultation asks respondents to reply to 28 particular questions which give a good indication of how specific subsequent guidance will be. The majority are aimed at organisations in these two sectors, but the issues of incident handling procedures, technological protection measures to render data unintelligible, speed of response and record keeping have wider applicability. So perhaps there will be some useful information for your own web/system incident response plan.

The consultation closes on 9th September 2011.

In May, the UK's Information Commissioner's Office (ICO) published its initial guidance on how cookies and similar technologies that store information on user's devices should be deployed (see my previous posts here, here and here). The European Union's Article 29 Working Party has now published its own views concerning obtaining consent.

The working party's Opinion 15/2011 (WP 187) suggests that prior consent will always be required and this may mean that the ICO will need to update its own current guidance and enforcement guidelines.

Although the working party's opinion is quite a long document, if you are considering how to build consent for cookies, etc into your future web product development plans (e.g. web sites, mobile apps, social networking activities, e-commerce and f-commerce), it is worth the read.

They emphasize the need to obtain unambiguous explicit consent before any personal data processing can occur, and to be able to subsequently prove this was given. This does not affect mechanisms "strictly necessary" for the provision of the service as discussed before about session cookies. The examples included in the text add some realism to the intent of the opinion, and it is likely the recommendations will form part of future updates to EU legislation.

And remember not to lose sight of the other data protection principles. Obtaining consent does not negate the controller's obligations for fairness, necessity, proportionality, security and data quality.

I had the chance to read a recent paper on the privacy risks of collaborative filtering. These are the types of systems which provide recommendations and suggestions based on other users' activity, such as products bought or looked at.

The paper "You Might Also Like:" Privacy Risks of Collaborative Filtering by Joseph A. Calandrino, Ann Kilzer, Arvind Narayanan, Edward W. Felten and Vitaly Shmatikov is summarised on Joseph Calandrino's blog, but describes inference of individual transactions from the outputs of collaborative filtering systems, thus revealing information without a user's knowledge or consent.

The approach described in the paper does not require the creation of fake user accounts or enter purchases or ratings into the target systems, and it does not assume the target user's transactions are available in either an identifiable or anonymised form. Instead the algorithm monitors changes to the recommender systems over a period of time, which when combined with auxilliary information, can be used to infer some of the target user's previous transactions i.e. not to predict future events but to infer past events.

There is some fairly serious mathematics in the paper, but don't let that put you off reading the rest of the paper.

I wonder if this approach could be used to infer answers in personal knowledge question based password recovery functions?

Having travelled to Dublin the day before the training courses begin at OWASP AppSec Europe 2011, I have had time to catch up on some reading in my accommodation at Trinity College.

Alexander Neumann, Johannes Barnickel, Ulrike Meyer of the IT Security Group at RWTH Aachen University have published Security and Privacy Implications of URL Shortening Services. The paper includes a thorough review of related work and their own research into the security and privacy risks of URL shortening services (USS).

The risks discussed include:

• redirecting people to malicious web sites
• exposure of "secret URLs" (by search engine or enumeration)
• tracking by the USS provider
• information leakage (via HTTP referer header)
• use to attack web sites
• loss of shortened URL
• SSL-only circumvention

The paper is a useful reference for undertaking privacy impact assessments (PIAs) relating to the use of USS, or for designing similar systems.

On a related topic, Elke Roth-Mandutz from Georg Simon Ohm University, is discussing "A Critical Look at the Classification Schemes for Privacy Risks" at AppSec EU this Friday morning.

I will keep you updated with the talks I attend on Thursday and Friday.