Posts Tagged ‘Cookies’

Response from the EU Webmaster

Tuesday, June 14th, 2011

I previously contacted the EU regarding the fact that their websites set cookies without user consent in violation of an EU regulation. (See previous post).

Their response was as follows: –

Dear Madam / Sir,

We thank you for your interest in the European Parliament website.

Indeed, the EU Cookies Directive effective since 25th May 2011 imposes the consent of the User during setup of cookies. We are currently considering the compliancy towards this opt-in policy. The principle of a Guideline is to establish a normative frame imposed to the member states. Then, the national authorities have to enact practical and restrictive measures for websites owners.

Requirement of User consent is not obvious regarding, for example, cookies setup by Google analytics,… In every case, the Institutions have to think in a practical way, about a coherent policy regarding this matter, which can take some time.

Therefore we thank you in advance for your patience.

Best regards,

Europarl Webmaster

EUROPEAN PARLIAMENT
DG COMMUNICATION
Directorate for Media

In other words, it sounds like they don’t know what to do about it either and they are going to wait and see what everyone else does!

Why the EU can’t comply with the EU Cookie Law

Thursday, May 26th, 2011

You may have heard about the new EU “Cookie Law”. I’m not going to post why it is so idiotic here, I’ll leave you to read about it in other places.

However, I decided that for a laugh I would see if the EU websites comply with the Cookie Law. I looked at 2 of them, and neither of them appeared to. I then decided to contact them via their online chat facility to ask why not. A transcript follows (personal details removed)…

Agent 133:[joined]
Agent 133:Welcome to the EUROPE DIRECT web assistance service. For future reference, your enquiry case ID number is *****.
Agent 133:How can I help you?
****:Hi, I would like to know why this website (europa.eu) and the European Parliament website do not comply with EU directives
****:to be specific, Directive 2009/136/EC Articles 5(3) and 2(5)
****:which state that a user must give explicit consent before cookies are stored
****:however, this site stores a cookie ‘europa_esurvey’
****:and the europarl website stored Google Analytics cookies – ‘__utmz’, ‘__utma’, ‘__utmc’ and ‘__utmb’
****:I was not asked for my consent before any of these were stored
Agent 133:Please wait a moment.
****:ok
Agent 133:I would like to suggest that I forward your enquiry to the European Commission.
Agent 133:Would that be acceptable for you?
****:yes
Agent 133:Would you mind giving me your email address?
****:******@****.com
Agent 133:Is **** your family name?
****:yes – my first name is ******
Agent 133:ok, thank you.
Agent 133:Do you have any other questions regarding this matter?
****:do you have any idea when I should expect a response?
Agent 133:Usually within 3 working days (over 95% of enquiries).
Sometimes we have to send your question to the relevant in-house expert, which takes longer, though no more than 3 weeks.

****:ok, thank you
Agent 133:Are you an IT expert yourself?
****:yes – I’m a computer programmer
Agent 133:ok, I see.
Agent 133:Is there anything else I can do for you?
****:no, that’s all. Thanks
Agent 133:Thank you for using the EUROPE DIRECT web assistance service.
Agent 133:Have a nice afternoon and evening, bye!
****:bye!

I can’t say that I was really surprised that they couldn’t give me an instant answer. I was slightly surprised that they were actually reasonably helpful and fairly friendly (although “Agent 133” seems a bit needlessly anonymous – most firms who have online chat facilities seem to have a surplus of very English names for people who are obviously not native English speakers). I will probably post up when I get a response from them. I’m very curious what it will be!

ASP.NET Sessions Part 3 – Maintaining the Session Data Across Multiple Requests

Monday, March 9th, 2009
This entry is part of a series, ASP.NET Sessions»

In order to maintain the data on the server across multiple requests by the same user, the server needs some way of identifying the user.

You may think that this can be done by IP address, but there are a couple of problems. Firstly, there is no guarantee that people are going to have a constant IP address – they may have multiple internet connections and a load-balancing router which will share their requests out among the different connections (this is becoming more and more common). Secondly, they may be accessing the internet via a common invisible proxy server or a common NATed router which will mean that multiple users may appear all on the same IP address.

That means that we need to find another solution. ASP.NET provides us with 2 alternatives. We can use cookies, or we can use unique URLs (web addresses) with a session key encoded in them. By default, ASP.NET uses cookies, but not all clients support them (some paranoid system administrators turn them off). ASP.NET also presents us with an automatic mode, which is designed to detect whether cookies are available and if not, encode the key in the URL. In my experience, this doesn’t always work.

The other problem with encoding the key in the URL is that ASP.NET can’t always reliably rewrite all URLs. It works pretty well, by encoding it as virtual directory, but this looks messy, and of course it creates problems if people bookmark the URL. It also loses the session if the user clicks a link which takes them to another site and then the site sends them back, or if the user retypes the original URL.

The sessionState element in web.config has an attribute called “cookieless”, which can be used to control whether cookies are used.

If it is set to “AutoDetect” (I think this is default), ASP.NET attempts (not reliably in my experiece) to detect whether the connecting browser supports cookies and use them if possible or if not fallback to URLs.

If it is set to “UseCookies”, ASP.NET will always try to use cookies, but they might not work.

If it is set to “UseDeviceProfile” (I think this is new in .NET 3/3.5 – not sure), ASP.NET uses System.Web.HttpBrowserCapabilities to try to find out whether the browser supports cookies. MSDN seems a little hazy on how this works exactly, but I would guess that it is via the headers that the browser passes in the page request.

If it is set to “UseUri”, ASP.NET will always use URLs, irrespective of whether cookies will work. I have had to use this setting at least once.

From ASP.NET 2.0, you are able to specify the cookie name if you are using cookies (it defaults to “ASP.NET_SessionId”) by specifying it in the “cookieName” attribute.

If you aren’t using cookies, there is also an optional boolean attribute called “regenerateExpiredSessionId”, which can be used to control what happens when a user comes back after the session has timed out with an old session ID.