GDPR - Recording simple page views We are currently using google analytics to track our site. The issue we now have with GDPR is we don't have a clear picture of our entrance pages. Our landing page data is messed up badly because the tracking cookies have to be blocked initially until the consent is given. In our case it's a soft opt-in on continual use. So I was wondering. Can I add some in house code directly on the server to record landing page hits. only recording say the page name &amp; time. Maybe even a couple of element clicks. This way no cookies are used and there is 0 chance of identifiable relational data being used other than reading the php session. Which doesn't count as UI. And more importantly I don't need consent and can start getting the data I need right off the bat?
The so called "cookie law" is Article 5(3) of Directive 2002/58/EC: Member States shall ensure that the use of electronic communications networks to store information or to gain access to information stored in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned is provided with clear and comprehensive information in accordance with Directive 95/46/EC, inter alia about the purposes of the processing, and is offered the right to refuse such processing by the data controller. This shall not prevent any technical storage or access for the sole purpose of carrying out or facilitating the transmission of a communication over an electronic communications network, or as strictly necessary in order to provide an information society service explicitly requested by the subscriber or user. So this does not only apply to cookies, but to any way to store or retrieve information on/from the equipment of the user. When you use a PHP session, the session ID is stored in a session cookie or URL parameter. If a URL parameter is used, it is also stored on the equipment of the user, so the "cookie law" would also apply to that, but I am not sure about that. The Article 29 Data Protection Working Party (Art. 29 WP) has written Opinion 04/2012 on Cookie Consent Exemption. It considers a session-ID to be exempted from the requirement of informed consent: 3.1 “User-input” cookies The term “user input cookies” can be used as a generic term to describe session cookies that are used to keep track of the user’s input in a series of message exchanges with a service provider in a consistent manner. These would be expected to be first party cookies typically relying on a Session-ID (a random temporary unique number) and expire when the session ends at the latest. First party user input session cookies are typically used to keep track of the user’s input when filling online forms over several pages, or as a shopping cart, to keep track of the items the user has selected by clicking on a button (e.g. “add to my shopping cart”). These cookies are clearly needed to provide an information service explicitly requested by the user. Additionally, they are tied to a user’s action (such as clicking on a button or filling a form). As such these cookies are exempted under CRITERION B. So basically, a PHP session ID cookie does not require consent. However as soon as a session id is used for analytics, it is not exempted: 4.3 First party analytics Analytics are statistical audience measuring tools for websites, which often rely on cookies. These tools are notably used by website owners to estimate the number of unique visitors, to detect the most preeminent search engine keywords that lead to a webpage or to track down website navigation issues. Analytics tools available today use a number of different data collection and analysis models each of which present different data protection risks. A firstparty analytic system based on “first party” cookies clearly presents different risks compared to a third-party analytics system based on “third party” cookies. There are also tools which use “first party” cookies with the analysis performed by another party. This other party will be considered as a joint controller or as a processor depending on whether it uses the data for its own purposes or if it is prohibited to do so through technical or contractual arrangements. While they are often considered as a “strictly necessary” tool for website operators, they are not strictly necessary to provide a functionality explicitly requested by the user (or subscriber). In fact, the user can access all the functionalities provided by the website when such cookies are disabled. As a consequence, these cookies do not fall under the exemption defined in CRITERION A or B. However, the Working Party considers that first party analytics cookies are not likely to create a privacy risk when they are strictly limited to first party aggregated statistical purposes and when they are used by websites that already provide clear information about these cookies in their privacy policy as well as adequate privacy safeguards. Such safeguards are expected to include a user friendly mechanism to opt-out from any data collection and comprehensive anonymization mechanisms that are applied to other collected identifiable information such as IP addresses. In this regard, should article 5.3 of the Directive 2002/58/EC be re-visited in the future, the European legislator might appropriately add a third exemption criterion to consent for cookies that are strictly limited to first party anonymized and aggregated statistical purposes. First party analytics should be clearly distinguished from third party analytics, which use a common third party cookie to collect navigation information related to users across distinct websites, and which pose a substantially greater risk to privacy. So Art. 29 WP does not consider it a privacy risk under the conditions in the last two paragraphs. At least in some EU countries (Like the Netherlands) you would be exempted from the requirement of informed consent because of that. In your question you also mention you use "a soft opt-in on continual use". That is not sufficient to obtain consent.
Yes, their waiver has no legal basis and is invalid under the GDPR. They should have hired a better lawyer. GDPR rights cannot be waived (mrllp.com). The last bit should have been: Therefore, in consideration of my participation in any project, I understand that retaining my name and email address, as described above, does not require my consent and that the right of erasure, as spelled out in the GDRP Article 17 (1) b does not apply. The legal basis for our lawful processing of this personal data is Article 6 (1) f ("processing is necessary for the purposes of the legitimate interests pursued by the controller"). I.e. there is nothing in the GDPR that compels GitLab to erase this information, but their waiver is bogus. Keeping track of individual contributions in a software projects is necessary for a number of reasons, including security (if somebody contributes code that jeopardizes security, you want to audit everything that person has contributed).
The GDPR allows the right to access to be limited if this access would “adversely affect the rights and freedoms of others” (Art 15(4) GDPR). However, access to the recording would not give you more information than you've already received during the phone call, so this exemption is quite unlikely to apply in any case. UK data protection law also has a large list of additional exceptions, as summarized here by ICO guidance. These exemptions also cover some aspects of trade secrets, and even mention insurance examples. However, not such exemption is likely to apply in your case: the recording would not give you more information than you already have. If the data controller is concerned about some parts of the conversation, they should provide a redacted copy and explain why the redactions were performed. They should not reject the request outright. If the data controller wants to reject the request entirely, they must do so within the time frame for the DSAR (one month), must explain their reasons, and must inform you that you're allowed to lodge a complaint with your supervisory authority or to sue them. However, ICO guidance is flexible on how detailed the reason for refusal can be: Where an exemption applies, the reasons you give to an individual for not complying with a request may depend upon the particular case. For example, if telling an individual that you have applied a particular exemption would prejudice the purpose of that exemption, your response may be more general. However, where possible, you should be transparent about your reasons for withholding information. Here, I don't see any reason why full transparency would be a problem, so I would expect that the data controller can point to a specific exemption in UK data protection law. If you are unsatisfied with the data controller's response, please consider lodging a complaint with the supervisory authority. In the UK, this is the ICO. On the ICO complaints page, you can fill out the online form about “your personal information concerns”.
Either approach can be GDPR-compliant. An issue to consider is that you as a data controller relying on consent “shall be able to demonstrate that the data subject has consented to processing of his or her personal data” (Art 7(1)). This might be simpler if a record of the consent is linked to a user account. On the other hand, the GDPR's data minimization principle would suggest that decentral, offline approaches are preferable. So you do have some flexibility here, as long as you feel comfortable demonstrating that your approach is compliant when investigated by a supervisory authority. In many cases, consent is not an appropriate legal basis to start with. It is one of several options in Art 6(1) GDPR. If a data processing activity is necessary for fulfilling a contract with the data subject, then Art 6(1)(b) is more appropriate. If the processing is necessary for a legitimate interest, then Art 6(1)(f) would work – after conducting a balancing test. Art 6(1)(a) consent is appropriate when the processing activity is not necessary, or when a legitimate interest balancing test doesn't go in your favor, or in some cases when required by law. For example, consent is required when processing special categories of data (such as biometrics), or when accessing or storing information on the end user's device, beyond what is necessary for a service explicitly requested by the user (the “cookie law”, but much more general than cookies). Consent also has heightened compliance requirements compared to other legal bases. The data subject must be able to make a free decision, without any coercion. You must not use dark patterns. You must leave the data subject a real choice. You must not make access to your app conditional on giving unrelated consent (like providing access to a game only when the user gives consent for personalized ads). The data subject must be able to easily withdraw consent later, without suffering detriment for this. The EDPB has issued relevant guidelines that might be helpful here: EDPB guidelines 05/2020 on consent EDPB guidelines 2/2019 on Article 6(1)(b) in the context of online services (also relevant for apps) TL;DR: what is “necessary” for performance of a contract is an objective question, and should generally be considered from the data subject's perspective. It is not possible to circumvent consent requirements by putting unrelated processing purposes like “analytics” into a services' terms of service. The main purpose of this document is to serve as a rebuttal of Facebook's GDPR compliance strategy. But it's perfectly fine to avoid asking for consent for those processing purposes that are actually necessary for the user. I've noticed that you mentioned various Google services like Analytics and Firebase. To the degree that your use of these services implies an international transfer of personal data into the US, it might be impossible to be GDPR-compliant. Be wary of claims that you're only transferring “anonymous” data, as the GDPR has a fairly broad concept of identifiability.
As always, it depends. However, it is by no means certain that any public facing hobby project, such as a web app, is exempt from having to comply with the GDPR. Since the GDPR is only a few days old, we have of course no case law based upon the GDPR itself yet. However, when considering this, one should take the following two facts into consideration. 1. The "personal use exeption" in the GDPR is not new. The personal use exemption is unchanged from the article 3(2) of Directive 95/46/EC. (There as a lot of lobbying for removing "purely" from the sentence – but drafters wanted to keep it.) 2. Case-law under the previous regulation restricts the scope of the exception The ECJ has ruled on the scope of the personal use exception in two cases: C-101/01 C-212/13 In both these cases, the ECJ took an extremely restrictive view, and concluded that the personal use exemption did not apply to the processing done by these individuals. In C-101/01 it can be argued that the hobby project as a blogger was connected to the controllers professional activity (she was a catechist in a local church, and blogged about her work. including her colleagues). But in C-212/13, there no such connection to professional or commercial activity. Here, the controller operated a CCTV to protect his home, but set it up to also capture public space, and that was enough for the ECJ to decide that the personal use exception did not apply. Discussion Case-law based upon Directive 95/46/EC is in no way binding for a future court that need to rule based upon the GDPR. We need to wait for case-law decided under the GDPR to be able to have some degree of certainty about the scope of the "private use exception" under GDPR. However, given what we know about how the ECJ has ruled in these cases in the past, I think it is hazardous to think that just because what you are doing on the web is just a "hobby project" not connected to professional or commercial activity, you are exempt from complying with the GDPR. Conclusion IMHO, you may be exempt, or you may not be exempt. I think it really depends on your activity in your hobby project, and to what extent this project processes the personal data of other people than yourself.
No. As long as you don't see and have no means to access this data, but it is under the control of the user at all times, you are neither the controller or the processor of this personal data, and the GDPR does not apply to you.
The GDPR does not prescribe how exactly consent must be managed, as long as consent was obtained in line with the GDPR's principles. Similarly, the EDPB does not provide concrete recommendations in its guidelines on consent, mainly noting that Controllers are free to develop methods to comply with this provision in a way that is fitting in their daily operations. I would not be too concerned with edge cases like failing HTTP requests, at least not any more than for other HTTP endpoints. If the user indicated consent, and you act on that indication of consent in good faith, that's probably fine. However, remember that you must provide a equally easy way for the user to revoke consent later. If the user changes their mind, they can use the mechanism that you offer to inspect their consent status, and revoke it if they want. But again, how to do that is largely up to you.
The GDPR applies regardless of where and how data is processed. But it is necessary to look at what the processing activities in question are, and who is the controller for these activities by determining their purposes and means. This argument is supported: by the absence of relevant exemptions in the GDPR by the GDPR's broad definition of the data controller by the ECJ's analysis in the Fashion ID case GDPR Exemptions For certain constellations (e.g. controller = natural person, purposes = purely personal or household activities) that processing is exempt from GDPR compliance (see GDPR Art 2(2)). However per GDPR Recital 18, the GDPR would still apply “to controllers or processors which provide the means for processing data for such personal or household activities.” For example, this means that I am able to use WhatsApp to process my friends' contact information for purely personal purposes because I'm exempt from the GDPR with respect to that processing, but Facebook is still subject to the GDPR regarding how they process personal data collected via WhatsApp. Already on the basis of the GDPR providing no exception for processing on someone else's computer, I disagree strongly with the answer you cited (and have already written a competing answer). It seems entirely counterfactual. How to figure out who the controller is. Per GDPR Art 4(7), controller is whoever “alone or jointly with others, determines the purposes and means of the processing of personal data”, although other laws might provide more specific criteria for individual purposes or means. We will return to that definition in the next section. The ICO has provided a checklist to figure out if you're a data controller or perhaps a joint controller. Some of the questions are aligned with the above definition, like “We decided what the purpose or outcome of the processing was to be”. Other questions are there as a contrast to the data processor role, e.g. “We have complete autonomy as to how the personal data is processed”. Analysis of the Fashion ID case (ECJ C-40/17) This judgement provides a detailed analysis of who the data controller is, and is therefore relevant to the question. Fashion ID had embedded a Facebook “Like” button on their website, thus causing the visitor's browser to transmit personal data to Facebook. Fashion ID asserted that they were not the data controller, since they had no control over what data was collected by the Like button and how it was subsequently used by Facebook. Fashion ID relied in part of the argument that they weren't the controller because processing happened on the visitor's computer. This ruling was made on the basis of the Data Protection Directive 95/46 which was repealed by the GDPR. However, since the DPD and GDPR have effectively identical definitions of “controller” and “processing”, the court's analysis remains highly relevant. In the following I'll “translate” all DPD references to the GDPR, in analogy to GDPR Art 94(2). The court found that Fashion ID was a data controller for the processing by the Like button, and that it was a joint controller with Facebook for this processing. However, Fashion ID was only a controller for those processing activities in which they played a part, not for subsequent processing of the data that was controlled by Facebook alone. Relevant details from the Judgment (ECLI:EU:C:2019:629): Paragraphs 65–66: The GDPR tries to achieve a high level of data protection through a broad definition of “controller”. Thus, an overly narrow interpretation that counteracts this goal is incompatible with the law. Paragraph 68: An entity is a controller when it exerts influence over the processing for its own purposes, thereby participating in determining the purposes and means of processing. Compare the GDPR Art 4(7) definition of “controller”. case law: C-25/17 Jehovan todistajat, ECLI:EU:C:2018:551, paragraph 68: “However, a natural or legal person who exerts influence over the processing of personal data, for his own purposes, and who participates, as a result, in the determination of the purposes and means of that processing, may be regarded as a controller”. Paragraphs 67, 69–70, 82: It is not necessary to have a single controller, there can be multiple joint controllers. The joint controllers can be involved to different degrees. You can be a joint controller without having access to the personal data. case law: C-25/17 Jehovan todistajat, ECLI:EU:C:2018:551, paragraph 69: “Furthermore, the joint responsibility of several actors for the same processing, under that provision, does not require each of them to have access to the personal data concerned”. case law: C-210/16 Wirtschaftsakademie Schleswig-Holstein, ECLI:EU:C:2018:388, paragraph: 38: “In any event, [GDPR] does not, where several operators are jointly responsible for the same processing, require each of them to have access to the personal data concerned.” Paragraphs 71–74: Processing can consist of many different individual activities. A controller might only be involved in some of them, and can only be a controller for those activities for which they (jointly) determine purposes and means of processing. Paragraphs 76–79: Fashion ID was able to determine the purposes and means of processing regarding data collection and transmission by the Like button. The act of embedding the button showed that they had decisive influence over the processing: without the embedding, the data processing would not have occurred. To summarize the relevant conclusions: someone is a data controller when they participate in determining the purposes and means of processing for some processing activity for joint controllers, this holds regardless of whether they have access to the data or participate in the processing itself one cannot be a controller for a processing activity for which they cannot determine purposes and means. Conclusion and application to the question This analysis reaffirms my competing answer to the cited answer that it is important to determine who the data controller is. The Fashion ID case shows that is important to perform this analysis on a fairly granular manner, on the level of individual processing activities. For processing on a data subject's computer by a program written by another provider, this means: some processing activities might be solely under the user's control, then they are the sole data controller (or might be exempt from GDPR) for some processing activities, the software developer might decide alone for which purposes and through which means the processing is carried out for other activities, the user and data controller might be joint controllers. This does not require explicit agreement but can result implicitly. This does not require that the software developer has access to the personal data undergoing processing. For example, a spreadsheet application might be used by an end user to process personal data on their own computer (or via a cloud application, with the same conclusions). We can consider different processing activities performed by the software: sorting, transforming, and other processing of the data in the spreadsheet is solely under the end users control, so they are the data controller (if they aren't exempt) collecting usage analytics (where those analytics signals are personal data for which the end user is the data subject) is solely under the software developers control uploading crash reports (where those reports contain personal data from the end user and contain contents from the currently opened spreadsheet) is more complicated. The software developer is definitely a controller. The end user has a dual role here as a data subject and a joint controller (if they aren't exempt) because the crash report processes personal data for which they are the controller.