Is this Cookie scenario GDPR compliant? I noticed that many websites, including StackExchange websites just have a banner while full functionality is provided by the website, which is probably not GDPR compliant. Is this true? As far as I know, legally you may not load ANY external JavaScript files or pictures without getting consent first. So my prototype would be the following: Every time a user visits the website under any URL the cookie consent will get checked and if the cookie is set already the user will get redirected to the URL they were visiting. But if they don't have the cookie (a.k.a. haven't given consent) no external pictures or JS gets loaded and the user goes to a captive portal where they got to accept the cookies. Is this GDPR compliant? Is this secure enough? Let me know whether this should be posted on Law StackExchange.
There are a number of misconceptions here. GDPR does not generally impose blanket bans, but things get dicey if you're using data in a way that is not strictly necessary. Consent (freely given opt-in) is a way to continue nevertheless. A website without ads, tracking, or potentially tracking embedded content can probably work without having to ask for consent. Under the GDPR, every processing of personal data needs a purpose. This purpose must be covered by a legal basis. Some processing might be legally mandated or required by a contract with the data subject. It's also possible to base processing on a legitimate interest, but this requires a balancing test that also considers the data subject's rights and interests. As a last resort, consent can be an appropriate legal basis, but this comes with additional restrictions. Once you have a clear purpose that is covered by a legal basis, you can process the minimum data necessary to achieve the purpose. Sometimes, laws prescribe a particular legal basis. This is the case for cookies. You can use cookies (and similar technologies that access information on the end user's device) as strictly necessary to provide a service explicitly requested by the user. If you go beyond that, the ePrivacy Directive says you must obtain consent first. So for example, session cookies, shopping carts, or cookies that remember a “dark mode” preference are all perfectly fine because they are strictly necessary for something the user is trying to do. Also, you can use cookies to remember if the user gave or declined consent. On the other hand, analytics or tracking cookies are not necessary and require consent. If a website embeds third party content, this discloses personal data such as IP addresses to the third party. This disclosure requires a legal basis, most likely consent. There is case law about this regarding Facebook Like buttons on a page (→ Fashion ID case) but the same principle can be generalized to embedded Tweets or Youtube videos, images, or JavaScript files. A common way to handle this is to replace the embedded content with a placeholder, and to only load the embed once the user gives consent. But not all other domains or services are “third party” in the sense of the GDPR. When you engage a company to act as a data processor on your behalf, they are contractually bound to only use the data as instructed by you, and not for their own purposes. The GDPR allows you to outsource processing activities such as serving web content, as long as you have a suitable contract in place. Such “data processing agreements” are common for hosting providers or CDNs. When consent is to be used as a legal basis, it's important to consider the various conditions that the GDPR imposes (see Art 7 GDPR). The core principle is that consent must be freely given. You cannot make access to a site conditional on consent, so a naïve cookie wall or captive portal will be non-compliant. It's fine to force a choice, but “no” MUST be valid and possible. That consent is freely given also means that you must provide enough context for the user to make an informed decision, that the user must give consent through an unambiguous, affirmative action (consent is never the default), and that consent must be specific for a particular purpose (you can't bundle unrelated purposes). That is why modern consent management tools have multiple layers of information and allow the user to give consent for individual purposes (e.g. yes to analytics but no to ad personalization). In your particular context, you could proceed as follows: Figure out what kind of external content you're currently including. Can you enter into a data processing agreement with the external providers? If so, sign that. Can you host the content locally? This can be an easy solution except for video streams. Careful: copyright concerns might make this impossible. Can you replace the content with placeholders that only load if and when the user gives consent? That way, the rest of your site remains accessible without annoying consent walls. If the third party content is an unavoidable and essential part of your page, use an interstitial to inform the user of the risks before they proceed.
There is no clear answer to this question. The GDPR doesn't not apply, but it delegates rules for processing in the context of employment to member states. That means, the laws in your country might override the GDPR here. As the data controller in this situation, the company must protect the personal data it processes, including the personal data of employees. Protection doesn't have to be absolute, just proportional to the risks. It may be fine to treat data in one context more carefully than another. This is always a judgement call of the data controller. There is nothing about holiday rotas where the GDPR would require them to be kept under lock. The company could very well decide that this data isn't very sensitive and that everyone can look at it themselves. For example, the company might argue they have a legitimate interest for this so that employees can see whether their colleagues are unavailable. But until the controller makes such a decision, the rota contains other person's personal data and cannot be disclosed without a legal basis. Here, I see three reasons why the company might be acting that way: They are overly careful with GDPR compliance and are cargo-culting restrictions that are not actually necessary. They have made a conscious decision to restrict access to this data to protect the private life of employees. They want to make it more difficult for employees to take time off.
What would be the legal validity of this behaviour? Your changes to the browser source of the website contract or license of Terms of Service (TOS) - essentially a "click-wrap" license - before agreeing to it means nothing in a legal sense, other than to void the contract. The other party (the website) can't possibly agree to those contract changes without them being submitted as contractual changes and agreeing to them, if they did agree to them. That's basic contract law. That website TOS probably has a clause that says that if you don't agree to the TOS in full, as written, without modifications, you can't use the website. And the TOS may also say that they reserve the right to prevent you from using the site by closing your account or even blocking your access. Your "witness" to the contract changes is meaningless, as your witness is not a party to the contract. And any witness to the fact that you have changed the terms of the TOS before agreeing to it would work against you in a civil proceeding as proof of your attempt at modifying the contract.
If you are purely a designer (and not contracted for the daily operation of the site), the answer is "no". GDPR Article 4 defines the "roles" responsible for complying with GDPR, and there are two: Controller and Processor. The Controller is the one who calls the shots. In particular: Decides what personal data to process. This is usually the owner of the web site. The Processor is the one that actually does the processing. This is usually some company providing some sort of data processing service (e.g. SaaS, PaaS, etc.). The relationship between the Processor and the Controller must be contractual. The contract is called a DPA (Data Protection Agreement or Data Processing Addendum). As a designer, you don't fit into any of these roles. If your contract with the client is silent on liability for GDPR compliance, then you have no liability. This goes for projects completed both before and after the May 25 deadline. Of course, if there are GDPR clauses in your contract, then you must fulfil them just as have to fulfil any other contractual obligation. But unlike the controller and the processor, there are no automatic legal liability for a designer or programmer.
No, it's not legal. The General Data Protection Regulations (GDPR) apply given that you are in the UK (regardless of where the Data Processor is based). The UK GDPR is slightly modified due to Brexit, but the same principles apply. The only plausible legal basis for this actions would be that you consent to it, and you're entitled to withdraw that consent at any time. Some may claim that Article 6.1(b) applies, i.e. that it's necessary to send marketing email in order to fulfil the contract, but GDPR is clear that bundling such consent into a contract for service simply to permit the data processor additional actions isn't allowed, as I'll demonstrate. UK GDPR requires that consent to use your personal information (in this case, your email address) for the stated purpose be freely given. Consent to use your information for direct marketing is not freely given if it's inseparable from the consent to use it for some other service, as per para 43: Consent is presumed not to be freely given if it does not allow separate consent to be given to different personal data processing operations despite it being appropriate in the individual case, or 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. And Article 7.4 backs this up with When assessing whether consent is freely given, utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is conditional on consent to the processing of personal data that is not necessary for the performance of that contract. The intent of Article 6.1(b) is that only the processing required for the service you have bought is allowed (e.g. if you supply your address for delivery of stuff you've bought, the data processor can use that address to send you the stuff, but is not allowed to add a contract term that allows them to send you unwanted stuff). Examples of emails that Article 6.1(b) would allow (in my assessment) include things such as notification of upcoming downtime, or a reminder that subscriptions are due, but not unsolicited advertisements for other products. There's a grey area that's open to interpretation, where adverts are piggybacked onto actual service messages.
The GDPR as such puts obligations on the Data Controller (DC), that is the person or firm or other entity who determines the purposes for which data is processed. The entity that hires the developer and operates the web site is responsible for compliance with the GDPR and other laws and regulations, such as the e-privacy directive and its implementing laws. However, it is highly likely that in commissioning a web site the DC would specify that it be designed to aid compliance with the GDPR and other relevant laws, and if the developer did not do that it might be a breach of contract. Indeed, even if GDPR-friendliness was not explicitly required by the contract between the developer and the DC, the implied warranties of merchantability and fitness for the purpose would probably apply. A designer who, knowing the site is to be hosted and operated within the EU, failed to design it to facilitate GDPR compliance might well be in violation of those warranties. But that would depend on the specifics of Italian law. But note that GDPR compliance is not a matter of web site design, but of the ongoing practices of the operation of the site. There are various ways to comply with the GDPR, no specific technology or design need be used. The DC must so operate the site as to comply. If the DC fails to do that, penalties could be imposed on the DC, not on the developer.
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).
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.