Is it legal to compel users to share data in order to access more features, when the features being accessed do not require the data being requested? Apologies in advance if this is not the correct exchange for this question. I am a developer working for a company that owns a healthcare application. They operate exclusively in the EU. As part of the data consent / privacy policy, users can agree to allow the company to collect additional data about their account, in addition to our standard terms. I have been asked to implement a set of new features. Part of this implementation involves making these features inaccessible to users who have not allowed the company to collect additional data. If the user agrees to share this data, they can access the new features. However, these new features do not need to use the additional data in order to work. I am concerned that this is illegal and am hesitant to carry out the project. I have spent some time trying to research this online but have been unable to find clear advice on the legality of leveraging feature access against data consent options. I do not think this is considered best practice, but I am unable to assess if it is illegal, or just a poor decision. Is it legal to compel users to share data in order to access more features, when the features being accessed do not require the data being requested?
Any processing of personal data needs a legal basis, for example necessity for some contract or legitimate interest. If no other legal basis allows the processing, you need to acquire consent. Consent must be freely given. If something is gated behind consent without that consent being really necessary, this might coerce users and they would not be able to consent freely. The GDPR does not have a hard ban on this, but it explicitly calls out that this case must be considered when determining whether consent is valid. So what your company is trying to do is in a dark grey area. Not necessarily wrong, but likely so. Consent could be made free if users have an actual choice. For example, some online newspaper sites had success with a “pay or consent” wall. (Success in the sense that some data protection authorities allowed this). In your case, this could mean that users either consent to extra data collection, or that they buy some reasonably priced premium mode. But none of this is for you to decide. You can voice your doubts that the software would be compliant. You could also ask if the Data Protection Impact Assessment document for this proposed processing is available (creating such an assessment is likely mandatory in this case). But in the end, it is the company's obligation to be compliant, and this responsibility is largely shouldered by the company's data protection officer (to whom you can turn with further questions).
The European Convention on Human Rights has an article about privacy (article 8). Note that this is from the Council of Europe, which is not the same as the European Union: non-EU member states such as Russia, Turkey, and Azerbaijan are also part of the Council of Europe and therefore the ECHR. I'm not sure if you first have to go to a lower court, but the European Court of Human Rights is the authority on this (commonly mistaken for the European Court of Justice, but they are distinct entities). According to this ruling of the ECtHR, it is not illegal to monitor your employees' communications per se. However, the monitoring has to be: for legitimate purposes ("the employer had only accessed the account in the sincere belief that it contained only messages of a professional, not personal, nature"), proportionate ("it was the only possible way available"), and communicated to the employee (or, if the monitoring is not announced, at least the restriction on personal use should be communicated, for example through company policy). In the European Union, there is also the GDPR, but this does not change much. It applies to your employer the same as any other organisation and basically says that they have to be reasonable about it: collect only what they need, for a legitimate purpose, and tell you about it. I think you should be able to request a copy of any data they collected about you, ask a human to review an automated decision, and your other usual rights. They don't need your consent to start collecting data, as Esa Jokinen already commented: "GDPR doesn't even require consent to handle PII data, but the consent is just the last option when there's no other legitimate reason to process the data." In fact, your employer probably cannot ask you for consent: because of the employer–employee imbalance of power, the consent would probably not be considered to be freely given (where this article mentions "The GDPR states", I think they are referring to recital 43).
Yes. The license itself is really just one sentence long, and states explicitly that this is allowed. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
Simply use a cookie to store consent. First consider the opposite. If a user does not agree to store cookies, a cookie is the only way to remember this, as you want to avoid a new pop-up on every page-load. Because this use of a cookie is functional, you don't need permission to store that cookie. You seem have the impression that you have to prove towards the ICO if someone has provided consent. However I think it would be sufficient if you can demonstrate how your website works technically. In particular whether consent is handled properly. You might need to create screenshots or a screencast to do so. Add new proof after each major update of your website. Storing consent server-side would violate the data minimization principle of the GDPR I think. In particular because you would need to do something to be able to identify users. That would violate Art. 11(1) GDPR: If the purposes for which a controller processes personal data do not or do no longer require the identification of a data subject by the controller, the controller shall not be obliged to maintain, acquire or process additional information in order to identify the data subject for the sole purpose of complying with this Regulation. Notice it is possible to configure google analytics in a way so you don't need any consent. See my answer to this question. Just IP anonymization is not sufficient.
You are missing something. The fact that you have a tick box and its state is saved in the database is enough. The burden of proof is only "on a balance of probabilities", so someone arguing that they didn't consent would have to demonstrate that you falsified the database entry somehow. In terms of GDPR requirements in general you don't need a greater level of proof than this, the key thing is that you have a robust system in place to obtain proof (such as not allowing data into the database without a tick in the box).
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.
Yes, there would still be an obligation to comply with erasure requests – if the data subject can be identified, and if the GDPR applies. This is a case for Art 11 GDPR: processing which does not require identification. The pastebin site is not required to collect identifying info just in order to facilitate later deletion. If the site is unable to identify the data subjects, then the data subject rights (like access, rectification, erasure, restriction, or data portability) do not apply. Other rights like the right to be informed and the right to object do remain, though. But if the data subject provides sufficient additional information that makes it possible to identify their records, then the data subject rights apply again. In practice, this is likely going to mean that anyone with access to a paste will be able to request deletion, since the site would have no ability to verify the identity of the data subject beyond the information in the paste. None of this absolves the site from implementing appropriate technical and organizational measures to ensure the security of this data. Even though the pastes might not be directly identifying, they are personal data and are far from anonymous. Common practices like numbering pastes with a sequential ID or showing recent pastes on a homepage have to be viewed critically. My go-to recommendation is to assign a cryptographically random UUIDv4 ID to the post, so that it is practically impossible for anyone to find the paste unless they were given a link by the uploader. Your idea to delete pastes after a fairly short retention period is also good. This helps with security, and it is in line with the GDPR's data minimization and storage limitation principles: data may only be kept as long as necessary for its purpose. On the other hand, quick deletion might not be in line with the purpose of these pastes – it all depends on context. You mention that this is an US-based site. If so, there's a question whether GDPR would even apply. GDPR will apply per Art 3(2) if the data controller is offering its services to people who are in Europe. Here, “offering” does not mean mere availability of the website, but that the data controller intends the service to be used by such people, in particular if the service is somehow targeted or marketed to such people.
There is no requirement about "data" in the GDPR, so provided this is just "data", no. An empty form with fields for personal data contains no personal data. On the other hand, if the form is filled in by the user with personal data (as defined in GDPR article 4), and you receive a copy of the filled in form and process these personal data (as defined in GDPR article 4) - then the answer is: Yes. However, if you do not process the personal data (i.e. the form is just printed out on paper and filled in with a pen, and nobody except the data subject has access to the piece of paper with the filled in form - then the answer again is "no").