Who&#39;s liable for GDPR compliance when embedding/hosting a self-contained 3rd-party website/service? I'm building a website for a client (a hotel) in Germany. In addition to a bunch of static pages, this website will also host a reservation system which is provided by a 3rd party software company in the form of a single page application. You just have to include their javascript snippet that builds up the whole system/website. Then it's basically a self-contained website, including a footer etc. They're using all kinds of technologies that a user would like to be informed about in a privacy policy (Google Analytics, Google Fonts, Social media plugins). The problem is: They're not providing a privacy policy on their own and the support argues that it's the responsibility of the web developer to author this privacy policy themselves. Question: Given that the 3rd party basically provides a whole website (including header and footer) aren't they obliged to deliver a privacy policy too? Question: Who would be liable in case the privacy policy is incomplete in respect to the technologies used on the 3rd party software?
Unless there's a data processing agreement between the hotel and the third party, both would likely be joint controllers. I.e. the hotel is fully co-responsible for any data processing that happens due to any embeds. If there were an Art 28 data processing agreement, the hotel would be fully responsible as well, but would have the primary responsibility for ensuring compliance – if the third party is a data processor, they don't have to publish their own privacy policy. This view is supported by the ECJ C-40/17 “Facebook Like-Button” case. A fashion retailer included the FB like button on the web page. The court found that the retailer was not a controller of subsequent processing by Facebook (here, Facebook is its own controller). However, the two parties are joint controllers for collecting and transmitting the personal data on the page.[1] While the ruling was made under the previous Data Protection Directive, it is entirely transferable to the GDPR. In your scenario the on-page processing is even more substantial. [1]: Which means that the website needs a legal basis for sharing data with the embed provider. For like buttons, the typical legal basis is consent, and loading the social plug-in is deferred until the visitor consents. This is more tricky for a reservation system because service may not be conditional on consent per Art 7(4). The definition of a data controller is the party “which, alone or jointly with others, determines the purposes and means of the processing of personal data”. The hotel is clearly a controller here because it decides purposes and means. Using the third party embed is a means for the purpose of making reservations. The hotel has a responsibility to ensure that the purposes and means are in compliance with the GDPR. It seems like the third party the hotels wants to use is not prepared to act in a GDPR-compliant manner, or to enable its customers to achieve GDPR compliance. Another reservation system should be used, or a the hotel should set a link to the reservation system's own web page, to make it clear that they are not responsible.
That's an old idea that has been tried several times before (such as the first, being Unvarnished: Website Lets You Review People (And Trash Them) | HuffPost, which no longer exists); and one of the latest incarnations is Peeple (mobile application - Wikipedia). There are lots of legal liabilities, including defamation and harassment/stalking, even with the Section 230 of the Communications Decency Act | Electronic Frontier Foundation which (mostly) protects the website owner from others' speech posted on the site (your mileage may vary due to jurisdiction). The only way such a site would survive is to do what Peeple and other sites have done: greatly limit the speech allowed, such as limiting to only positive reviews, giving the subject complete control over what does appear on their profile, only allowing "opt-in" profiles, verify identities, etc. You would have to implement full GDPR compliance; but various lawsuits will either shut you down before you get far enough to launch or soon after and force you to greatly limit the scope of the site. Most lawyers would advise you to find something else to do with your time and money.
Not going to hold up. Dutch Supreme Court confirmed 2012-09-21 in LJN BW6135 that arbitration is still covered by the the right to an independent judge, as established in Golder v UK, ECHR 1975-02-21, nr. 4451/70. Stack Exchange can't decide the rules themselves. (The Dutch case confirms that sector-wide arbitration is in fact legal, with regard to a standard arbitration clause commonly used in the Dutch building sector. The arbiter was found to be independent in that case precisely because they weren't picked by the builder involved.) The GDPR is only indirectly relevant, but the fact that it's mentioned does mean that there is an indisputable intent to provide services to EU consumers. (See section 23 of the GDPR, or its national equivalents). As such, you can't hide behind a US business address. If you intend to do business in the EU, it's under EU laws - all of them. You can't say that only the GDPR applies, and not other rules. I'm having a bit of a problem finding a source, but I'm fairly confident that consumers have the right to sue at their own, local court, overruling the default of suing in the court where the counterparty is located. Finally, I have the right under national law (Dutch: BW 6:236 start and sub-n) to strike the arbitration clause up to 30 days after the conflict arises, and demand a court decision. That's not 30 days after I accept the "Public Network Terms", that's 30 days after the arbitration is invoked. Dutch law explicitly allows arbitration abroad, and arbiters may apply foreign law, but as written the arbitration clause has no legal basis in the Netherlands, and any arbitration resolution would therefore not be considered valid. You may wonder if it matters to Stack Exchange that the arbitration decision would not hold in the EU. Well, consider a clause like Indemnification, which demands the user indemnifies Stack Exchange. That's a pretty empty demand if it's not enforceable.
You need a privacy notice for any website (if you're subject to GDPR). Having a PayPal button alone does not trigger such an requirement, since any website is already processing personal data such as IP addresses even if there's no third party content. But it's good that you think about issues for including third party content. As rulings such as the Fashion ID case and the more recent Google Fonts judgement have clarified, you are responsible having a suitable legal basis when you cause visitor's personal data to be disclosed to third parties. Even just embedding/loading a button or logo can cause personal data such as IP addresses to be disclosed to the recipients. You might have a legal basis if earlier, the user already opted in to payment with PayPal (could be consent per Art 6(1)(a) GDPR, or necessity for performing the contract per Art 6(1)(b)). Loading the embedded content just because the user might want to use it is probably not compliant though. For example, the common PayPal donation button is problematic. Thus, instead of linking a PayPal SDK, you might want to host the code + assets for the PayPal payment functionality on your own servers, or only load the PayPal content after the user unambiguously indicated that they want to use this content. I've discussed the PayPal donate button previously, as well as background on the Fashion ID case and click-to-consent wrappers for embedded content. What the Fashion ID case made very clear though is that you're only responsible for compliance for those data processing activity where you can actually influence the “purposes and means” of processing. You have no control over what PayPal does with the data on their servers, so they are solely responsible for that. And if the PayPal button navigates to a PayPal website, you're not responsible for what cookies PayPal sets on its own website. It is thus correct that the PayPal popup has its own cookie banner – you are not responsible for the contents of the popup. You also don't need to collect consent for cookies and similar technologies that are strictly necessary to provide a service that was explicitly requested by the user. For example, session cookies, XSRF protection cookies, and cookies containing a shopping cart are often such strictly necessary cookies. You must still be transparent about the use of such cookies, but you probably don't need a banner to announce this. So I think that you can probably go without a cookie banner, though you should probably get consent before loading PayPal content into your page, and you will likely want to be transparent about cookies as part of your privacy notice.
Your analysis so far seems correct. You must comply with all applicable laws. The GDPR's Art 6(1)(c) legal basis clarifies that having to provide personal data is no excuse: that legal obligation is all the legal basis you need for sharing the personal data in accordance with your obligations. However, that legal basis doesn't generally excuse you from your other data controller obligations. For example, you should still inform the data subjects about the processing as per Art 13(3).
Makerbot's explanation of the Terms is accurate This is comparable with most other services that host and display User-created content - even with SaaS providers, as per Interpretation of content ownership/usage in service provider agreement. They are correct that they are asking for the lots of broad rights, but it's all qualified with (my emphasis): 3.2 License. You hereby grant, and you represent and warrant that you have the right to grant, to the Company and its affiliates and partners, an irrevocable, nonexclusive, royalty-free and fully paid, worldwide license to reproduce, distribute, publicly display and perform, prepare derivative works of, incorporate into other works, and otherwise use your User Content, and to grant sublicenses of the foregoing, solely for the purposes of including your User Content in the Site and Services. That is, if they use your User Content for a purpose other than including it in the Site and Services (and you have not agreed to this use), you may be entitled to relief in the form of an injunction or damages.
IANAL. (1) GDPR is certainly relevant. (2) This is certainly "personal data" under the definition in GDPR article 4. (3) Maintaining this data is probably lawful under article 6 sections 1(a) (consent) - provided that the Terms and Conditions of the site make clear that the user by signing up is consenting to this information being held (3) There is certainly an obligation under article 14 to disclose that the information exists, and to say how it used. (4) Article 15 says that data subjects are entitled to see the information and know what recipients or categories of recipient have access to the information (I don't know whether it's enough to just say "moderators", or whether the moderators need to be identified). (5) I can't see any reasons why the obligations under articles 16, 17, and 18 regarding rectification, erasure, and restriction of processing aren't relevant. This is exactly the kind of situation that GDPR is designed to address. If you're restricting the service available to particular users based on a record of their behaviour or on judgements made by moderators, then they absolutely have a right to know, and a right of redress.
It depends. Can the data controller or another person, with &quot;means reasonably likely to be used,&quot; (see clause 26 of the preamble of the GDPR) use that data alone or in combination with other data to identify a natural person? If yes, it is personal data within the meaning of the GDPR. If no, it is not personal data within the meaning of the GDPR. Anonymous data is not subject to the GDPR. &quot;The principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable. This Regulation does not therefore concern the processing of such anonymous information, including for statistical or research purposes.&quot; Assigning an unique alphanumeric code to a thing does not necessarily make the code and/or the thing &quot;personal data&quot;. But if you have a set of data that is or can be linked by the unique alphanumeric code (e.g. as a primary key in a set of tables) and you can use it to identify a person, then it is personal data. Either way, to be GDPR-compliant / to mitigate risk you should make some kind of record to reflect that process of thinking and what you decided. And if the answer is Yes, it is personal data, then you should record your &quot;lawful basis&quot; for processing the data and how you decided that.