Is storing records of chess games a violation of GDPR? Many amateur chess players store the notations of their games in electronic format (like pgn) so that they can later reference the game for analytical and historical reasons. Information in this file typically include the name and rating of the opponent, the date and location of the game, the moves played and the result. These files are typically only used in private, but they can be stored on public servers and shared with others (it is not unusual for someone to email a pgn of a game to someone else for the purpose of further analysis). Is doing this without approval from the opponent a possible violation of GDPR? Note: I am aware of How does GDPR affect sports statistics? but the answers there seem to indicate that because professional athletes are to some extend public figures, they give up a fair amount of rights to protection of personal information. My question is about amateur chess players, not professionals.
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.
GDPR rights and obligations cover different things: A duty of the data processor towards the government of the country where they operate to present certain documentation, and to implement technical and organizational measures to protect data. These would be audited by government agencies, not the individual customer. A single data subject cannot waive them. A duty of the data processor to process and store personal data only with a legal justification. User consent is one possible justification, if it is informed, revokable, etc. So a single data subject can waive a &quot;ban&quot; on storing his or her data in a database along with all the other users who waived that &quot;ban,&quot; but the duties towards the government regarding that data would still apply. A duty of the data processor to respond to an Article 15 request by the data subject in a certain way and timeframe. If a data subject writes a letter to the data processor and explicitly states that the letter is not an Article 15 request, then Article 15 does not apply. The data subject would of course have the right to make an Article 15 request at a later time.
Term 1 isn't going to hold up, but that is not a GDPR matter. It's just a matter of basic consumer protection law in the EU. You can't offload responsibility for your mistakes. Looking at 2, Dale M. already pointer out that it's now how the GDPR works. You are the Data Controller. X,Y and Z are Data Processors. Article 28(1) of the GDPR is in direct conflict with your disclaimer. You accept zero responsibility, the GDPR says you are fully responsible. That's the exact opposite.
Consent for cookies is not mandated by the GDPR, but by some member states' implementation of the ePrivacy directive. Specifically, cookie consent isn't required for processing personal data (which the GDPR is about), but for storing anything on the user's device unless this cookie is technically necessary (e.g. session cookies, preferences). This leads to a situation where you might not need consent for the analytics themselves, but still need consent for the cookies that are used to track a user for analytics. In practice, the cookie consent requirements are handled very differently. Some sites ignore this requirement, others show a notification banner that doesn't collect active consent like the GDPR would require. Yet other sites bundle cookie consent with other consent issues into a single consent management solution. Currently, the passive notification looks like a best practice in general. However, the actual privacy laws in your member state might have more specific requirements. With regards to consent for Google Analytics, note that the use of anonymizeIP does not directly affect whether you have to collect consent. The purpose of collecting site analytics might fall under your legitimate interest either way (consent is just one among many legal bases). But using the anonymizeIP feature conforms to the GDPR's data minimization principle. Some optional GA features (that share this data, or enrich it from other sources, or use it to target ads) might still require consent. The GA documentation doesn't always make this distinction clear.
Consent of the data subject is only one of several conditions that allow the processing of personal data; these are found at Article 6(1) of Regulation 2016/679. The last, item (f), is also of interest: Article 6 Lawfulness of processing Processing shall be lawful only if and to the extent that at least one of the following applies: (a) the data subject has given consent to the processing of his or her personal data for one or more specific purposes; (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; (c) processing is necessary for compliance with a legal obligation to which the controller is subject; (d) processing is necessary in order to protect the vital interests of the data subject or of another natural person; (e) processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller; (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. Point (f) of the first subparagraph shall not apply to processing carried out by public authorities in the performance of their tasks. Most sports statistics systems maintain identifying data for legitimate purposes pursued by the systems' owners. Since the data in question are already publicly available, and in many cases are made public by the athletes in the course of their lives as public figures, it is unlikely that a court would find that the athletes' interests or fundamental rights and freedoms override the interests of the systems' owners in processing the data.
Do I need to inform the user about storing the score locally? No, there is no need as long as you don't transmit, store or process any personal info. It's doubtful that the score could be considered personal info, but you're not sending it to your servers in any way, so you don't seem to be processing it anyway. Do I need consent for using non-personal AdMob? You have to check this with AdMob, but usually, if it is non-personal, they shouldn't be processing any PI, so you're clear without informing. Do I need to ask for the age? How should I handle kids? Again, you're not processing any PI, so regarding GDPR there isn't any problem. Can I disallow a user from using the app if consent is not given? If you needed consent, no, it would be unlawful to block a user for not giving consent, unless it is impossible to provide the service without it. See recital 43: Consent is presumed not to be freely given if [...] the performance of a contract, including the provision of a service, is dependent on the consent despite such consent not being necessary for such performance.
Yes, but it doesn't matter. This answer discusses gdpr implications. Personal data is any information that relates to an identifiable person. The GDPR has an extremely broad concept of identifiability, also covering indirect identification using additional information and with the help of third parties. Even just being able to single out one data subject, i.e. being able to distinguish different users from another, counts as identification. If you already have a concept of user accounts, any information that is linked with the user accounts and somehow relates to those users would also be personal data. Since you have distinct push tokens per user, it seems like this criterion would be met. Additionally, those unique tokens might be directly identifying by themselves. The GDPR does not allow for semantic games like “it only identifies the device, not the user”. The key here is that the definition of identifiability does not hinge on your intentions, but on objective capabilities: if you or someone else who can come into possession of this data were to attempt to identify the user (such as singling out users from another), would they be reasonably likely able to do that? Since most devices are single-user, being able to identify a device would imply that you're reasonably likely to also identify users. Just because something is personal data doesn't mean you're forbidden from using that data. It means that you'd have to comply with GDPR rules, if you're otherwise within scope of that regulation (e.g. if you're EU/UK-based, or are targeting your services to people who are in UK/EU). For example, basic GDPR compliance steps include having a clear legal basis for your processing of personal data (such as necessity for performing a contract to which the data subject is party, or necessity for a legitimate interest, or consent), providing a privacy notice, and taking appropriate technical and organizational measures (TOMs) to ensure the compliance and security of processing. For example, TOMs regarding these push tokens could involve encryption, access controls, and a plan for installing security patches in order to prevent data breaches. Using push tokens is already a good measure in this context, since they are effectively pseudonymous and prevent linking additional information via that token (two sites/apps pushing notifications to the same person will have entirely different tokens). However, the push notification provider (e.g. Google, Apple, Mozilla) can resolve the pseudonymous tokens and link them to a person, indicating that these tokens are ultimately identifying (even if you can't perform that linking yourself). Note that if GDPR applies, then other EU/UK rules might apply as well. For example, sending electronic messages (such as emails) is subject to anti-spam rules (EU: ePrivacy, UK: PECR). These rules apply regardless of whether personal data is involved. Since the rules are not technology-specific, it is likely that regulators would consider user-visible push notifications to be equivalent to more well understood technologies like email and SMS.
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.