One of the areas on the cookie consent that confuses me is if a cookie is required for the website to function it doesn't need consent. Since the only cookie my website uses is a session cookie, I don't use a cookie banner. My site won't without it due to the security login area. If you're in a public area and your browser doesn't accept cookies you can still do public things such as reading things and sign up but not login and use the actual system. I am still not sure if I am compliant or not.
There is some server side tracking, basically the source and campaign if they convert. And some A/B testing tracking. But the thing is, I can't have two separate session cookies with the framework I'm using. And it's not exactly possible to delay a session cookie creation with the framework i am using if it's in an area converted by the security firewall rules.
To be legal you need to get the user's consent, upfront, for that tracking. Technical challenges are not a defence.
GDPR is not the only regulation at play here. The PECR also applies. You need consent for the session cookie in the public areas of your site. It doesn't become essential until the user logs in, registers, adds an item to the cart, etc.
Honestly, considering the state of play at the moment the law is pretty much unenforcable. They literally can't fine everyone who is breaching it, they don't have the manpower.
And considering the ICO, the UK org that enforces these laws and where you have to go to find out the UK laws on it, literally just tell you that they use cookies to make their website work and don't ask for consent makes me think this is so much more complicate than any of us truly understand.
If they're setting cookies without consent with a user tracking id, I am going to guess that my session cookie falls under the same thing theirs does.
> To be legal you need to get the user's consent, upfront, for that tracking.
No, that's just one basis for processing data. Another basis for server-side tracking like this could be legitimate interest. The site will need to provide evidence that they've weighed up the user's interest in this and be able to demonstrate a convincing case in favour of the site.
For example, it could be a legitimate interest to track A/B testing in order to increase shopping cart checkout rates - the legitimate interest is arguably that the site wants to increase its revenues and if it can demonstrate a convincing case for this, it will be allowed by the regulator.
Storing a cookie which is not strictly necessary to provide the service, requires explicit consent. This is a PECR requirement, not a GDPR one. Tracking the source and campaign of a user between pages is not required to deliver the page.
So you may rely on legitimate interest to process the data, but you need the consent to store the session cookie to collect the data in the first place.
If you have A/B testing in place it is strictly necessary to have a session cookie. Otherwise a user could end up in a case where they where in the A group on their first request but their second has them in the B group but the page they visited isn't enabled or displays different content than what they expected to see.
If you have special offers based on the URl they came from then it is strictly necessary to be able to remember where they came from so they get the special offer and don't fall victim to false adverstising.
Strictly necessary means if the website will break in anyway without it.
Your understanding of strictly necessary is incorrect. You do not need to a/b test a website for it to function. It is optional. It doesn’t become legal just because your tech stack makes it difficult, or because you engineer the site not to work without a non-essential cookie.
You could a/b test based on even or odd numbered IP address and not require consent to store a cookie. You can pass the referrer around via query string and not require consent to store a cookie.
However, as you said, there is no enforcement of the regulation so the risk of non-compliance is basically zero :)
>Your understanding of strictly necessary is incorrect. You do not need to a/b test a website for it to function. It is optional. It doesn’t become legal just because your tech stack makes it difficult, or because you engineer the site not to work without a non-essential cookie.
No if a user clicks a button to see the prices at 10 euros but see the prices at 20 euros then that is an issue. That is a rather serious issue, if I show you a price and then when it goes the payment processor on the second request that is illegal.
There are many ways of doing things but considering the ICO's list of strictly necessary this falls into it.
Also, I use the session id in my logs so I can debug issues such as the user saw x on page then did y so z happened. This is falls under it as well due to it being required for the operation of the website.
The fact there are other ways of doing things doesn't remove the fact for my way the cookie is strictly necessary. The system will fail. And yes, the tech stack and the way I built it does affect this. Look at the laws and you'll see a number of times where they say something along the lines of "if feasible". The recommendation from ICO is that you don't need to ask for permission for everything and they kinda make a point of saying that as it's annoying as hell for everyone.
> No if a user clicks a button to see the prices at 10 euros but see the prices at 20 euros then that is an issue.
I agree with you, that is a serious issue. But that issue is caused by your use of a/b testing, and if you solve that issue with a cookie then you need consent.
The ICO PECR guidance explicitly states that you can not rely on the strictly necessary exemption for analytics cookies.
A/b testing is not analytics. Analytics is how many people are using the site not market testing. And it says you can‘t use it for soley analytics, soley being a keyword. The analytics from market research which results in a legal requirement of having to charge the price advertised is not the same as Web Site analytics of how a user used the site. Just which version of the site they used and what legal requirements/contracts are in place.
On this point GDPR is pretty simple. In general security do not require consent, nor does cookies that are used for functional aspects of the sites.
A simple guideline is to imagine if someone breaks into your server and steal data. If that data can come to harm real people somewhere then you likely have something which you needed to have gained consent in order to handle. On top of that there is an additional exception for data only used for security purposes.
Second paragraph is false, first one is partially true.
There are many legitimate reasons for storing and processing data, and you should not ask for consent needlessly - among other reasons, because consent can be withdrawn, at any time, and you are obliged comply stop processing and remove data - unless you have other legitimate reasons, in which case the whole exercise seems pointless.
Whether the data can be used to harm real people has significant correlation with whether it is covered by GDPR, but does not relate to consent. It can also be of relevance on what security precautions are required and when weighing right to privacy vs. needs to process specific data.
As a typical example, you do not need (and shouldn't ask for) consent for data and purposes that are reasonably necessary for the services customers ask for. You are not allowed to share / use for unrelated purposes other than allowed by other stipulations. Also, information on data collection / processing should be reasonably, easily accessible.
This is completely wrong. I don't want to pick your comment apart, but I suggest actually reading the GDPR. It is available in every European language.
I suggest you read the Recitals 47 to 49 of the GDPR, especially 49. It is liked here https://gdpr-info.eu/recitals/no-49/ but it is short enough to fit a HN comment. It is called Network and Information Security as Overriding Legitimate Interest, a name which has the word overriding in it. Pretty clear language.
The processing of personal data to the extent strictly necessary and proportionate for the purposes of ensuring network and information security, i.e. the ability of a network or an information system to resist, at a given level of confidence, accidental events or unlawful or malicious actions that compromise the availability, authenticity, integrity and confidentiality of stored or transmitted personal data, and the security of the related services offered by, or accessible via, those networks and systems, by public authorities, by computer emergency response teams (CERTs), computer security incident response teams (CSIRTs), by providers of electronic communications networks and services and by providers of security technologies and services, constitutes a legitimate interest of the data controller concerned. This could, for example, include preventing unauthorised access to electronic communications networks and malicious code distribution and stopping ‘denial of service’ attacks and damage to computer and electronic communication systems.
GDPR is compatible with information security and do not interfere with it. The section is technology neutral in that you can use cookies, logs, firewalls, blacklists, oracles or any other methods that include data processing and as long the purpose is strictly necessary and proportionate to ensure network and information security than that is acceptable as according to Recital 49.
> A simple guideline is to imagine if someone breaks into
> your server and steal data. If that data can come to harm
> real people somewhere then you likely have something which
> you needed to have gained consent in order to handle.
The website admins and developers are not those who decide what data is covered, based on any idea we might have as to what may be likely to cause harm. Rather, the GDPR defines personal data and the rules for handling it differ between controllers and processors. I should have typed up a more thorough answer.
In any case, there are always more and more nuances to be discovered about the GDPR depending on field. I'm not a lawyer and I'm glad to always be corrected and updated.
Never said that the information needed to be likely to cause harm, but simply can. The exact phrase that GDPR use is "Any information that relates to an identified or identifiable living individual".
An example where any information that related to an identified or identifiable living individual would be harmful would be in a court. Any information about juries, judges, accused or defendant is potentially harmful if abused. All legal systems depend on the presumption of privacy in this regard, and all legal system that I know have processes in places to replace individuals when that harm can be actualized.
A similar situation is possible when it comes to information being distributed to a very large audience. Unimportant "harmless" information can be perfectly safe in a small group, but if millions of people see it in a harmful context then such harmless information can turn harmful. Any person operating a forum, a voice chat group, or a place where any two people meet should treat any logs with the threat model of it being leaked and the information harming real people.
I should have clarified in the above comment that information that related to an identified or identifiable living individual should always be assumed as potentially harmful, and thus involving a risk to the identified person. This is the problem GDPR is mostly attempting to solve, and thus the situation for which the operator need to act on. Similar, if the information is of such nature that it can't be harmful, it is also very unlikely to be information that relate to an identified or identifiable living individual.
When GDPR came it a lot of people asked similar questions as the parent post. What about Apache logs? What about login credentials and sessions. What about CRM and customer registers? The collective answer from that conversation, as I remember (and much of those discussion can be found archived), was that the question depend on the context. If its purely for security then the operator can likely continue on as before per the above quoted section, with some caveats to proportionality. For most everything else, look to the purpose of the GDPR.
