Do the GDPR and Cookie-Law regulations apply to localStorage? We use the localStorage API to store information about the login data to keep the user logged in through various sessions (we do not store personal information), furthermore the localStorage data is not accessible by third-parties. Should we show the banner asking for permission to use cookies (the legislation requires to use the name cookie also for similar technologies) anyway?
The official EU-legislation does not use the word "cookies", except in the recitals. The "Cookie-Law" is part of the Privacy and Electronic Communications Directive 2002/58/EC and is amended by Directive 2009/136/EC, where the relevant text of Article 5(3) is found: Member States shall ensure that the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent, having been provided with clear and comprehensive information, in accordance with Directive 95/46/EC, inter alia, about the purposes of the processing. This shall not prevent any technical storage or access for the sole purpose of carrying out the transmission of a communication over an electronic communications network, or as strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service. This is a Directive, which is not directly binding, member states must implement it in their own law. But there will not be large differences to the text above. The guidance from the UK's ICO includes useful examples in particular about the exceptions to obtain consent. There is an exception to the requirement to provide information about cookies and obtain consent where the use of the cookie is: (a) for the sole purpose of carrying out the transmission of a communication over an electronic communications network; or (b) where such storage or access is strictly necessary for the provision of an information society service requested by the subscriber or user. The best example is a shopping cart: This exception is likely to apply, for example, to a cookie used to ensure that when a user of a site has chosen the goods they wish to buy and clicks the ‘add to basket’ or ‘proceed to checkout’ button, the site ‘remembers’ what they chose on a previous page. This cookie is strictly necessary to provide the service the user requests (taking the purchase they want to make to the checkout) and so the exception would apply and no consent would be required. And there is a negative example which is unlikely to fall within the exception: Cookies used to recognise a user when they return to a website so that the greeting they receive can be tailored In your question you explicitly state localStorage to keep a user logged in. LocalStorage is "storing of information in the terminal equipment of a subscriber". If you want to keep a user logged in, the user has performed a log in step. So you provide a service to keep the user logged in, which is exactly what the user wanted. So the exception would apply and you don't need to obtain consent. For example this stackexchange website also keeps me logged in, so the exception would apply here. However, you must make sure that you don't use the cookie/localStorage in a way which is incompatible with the exception. For example it would probably not be allowed to use the same cookie to count unique visitors to your website. If personal data is processed to store login data, Art. 6(1)(b) GDPR would probably apply; Processing shall be lawful only if and to the extent that at least one of the following applies: (b) processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract; So the GDPR would also not require you to ask for permission.
No. Art. 17(1) GDPR lists conditions when erasure can be requested. None of the listed grounds would apply in this case. However, you might have to explain why you process the data (for moderation purposes as you explained above), and why that is lawfully. In particular Art. 5 and Art. 6 need to be taken into account. In your case, processing will be based on Art. 6(1)(f): (f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child. Even if the data subject would be a 9 year old child, the legitimate interests of you and other forum users outweigh the objection of the data subject. Based on Art. 5, there will be a moment when the data has to be deleted. For example 1 year after the last login attempt.
From the WP 29 Opinion 04/2012 on Cookie Consent Exemption - 00879/12/EN WP 194: Persistent login cookies which store an authentication token across browser sessions are not exempted under CRITERION B. This is an important distinction because the user may not be immediately aware of the fact that closing the browser will not clear their authentication settings. They may return to the website under the assumption that they are anonymous whilst in fact they are still logged in to the service. The commonly seen method of using a checkbox and a simple information note such as “remember me (uses cookies)” next to the submit form would be an appropriate means of gaining consent therefore negating the need to apply an exemption in this case. So a cookie to keep a user logged in, requires consent. But the checkbox "Keep me logged in" is appropriate to gain consent. So in your case you do not need to display a cookie banner.
Yes, you could do this be means of the EULA, provided you are not in the EU yourself. You only have to comply with the GDPR if you are offering a product or service to people that are in the EU. If you are making it clear that whatever you offer is not available to Europeans, you make your site exempt from the GDPR.
The GDPR does not set fixed retention periods. Instead, it says data may not be kept for longer than necessary. What is necessary depends very much on the specific context of the processing activity, in particular on the purpose of processing. The GDPR allows retention for as long as necessary. For example, businesses (including financial institutions) are required to keep financial records. This requirement stems from EU member state law, which also sets specific retention periods. If a business wants to keep personal data in financial records for longer than this retention period, they can't just point to the law to authorize this processing – they must instead find a different purpose why they need to keep the data, and then find a suitable Art 6 legal basis. In some cases, retention periods might not be coupled to a fixed duration, but to certain events. For example, personal data for online accounts should typically be kept until the account is closed, which is potentially indefinite. This follows directly from the GDPR approach of limiting data storage by necessity, not by duration. All processing needs a clear purpose + a legal basis. In the context of a genealogy site, the site should analyze carefully what data they collect for what purposes. These purposes might enable potentially unlimited retention. But such processing must also be covered by a legal basis, and I doubt that the site would have a legal basis to make such storage irrevocable. If the data is collected based on Art 6(1)(a) consent, then the data can only be used as consented to, and consent can always be withdrawn in the future. If the data is collected based on Art 6(1)(b) necessity for performance of a contract, then the data can be used for compatible purposes in the sense of Art 6(4), but that would require a new legal basis (e.g. legitimate interest). If the data is collected based on Art 6(1)(f) legitimate interest, then the data can be used for Art 6(4) compatible purposes but the data subject has the Art 21 right to object to processing. While a genealogy site may have a legitimate interest in keeping supplied data in order to use it for future research, I think this is a fairly weak legitimate interest that can be easily overridden by an Art 21 objection, which in turn could require Art 17 erasure of the data. The genealogy site should also keep in mind principles like data minimisation and data protection by design and by default, so just keeping data for the off chance that it might be useful in the future is not GDPR-compliant. Data can only be collected and processed for “specified, explicit, and legitimate purposes”. The Art 89 privilege for research purposes also imposes conditions. There is a pretty big carveout in these GDPR requirements for archiving purposes in the public interest, scientific or historical research purposes, and statistical purposes. Specific rules for this exemption are given in Art 89 GDPR. The main value of this exemption is that Art 89 research purposes are always considered compatible with the purpose for which the data was originally collected (cf Art 5(1)(b)), though this might not cover data that was collected under the legal basis of consent (cf Art 6(4)). Other GDPR rules stay intact, and Art 89(1) imposes extra steps to consider: Special attention MUST be given to the data minimisation principle. If the research purpose can be achieved without identifiable data, the data MUST be anonymized. If the research purpose can be achieved with pseudonymized data, pseudonymization MUST be used. Appropriate safeguards MUST be implemented (though this just re-iterates the general requirement in Art 24). In some cases, the research purpose stands in conflict with data subject rights like the right to be informed or the right to object. If so, EU or member state law can provide exemptions from the data subject rights, but can also impose further conditions or safeguards. It is not possible to rely on the Art 89 exception without taking member state law into account. Art 89 does not modify necessity-based retention. Now on to the main question: how long can the personal data be kept for research purposes? While Art 89 research purposes allow us to extend the retention period because we have a new and compatible purpose of processing, it does not affect the general principle that data may only be kept as long as necessary for that purpose. In a scientific context, it would be common to preserve many data sets indefinitely for the purpose of enabling reproducibility of the scientific findings. A privately-run genealogy service might not benefit from Art 89. This “research” angle doesn't seem to be a good fit for a genealogy site. Such a site would typically not be collecting personal data for specific research purposes. At best, it would be operating as an archive of personal data which can be mined by future generations of researchers. But the GDPR specifically only considers archiving purposes in the public interest, which might not cover privately run archives. Archives rely on specific privileges in national laws, and severely restrict access to the information. For example, I'm leafing through the law on public archives in a German state. It forbids access for 10–100 years, depending on the date of death of the data subject and on the age of the documents. This leads me to believe that a privately run genealogy site cannot reasonably rely on the Art 89 exemption, and must instead rely on an ordinary processing purpose + corresponding Art 6 legal basis. This doesn't directly prevent indefinite storage, but means that it will be easy for a data subject to invoke their right to erasure. It is not quite enough to say “we will keep the data indefinitely”, it is also necessary to have a clear purpose for this retention.
I don't believe GDPR makes a distinction between 'real life' and 'online'. It's all real life. You can tell anyone that they don't have consent to keep your personal data, but that doesn't mean they always have to delete it. There are six lawful bases for processing of personal data, so if an organisation is using and can justify one other than consent then they don't necessarily have to delete your data when they ask. The six bases are listed by the UK Information Commissioner's Office: (a) Consent: the individual has given clear consent for you to process their personal data for a specific purpose. (b) Contract: the processing is necessary for a contract you have with the individual, or because they have asked you to take specific steps before entering into a contract. (c) Legal obligation: the processing is necessary for you to comply with the law (not including contractual obligations). (d) Vital interests: the processing is necessary to protect someone’s life. (e) Public task: the processing is necessary for you to perform a task in the public interest or for your official functions, and the task or function has a clear basis in law. (f) Legitimate interests: the processing is necessary for your legitimate interests or the legitimate interests of a third party unless there is a good reason to protect the individual’s personal data which overrides those legitimate interests. (This cannot apply if you are a public authority processing data to perform your official tasks.) https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/lawful-basis-for-processing/#ib3
The cookie consent requirement comes from the ePrivacy Directive, not from the GDPR. While the GDPR defines consent, cookie consent is required regardless of whether the cookie actually contains personal data. Instead, it says we can access information stored on an end users device under the following circumstances. Technical access to the information is used for the sole purpose of performing a transmission over a network, e.g. using a browser cache. Accessing the information is strictly necessary for providing a service explicitly requested by the user, e.g. session cookies or a consent-declined cookie. The user has given consent to the access, where consent is defined by the GDPR (freely given, informed, specific, …). The first scenario likely doesn't apply because your cookies aren't likely to be “technical storage or access” in the sense of ePrivacy, and because the tracking cookies wouldn't be used for the sole purpose of carrying out a transmission. The second scenario doesn't apply because tracking cookies are not strictly necessary to interact with the webshop, as evidenced by the possibility to opt out. The service explicitly requested by the user is the webshop or website, not the A/B testing. This only leaves consent as possible grounds for storing or accessing information on the user's device. It is already the storing or access that is covered by ePrivacy, not only later use as a persistent identifier. Your suggestion – to first set the cookie and then delete it if it shouldn't have been set – is more compliant than many set-ups I've seen, but is still technically non-compliant. It is also likely to fail in practice under non-ideal network conditions: if the request to see whether GDPR applies times out, or if the user closes the browser tab before the cookie will be deleted, the tracking cookie will remain without consent. I would instead suggest to consider the following points. It seems that by itself, Optimizely Web cannot be used in a compliant manner since it doesn't provide sufficient control over how cookies are managed. Thus, you should avoid loading such tracking scripts unless consent has been given, or unless this processing falls outside of EU/UK law. Currently, you defer loading of tracking scripts until you know if you have to ask for consent. This can be avoided if you always ask for consent :) This can also be avoided if you load the tracking scripts from a server that can independently determine whether the requests comes from the EU. For non-EU requests and for users with opt-in, the server can return the original tracking scripts. Otherwise, the server returns a dummy script. This server can be independent from your website's hosting. By combining the jurisdiction decision with the loading of the script, one roundtrip is saved and latency is reduced. Finally, no one is forcing you to use Shopify, and ePrivacy/GDPR is not required to accommodate their limitations. You do have different choices: use Shopify, at the cost of slow pages and limited A/B tests use a different A/B test provider that can be used without setting cookies use edge computing to do stuff in between of the browser and the original server use a different webshop platform ignore EU laws Well, one of them is clearly unethical. But you do have choices, and which choice you take is a business decision. Slow pageloads and consent banners are likely costing you conversions, but Shopify might be providing massive value that outweighs all that.
By itself, a chess position is not personal data. Personal data is “any information relating to an … identifiable natural person”. Since the file in question includes the name of the opponent, it is clearly personal data about the opponent. If the files are used for “purely personal or household purposes”, the GDPR won't apply per Art 2(2)(c). If the files are shared more widely – especially if the files are published – then GDPR becomes relevant. The person/entity who is data controller has to consider GDPR compliance. Data controller is whoever determines the purposes and means of processing of personal data (the “why” and “how”). The first question would be under which legal basis this personal data about another person can be shared. The GDPR offers multiple legal basis, notably “legitimate interests” and “consent”. Consent is always an option, but must be freely given (entirely voluntary). Legitimate interests can serve as a legal basis after a balancing test between your interests and the data subject's rights and interests. This balancing test also depends on the reasonable expectations of the data subject, which in turn depends on the more general context. For example, in a chess community where such sharing is completely normal there would likely be a legitimate interest for you to share games as well, if the games occurred in the context of this community. But if you play a game with a friend who is not part of this community, the friend cannot reasonably expect that their name and associated personal data would be shared. The second question would be how you would satisfy further GDPR compliance obligation, in particular the Art 13/Art 14 right to information. When collecting personal data, it is necessary to provide certain information such as your identity, what processing is being carried out, and how the data subject can invoke their GDPR rights (a privacy notice or privacy policy). This might be difficult or awkward to do. Practical solutions to these problems: If you want to share a game but aren't sure that the opponent is OK with this, remove identifying aspects such as names. For example, you could crop a screenshot, or describe the game in textual notation without listing the opponent's name. Play the game via a chess website that publishes the game. This way, the website is the data controller, and you and the opponent are the data subjects. This avoids having to act as the data controller yourself. This might work for private interactions, but not e.g. if you run a chess club and require members to play via that website – you might still be in a data controller role then and have full compliance obligations.