Germany: Does a github.io hosted site require imprint / data privacy statement according to the GDPR? github offers free publicly accessible data storage. Many people use that to present their personal profile where they e.g. advertise for freelancing services. An example url could be http://username.github.io. If I have such a personal page where I advertise services, do I need to make sure I have an Impressum and a data privacy statement to comply with the new General Data Protection Regulation DSGVO? It would be hosted by github and linked to and accessible only via github, not e.g. a domain of mine. Though it would still be possible to e.g. include a contact form that sends visitor data to my email address.
a few quick notes that come to mind. As the commenters point out: DSGVO is indeed the German equivalent name to the GDPR (English term) "Imprint" isn't a privacy related topic that much, as such it's not really changed by the upcoming GDPR The GDPR changes many things, but the requirement for up front information isn't one of them - so it would've already been a rule to follow Sometimes the question who is responsible for privacy information might not be that easy to decide when you're on platforms. I take this situation as being pretty clear though. You are basically given a blank slate, you can do with that page whatever you want, and the visitor has no clue whatsoever that it might be hosted by Github. In addition to this, Github would be classified as a data processor (providing the tool) and you as the data controller who is in charge of practically everything except for the provision of the page. I hope this helps. Btw. it's not that hard anymore to write a privacy policy these days.
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.
There is no general prohibition against taking down material, even non-infringing material, which is posted by some person, but there is a risk to the service provider. Abstracting away from the specifics of github, a Provider has some agreement with the User whereby User rightfully makes Stuff available on Provider's site. Arbitrarily removing Stuff (in violation of the usage agreement) may cause damage to User, who may sue Provider, and Provider will avoid that if possible. DMCA protects Provider from copyright infringement suits by Victim, providing the proper DMCA procedure is followed, and it allows Provider to remove Stuff without fear of getting sued by User (17 USC 512(g)). This protection is not available if the takedown notice is not proper. (As a case in point, the entire series of Harry Potter books is still out there freely on the internet, because only the rights holder can demand a takedown, and the rights holder seems to not be concerned).
The GDPR actually does require you to follow DNT in Article 21: In the context of the use of information society services, and notwithstanding Directive 2002/58/EC, the data subject may exercise his or her right to object by automated means using technical specifications. I think this is quite explicit.
It seems clear that this is personal information under the GDPR. If you are subject to the GDPR, you need to have a "lawful basis" to store or process such information. (You are subject to the GDPR if you are locates in the EU, or if your users are. My understanding is that it is location at the time the app is accessed that matters, not a user's citizenship. I am not totally sure about that, however. Unless your app is limited to non-EU access, it it probably safest to comply with the GDPR) The degree of precision of your location data will not matter -- a specific city is quite enough to make it personal data if it can be tied to a specific person. There are various lawful bases that may be relied on for processing and storage, but explicit consent is probably the one with the widest applicability. To use consent as the lawful basis, you must present an OPT-IN decision to the user, and record the results. If the user does nothing, the result must record lack of consent. You may not use a pre-checked consent box or another mechanism that has the effect of an opt-out choice. You should be clear about what information will be stored, and how it will or might be used. You will also need to consider how your app will function for those who do not consent, and how to handle requests to withdraw consent. So if an app obtains user consent to store location data in a manner that complies with the GDPR, it may store user location data. The consent should make the possible uses of the data clear. If the data is to be shared, the consent should make the possible extent of sharing clear. Some previous questions and answers here on law.se dealing with GDPR consent that seem possibly relevant: User consent required under GDPR What provisions should I make regarding GDPR consent when users do not sign themselves up? GDPR - Withdrawn user consent Opt Out Consent under GDPR
Most likely yes if you are subject to UK or EU laws: The EU ePrivacy directive and implementing laws such as PECR in the UK require that you obtain consent before accessing information on a user's device, unless that access is strictly necessary to perform a service requested by the user. Cookies and similar technologies such as LocalStorage are stored on the user's device. Analytics are not strictly necessary to display a website. Thus, you need to obtain valid consent before setting any analytics cookies. GDPR and ePrivacy/PECR have some interactions: Even though the cookies might technically be set by GoSquared, you as the website operator are responsible for compliance. You are the data controller, the third party analytics are usually a data processor who only process data on your behalf. You must ensure that the data processor is compliant. Even if they were a joint controller you'd be responsible for what happens on the website (relevant precedent is the Fashion ID case). While ePrivacy originally had a fairly weak concept of consent (e.g. “by continuing to use this site, you consent …”). However, the GDPR updated the definition of consent, so that valid consent must be freely given, informed, actively given, and specific. If you set cookies for different purposes in addition to analytics, users should be able to give or withhold consent for analytics independently from other purposes. Since consent must be actively given, consent is never the default, e.g. pre-ticked checkboxes are not compliant (relevant precedent is the Planet49 case). Like Google, GoSquared stores data in the US. You are causing personal data to be transferred into the US, which is an international transfer. Before it was invalidated earlier in 2020, such transfers were easy to do under the Privacy Shield adequacy decision. Now, such transfers are only legal if you sign SCCs with your data processor, and your risk assessment indicates that your user's data is sufficiently safe there, despite your processors potentially being legally unable to comply with the SCCs. Fortunately for you the UK's ICO has taken a more industry-friendly stance on this matter than other countrie's data protection agencies. Why do so many websites use Google Analytics (GA) without requesting proper consent? A variety of potential reasons: They are actually non-compliant. After all, GA is not GDPR-compliant in default settings, and Google doesn't do a good job of providing essential information. Many data protection agencies have indicated that cookie consent enforcement is not their focus. GA can be used without using cookies/LocalStorage/…, and thus without requiring consent under ePrivacy or PECR. The websites might not be subject to EU or UK laws such as ePrivacy.
If the website containing the GDPR-wall processes any personal data of users who hit the GDPR-wall, the GDPR applies to that website. This can be as simple as writing a logfile of all visits to the website. In this case it will be illegal if the website owner does not comply with the GDPR. However a supervisory authority would probably not spent any time on such a minor violation. As long as the the website with the GDPR-wall does not process any personal data, the GDPR does not apply, so nothing in the GDPR can forbid the GDPR-wall. Some related remarks: The GDPR does not require a "privacy policy" on the website if the website does not process any personal data. If personal data is processed based on consent, that consent must be freely given. Also it may not be disruptive. So a cookie wall asking for consent would be illegal. But the GDPR does not care about any other disruptive popups, as long as they are not related to asking for consent. Using GeoIP is a perfect way to implement such a GDPR-Wall, because it would block everyone from within the EU, but nobody else. So it blocks exactly those for who the GDPR would apply. In such a case it would not be reasonable to expect anything more from a website owner. A user which uses a proxy, can not expect to be protected by the GDPR, because it bypasses a restriction set by the owner of the website. A webserver does use the IP-address of all incoming requests, to send the reply back. That could be considered a processing of personal data, but everybody seems to agree it is not. I am not sure why. But I do agree that it would be very impractical if that is considered processing of personal data. I added an example from the Washington Post So you have to pay $9/month for a GDPR compliant subscription. Because the price you have to pay is not unacceptable high, I think it would be valid to offer the premium version this way. This does not force you to choose one of the other subscriptions. In december 2018, the Austrian DPA (DSB) has confirmed that a similar offer is lawful. On derstandard.at you get a choice between free access with tracking and advertising, or pay 6 Euro/Month for tracking free access. Because 6 Euro/Month is cheaper than subscribing to the printed edition, the DSB accepted that as a valid choice. More information can be found on noyb.eu or, (with more details but in German), on wbs-law.de.
I'll quote from my answer on a similar question from Programmers.SE: ...[T]he Github TOS have this to say about material hosted on their site: By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories. Hosting on Github means that the author grants others the right to &quot;view&quot; and to &quot;fork&quot; the repository. Here, &quot;fork&quot; probably just means &quot;use Github's fork feature&quot;, which creates a repository clone, hosted on Github. GitHub's use of &quot;fork&quot; here probably refers to the software feature of the website github.com called &quot;Fork,&quot; which allows users to create a verbatim copy of a repository on github.com. The TOS do not require the author to grant any other specific rights, like the right to prepare derivative works or to redistribute copies of the work, so &quot;fork&quot; here probably is not used the general sense of &quot;produce a derivative work.&quot; Thus, the code's presence on GitHub does not grant you rights to reuse the work in ways protected by copyright (commercial or otherwise) without a explicit license from the author.