Can governments require administrators of groups on social media platforms to buy licenses? The Kenyan government now wants administrators of WhatsApp groups and other social media platforms to pay for licenses. Is this possible with the GDPR, Facebook privacy policy, etc., as the proposed law also requires such administrators to keep all the data of the users of the platform and submit the same to the authorities when required. Bill summary
If the Kenya legislature passes such a law, they can impose such a requirement on Kenyans who want to create such social media groups. Note that this is a license from the Kenyan government, not a copyright or trademark license. In effect, it is a tax on running a social media group, along with various regulations. I have no idea if this bill is at all likely to pass. If it does pass, it might be hard to enforce, as it would probably require cooperation from Facebook and other social media platforms, and the companies which run those platforms are not located in Kenya, and might not cooperate.
Elon Musk doesn't own Twitter He is part of a consortium of investors that own it. What he can and can't do with it will be constrained by any agreements that exist between those investors and, as CEO, a duty to all of the shareholders and to the company itself. However, that jus begs the question: can the &quot;owners&quot; of a company dissolve it? Yes. Or, more precisely, the directors acting for the shareholders can cease operating the company, collect all that it is owed, pay all that it owes and distribute wherever is left over to the shareholders. If there won't be anything left over, then the directors have a duty to point an administrator/liquidator to finalise the company. One of these two things is, ultimately, what happens to every company sooner or later.
According to Josh Aas, Internet Security Research Group (ISRG) Executive Director, (the umbrella 501(c)(3) for Let's Encrypt): "It is not against our terms to charge for services using our certificates, though we'd strongly prefer that HTTPS just be part of every offering as a default with no additional fees." My host sells SSL letsencrypt certificates - Help - Let's Encrypt Community Support That said, what your old company is doing is charging for their time and expertise (aided possibly by their own automated software they developed) to install SSL certificates for their own webhosting customers on their own servers. The company is not reselling the SSLs; they are selling the service of installing the certificates. It's not easy to install and automate the updating of 90-day SSLs from Let's Encrypt. So what your old company is doing is making it easy - for a fee - for their customers to use a somewhat difficult to use free service with the rest of their paid webhosting. The customers are not getting any information about what certificate they are buying. That could be. Check the TOS and information that each customer gets when they use the webhosting service with an SSL from Let's Encrypt. Many customers may only be concerned with if the SSL works, or not. And I'm sure the webhosting company does not divulge all aspects of their services to their customers, especially concerning security of their webservers and other business systems.
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.
First, when using profiling third party services (Analytics is "profiling" as defined by the GDPR), your main concern is not such a trivial thing as cookie compliance, but the security of processing I've analyzed Google's IP anonymization in some detail (as part of the DPIA I do for clients). My conclusion is that for most of the web-sites we manage, Google's IP anonymization is adequate to ensure security of processing as required by the DPIA process. However, on some sites that are likely to visited by users interested in what the GDPR calls "special categories of personal data" (Article 9), we either do not use Google Analytics, or we add additional layers of security in case the USA Government orders Google to disregard the stipulations in the DPA and hand over the data (yes, the US Government can legally do that - read the fine print in the Privacy Shield accord). As for Facebook Analytics, I think you've simply misunderstood their policy. Nowhere in that policy document does Facebook say that they "are not collecting Personal Identifiable Information". AFAIK, they collect tons of it, in all sorts of obnoxious and sneaky ways. What they actually say about PII in the context of Analytics is this: We do not share information that personally identifies you (personally identifiable information is information like name or email address that can by itself be used to contact you or identifies who you are) with advertising, measurement or analytics partners unless you give us permission. Let me remind you that one of their "analytics partners" was Cambridge Analytica, so if this promise not to share is true, it looks like a pretty new policy. OK, moving on to cookie compliance. To you (the controller), both Google and Facebook are processors. Given the history of the NSA and the methods it have used and AFAIK still use to get US-based companies to hand over the personal data about Europeans through orders issued by secret FISA courts, plus the fact that total nutcases currently are in charge in the USA, I am not going to rely on the privacy policy of any US-company for protection of personal data. So if I make use of Google Analytics (and I often do, they provide a great service), I always make sure that my users opt-in on that (hard cookie concent), even I make use of their IP anonymization feature (YMMV). As for Facebook, the fact that they promise not to share PII with third parties is irrelevant because they collect personal data. You will always need consent from your users to hand over their PII to Facebook in the first place. This is not optional. PS: If was a user, that consent would never been granted, no matter how great or valuable your site might be. If you have any sort of relationship with Facebook, I'll give you my personal data when you pry it from my cold, dead hands.
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.
This article is a useful introduction to restrictions on political advertising in the EU, where §3.4 (p 33) covers Italy. Silenzio elettorale is covered by art 9. of Norme per la disciplina della propaganda elettorale. The statutory situation is not entirely clear to me, but the main controlling fact relevant to the internet question is that AGCOM issues rules. An English legal analysis (from an Italian law firm) is here. Their undernourished analysis of the silence period is Finally, Italian legislation prohibits political propaganda on election day and on the day before. Although AGCOM is not competent for ascertaining infringements of said prohibition, it considers important to call everyone to turn the attention on these provisions. Indeed, they are important to guarantee effective protections of the constituents. As such, in the Authority’s opinion, the prohibition applies to all media. Clearly, the law applies to internet platforms. What is not clear is whether the prohibition as applied to web pages is against &quot;adding content&quot;, or does it require the elimination of previously-distributed content and scrubbing of links to such content. Perhaps the matter will be clarified in court one day.
The GDPR's right to erasure just applies in some specific situations. While messages you wrote on Slack are personal data, they are generally also part of a larger discussion with others. If your messages are removed, the discussion becomes incomplete, so that will violate the freedom of expression of those others. Art. 17(3) GDPR provides an exception for the right of erasure in such cases. So basically, whoever is the controller, you probably don't have the right to have your messages to be deleted. However, you would have the right to have your account pseudonymized like Slack replied in the Reddit post you linked to. See also my answer in "Does a user have the right to request their forum posts deleted?". Basically, it is correct that Slack can be just the processor. Even if the controller cannot get access to more than 10000 messages unless they pay. However, Slack is not allowed to do anything with those messages, except when the controller says so. In its Privacy Policy, Slack distinguishes between customer data and other data. It states to be the processor for the customer data, but controller for the other data. Because those are tied together, I am not sure this distinction can be made. If not, Slack and the customer will be joint controllers, but it requires probably a court case to decide on that. For example, the Court of Justice of the European Union has ruled (in the Fashion ID case) that putting a Facebook "like" button on your website, makes you a joint controller together with Facebook. And (in the Wirtschaftsakademie case) that also creating a Facebook "fan" page makes you a joint controller. But neither of those are very similar to the situation with Slack.