Whether or not this site is compliant depends on whether the "Got it" button is taken as affirmative consent for non-essential tracking or not.
Their privacy policy says:
> Other than in the restricted-access portions of the Web Site that require an ACM Web Account, ACM does not log the identity of visitors. However, we may keep access logs, for example containing a visitor's IP address and search queries. We may analyze log files periodically to help maintain and improve our Web Site and enforce our online service polices. ACM only uses analytical cookies and does not use any user-specific targeting cookies.
> A cookie is a small file of letter and numbers that is placed on your device. Cookies are only set by ACM when you visit restricted portions of our Web Site and help us to provide you with an enhanced user experience. Raw log files are treated as confidential.
So... not sure why a public portion of their website straight-up won't load without them. They're clearly not only checking/setting cookies on certain pages, otherwise they wouldn't know that my cookies were disabled.
In general, it's unfortunate their page doesn't degrade gracefully if cookies are disabled (though that's not always possible; for example, you can't assume that traffic Cloudflare can't analyze for trust is trusted... but those BACKEND and sessionState cookies being mandatory feels lazy).
If you use it only to keep track of the logged in status and access management of the user then you are compliant.
If you use it to track the user server side, then depending on the use case consent is probably required.
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.
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.
https://ico.org.uk/for-organisations/guide-to-pecr/what-are-...'. - Check developer tools and cookies.
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.
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 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.
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 :)
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.
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 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.
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.
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.
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.
I feel like this is a horrible implementation of this browser feature. If the user disables cookies, the browser shouldn't tell the website "I don't support cookies", but rather let the website's JS think it happily set a cookie but not store anything when you navigate to any other page.
(Note that you could also check server side on the redirection page)
I believe (but I cannot formally prove it) that it's actually impossible to prevent detection.
It's a bit similar to private browsing mode (which in that case should in theory not be detectable) but has revealed to be a challenging problem.
That said, I think cookie auto deletion basically satisfies that use case? I personally have cookies set to wipe when I close my browser, and I close my browser fairly frequently. That's not quite as often as you're suggesting though.
I've just been trying out the tridactyl Firefox plugin. (vi-inspired keybindings for browser usage).
In tridactyl, the element can be hidden by typing out ";k", followed by a couple of letters to select the element hierarchy to hide.
Is it really interesting, though. For example, we have seen this as a very common retort in HN comments every time an author is critical of advertising, tracking/analytics, etc. Someone points out the author's site itself uses the thing being critiqued.
Is that supposed to detract from the argument being made by the author. That does not make much sense.
It is a bit like another common retort we see in discussing tech company behaviour: "But everyone else is doing it." Does that make it OK. Or one we see when discussing regulatory action: "They should be focusing on X not Y." Don't look here, look over there.
I am highly skeptical of comments that try to leverage these tactics. The message is what it is. Whether or not it is valid does not depend on who is voicing it, where it appears, or what's going on somewhere else. This is pure misdirection.
This paper might be a worthwhile read. It makes little sense to pre-judge it before reading, simply because it appears on ACM's website, and ACM's website developers try to get users to enable cookies. What if the paper is re-posted on a site with no Javascript and that does not try to set cookies. Does the content of the paper then become "legitimate". Why or why not.
It is easy to retrieve this paper without using cookies, from another site. For example,
https://web.archive.org/web/20210305175101/https://dl.acm.or...
PDF: https://web.archive.org/web/20200701025846if_/https://dl.acm...
Not trying to single out this one comment. It's fine. The paper is not really arguing for or against banners and other notice and consent mechanisms, just studying their use. I cannot even see the banner because I use a text-only browser.
The most interesting paragraph in the paper IMO is the last one. They ask why the client, e.g., through browser settings, cannot be in control of the legal consent mechanism. What if clients were to sed an additional HTTP header to indicate whether or not the user consent to cookies. For example, Allow-Cookies: no.
The online advertising companies have apparently fought against this, e.g., the DNT header. If you enable DNT in one popular browser deployed by an advertising company you get this ridiculous warning message. Why the heck is it a big deal if the user controls the headers sent and the server has to honour them. When you read RFCs about www development they always make it sound like clients and servers on are equal footing. The reality is quite different. These companies want to control how a user "consents".
If it's so hard to do the right thing that someone who apparently both cares and understands the problem space still messes it up, then the issue is more fundamental than education.
In general, demonstrating GDPR compliance is an expensive process, and I’m not sure that a US nonprofit corporation like the ACM ought be trying.
Is this somehow suggesting nonprofits are less liable? I was quite shocked to read an article that gave a weekend sports team as an example of an organization that was maintaining GDRP protected data, basic the list of their team members
"It shall be as easy to withdraw as to give consent."
All those dark patterns to hide the rejection, keep some things ticked etc. are a complete waste of time. They all violate GDPR and are just another case for: no one has read the GDPR and is just copying everyone else.
It is just a waste of developers time, hiding rejection of consent, making it less understandable, etc. is just violating the GDPR. Google is violating it, Facebook is violating it,... but they have money for lawsuits, if you have it too, no problem, just copy them, if not, reconsider your tactics.
Bottom line, you are wasting time and effort to implement it, you are trolling the users with popups and at the end even the consents that you got is invalid and void. So why doing it?
Imagine the scenario, your beautiful website, your beautiful android application is being checked for a GDPR compliance based on lawsuit.
And you bring in your dark-patterned consent dialog (whoever the provider is, it doesn't matter, YOU are the controller, YOU are the one who needs to care for your visitors/users privacy and you will be fined if google ads are violating privacy by their scripts run from your application/site).
What do you think will happen, you will get pat on your back and someone one will say "you poor thing, you didn't understand, let me pardon you" or you will get an "Tommy Lee Jones" implicit facepalm [1]?
Same goes for all the sites that stuff the user id into the "consent/no consent" cookie where just setting "consent=yes" or "consent=no" would be enough. Again, just same thing, for avoiding storing one PII you create another PII (by GDPR, anything that is unique to a person is PII) and violate it by doing that. Just why. Dont bother. Wait for a law suit and that is it. Dont just waste more money with same result as not wasting it, rather label a jar with "GDPR Lawsuit" label and stuff the money wasted for illegal consent methods into the jar.
[1] https://me.me/i/implied-facepalm-when-something-is-so-ridicu...