Showing posts with label privacy. Show all posts
Showing posts with label privacy. Show all posts

Thursday, 12 April 2012

Get your cookies while they're red hot

The European Union told us last year that we needed to get explicit permission to set a cookie in a visitor's bowser. The old technique of having a 'we use cookies and this is how you disable them' message on a privacy page was no longer enough and after a year's grace, May 26th 2012 is the date. After this time the UK Information Commissioner's Office could be on your case if you, (make that we), don't conform.

There's a nice developer feature in Chrome that makes it easy to see what cookies are set when you go to a site. Using this on the ATSF site shows that our hosting company sets a cookie and Google Analytics sets some cookies. I don't program any cookies into the site directly.

Despite the year's grace period, the situation is still potentially complex. A couple of useful places to go for more information are a PDF on the web site of the UK International Chamber of Commerce called the UK ICC Cookie Guide, and a piece on the ever useful Register site: A month to go on Cookie Law: Will Google Analytics get a free pass? which looks in more detail at the question of analytics cookies (with a lower-case A as well as an upper-case one).

One category of cookie needs no consent. As the guide says:
These cookies are essential in order to enable you to move around the website and use its features, such as accessing secure areas of the website. Without these, cookies services you have asked for, like shopping baskets or e-billing, cannot be provided.
This is a Category 1 Strictly Necessary Cookie.These quotes, by the way, are suggested text with which you can inform your users about what is going on with cookies on your site.

The next category is the Performance Cookie.
These cookies collect information about how visitors use a website, for instance which pages visitors go to most often, and if they get error messages from web pages. These cookies don't collect information that identifies a visitor. All information these cookies collect is aggregated and therefore anonymous. It is only used to improve how a website works.
The final two categories are Functionality Cookies, which track preferences, and Targeting/Advertising Cookies, which tailor advertising to your habits and often pass information between web sites.

The Register reporter managed to get a quote from the Information Commissioners Office which suggests that they won't be loosing too much sleep chasing uninformed performance cookies and will be providing more guidance on this sometime soon.

The ICO web site helps us see one tactic for dealing with all this (and has done for some time). When you first visit it, on any page, there will be a message,as below, across the top of the page:
The ICO would like to place cookies on your computer to help us make this website better. To find out more about the cookies, see our privacy notice.
With a check-box and a button. When you check the box and click the button the page reloads, the message is no longer there, and a cookie called 'ICOCookiesAccepted', with a year's lifetime, is set along with the four Google Analytics cookies. If you don't check the box and agree then every page you visit will have the message at the top.

The logic is as follows:
Check whether an AcceptCookies cookie is set. If it is not set then add the cookie form at the top of the page. If the cookie is set then don't add the form.

Accepting cookies using the form activates an 'invisible' page which records the referring page, sets the cookie and returns the visitor to the referring page.

For any web site with a cookie-tracked 'private' area, using cookie category 1, then you don't need explicit permission. However, consider the case where there is a login form on every page ... just a small one at the top probably. A common approach for such a site is to open a session for each page and then check the session cookies and if the user is already logged in you show slightly different content; even if that is just a 'Log Out' button. It is doubtful whether setting a cookie designed to manage a secure area is essential on non-secure pages or for non-secure visitors, so in future such pages will need to check for a 'private area' cookie before opening a session on such a page.

The Google Analytics cookie question is a bit more complex (and similarly for any cookie-based analytics system). If your visitors have to explicitly ask for such cookies to be set then they will be under-reported and the value of the analytics data is greatly reduced. (The ICO have admitted that only 10% of their visitors click this box.) Old fashioned web server logs will not be affected of course, and it would be interesting to see just how many, or how few, visitors do agree to cookies.

Your clients, particularly smaller ones, may not be aware of what is supposed to happen at the end of May. Now is the time to discuss this, even if the analytics cookie question is still a little open.

Friday, 16 March 2012

Data Protection – Europe versus Rest of World?

Personal data shall not be transferred to a country or territory outside the EEA unless that country or territory ensures an adequate level of protection for the rights and freedoms of data subjects in relation to the processing of personal data.
Article 8 of the EU Data Protection Directive

We've warned in the past about checking whether any data you transfer to non-European countries conforms to European legislation on data protection. Data Protection practices vary throughout the world and we have to make any data gathering conform to European legislation and check that any other countries that we deal with interactively will agree to conform to European practices. This has usually been done using the safe harbor principle where clients or suppliers in countries such as in the US have agreed to hold the data in a protected or safe mode that will conform to European legislation. You need to take care of this in any contractual agreement you enter into where data gathering will be part of the process.

However, in the last month things have been stirred up by Norway suddenly deciding that Google Apps, in terms of their data protection, may not be legal in Norway or by implication Europe as a result of the US Patriot Act. See: Use of Google Docs or Google Cloud Services is illegal in Norway, Shaun Ellerton (18th February 2012). Of course it won't just be Google who might present a problem as a result of the act.

The use of cloud services generally may also pit the principles of safe harbor against the Patriot Act. That allows law enforcement agencies access to personal data: but the US is not alone here. See Clouds and Law Enforcement Access, Andrew Cormack (9th March 2012). This blog gives useful insight into progress with the proposed EC Data Protection Regulation that was announced in January 2012 and will take a couple of years to be made law.

Of course Google are no strangers to privacy controversy at the moment and it appears that their privacy policies may themselves be in breach of the safe harbor principles, which arguably demonstrates just how difficult these things are. Hawktalk (5th March 2012) states 5 areas of concern over these issues, and interestingly uses the Leveson Inquiry's data protection example as a parallel case.

The present position of what practices the EC follow for data protection are summarised by James Lappin in his G-cloud update (18th February 2012), where he outlines safe harbour, model contract clauses and binding corporate rules as examples of the legislation in action.

Well, it seems that data protection is truly back on the agenda after a lull. We need to keep an eye on developments as none of us want to be found in breach since the consequences can be mega!

Sunday, 31 October 2010

You never know who's listening

I suppose it comes into the category of a story that will run and run: it has legs, as they say, even though the problem was caused on wheels. What am I on about?

It looks as if Google Street View could be in breach of some laws in the UK, after having had similar problems in other countries and been blocked from the odd village for 'snooping'. It even shows our neighbour, frozen forever in the act of reading a book in the conservatory in front of his house while we all wait for our bins to be collected. I was in but Elaine was out, according to the cars in front of the house. Do I care?

Not about the photos, but if I thought that Google had recorded a snippet of my Wi-Fi traffic then I might be. That seems to be the nub of it: incidental and, apparently, inadvertent recording of data. Data that might contain part of a confidential email exchange or even a password sent unencrypted to an FTP server. The interception was, as I understand it, done to match a WiFi router's MAC code to the physical location. This would enable, say, a mobile phone to check its location by looking to see what transmitters of any kind were in range. Those of you with iPhones will have seen that blue dot dance that occurs as the Google Maps application refines your location, from a combination of cell tower information and WiFi until it can, finally, use GPS to give you the real location. The story goes that some extra code from another project got into the Google car system and instead of just recording the WiFi's location it also recorded some of the traffic.

There is a lesson for us all here, which is the danger of amalgamating code snippets without fully understanding what they do. The 'snooping' code was presumably attached to something less contentious but both were incorporated in the street view system. On the one hand it's good coding practice to efficiently reuse your legacy code ... to not reinvent a software wheel ... but it is vital to look in detail at what that code does. In turn that comes down to documentation and code comments. It also comes down to making sure that any code put in a routine for testing purposes is removed or disabled in the release version.

There is also a great temptation to cut corners with code for internal use; but you never know when things will get out into the wild. In radio they tell you never to swear in front of a microphone because you never know when it might be live. Treat code the same way.