Is Apple scanning user content for child abuse a violation of GDPR? According to this article Apple is scanning all the photos users have on their devices to detect possible child abuse. The article explains that a NeuralHash of each image will be uploaded to Apple servers. It also claims that the NeuralHash is only a fingerprint of the image. But that is not true, a hashing made by a neural network is reversible, the reconstructed image will not be as good as the original, but it can be compared to a lossy compression with high loss. Is this compatible with the European GDPR? Can a corporation upload user content to their servers without asking the user permission? Related question: https://politics.stackexchange.com/questions/68507/can-countries-prevent-foreign-corporations-like-apple-from-acting-as-private-pol Update: Thanks to the pointer from @Fizz I found the reference to the exception for child abuse recently voted. It is a bit ambiguous because as a law it should be immediately applicable, but member states should anyway update their legislation to avoid conflict. And the news reporting the laws mention some constraints. https://ec.europa.eu/commission/presscorner/detail/en/IP_20_2463 https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52020PC0568
According to a Politico article from July this year EU Parliament lets companies look for child abuse on their platforms, with reservations The European Parliament on Tuesday approved a controversial law that would allow digital companies to detect and report child sexual abuse on their platforms for the next three years. Tuesday's vote was the final hurdle for the bill, and will allow companies to scan their platforms for explicit material without fear of violating Europe's strict privacy laws. The bill pitted the European Commission, who proposed the bill, and children's rights activists against the Parliament and Europe's privacy regulators, who fear the bill could undermine the EU's privacy rules. The results showed 537 MEPs voted in favor of the bill, with 133 against and 24 abstaining. Despite the result, [some] European lawmakers warned that the rules are &quot;legally flawed&quot; and could crumble in front of a court. [...] MEPs also said that the blanket scanning of private messages of European citizens to look for evidence of child grooming could clash with another set of privacy rules protecting personal data, the GDPR. To allay the Parliament's concerns, EU countries agreed to modify the Commission’s law to add additional safeguards, including bringing in Europe's network of privacy watchdogs to advise on what technologies should be used to do the scanning, and how they should be used. They also left out audio messages from the bill. The changes prompted Sippel, who was negotiating on behalf of the Parliament, to sign off on the bill. So YMMV, but insofar it looks pretty legal unless a court decides otherwise. It seems Apple went public with their plan after this EU law was passed, so they probably took it into account. For what's that worth, there's an analysis from someone at Cambridge (in the Compliant and Accountable Systems Group, Department of Computer Science and Technology) that: EU law would require that Apple obtain the consent of individual iPhone users for on-device scanning. This consent would need to be opt-in, rather than opt-out; there would need to be a real possibility for users to refuse consent; users’ access to iCloud could not be made conditional on giving consent to CSAM Detection; and users must be able to withdraw consent without suffering loss of iCloud service. This may place a welcome brake on the deployment of on- device CSAM detection in the EU. However, these barriers may be removed by future EU or Member State legislation – just as similar potential barriers for automated CSAM detection by certain messaging services have already been removed by EU legislation. So it seems that there would be a way for Apple to do this &quot;device scanning&quot; even in the EU with user (clickwrap) agreement... The paper enumerates the things than can be made implicit (bundled) in a GDPR agreement, and then goes on to argue that probably none of these apply to Apple's CSAM on device, and so they'll probably need a separate checkbox for CSAM... which the paper's author is pretty sure the users would not check. Importantly, because consent must be specific, consent to one purpose (such as processing to detect CSAM) can’t be presumed from consent to another purpose (such as processing for cloud backup). Nor can consent to processing to detect CSAM be ‘bundled’ with consent to cloud backup. GDPR strongly indicates that ‘bundling’ – the practice of making access to a service conditional on giving consent to processing that is not necessary for that service – is not permitted. [...] It is unlikely in the extreme that even minimally informed holders of CSAM would give consent to Apple’s CSAM Detection system. The paper more tenuously (IMHO) argues then that Apple needs do the same for their server-side scanning in the EU, i.e. get explicit consent, because it's somehow tied to the on-device scanning via the iCloud account. (The author also makes their personal disapproval of CSAM in all forms more explicit towards the end of the paper.) But still that someone who disapproves of CSAM entertains that it might be deployed via clickwrap user consent (albeit with a separate checkbox) is noteworthy. In this context I'll note (even though the paper doesn't), that there is a 2019 CJEU decision that pre-checking certain kinds of checkboxes (like for &quot;nonessential&quot; cookies) is not legal. I suspect CSAM will fall in this kind of category... so they won't be able to have the checkbox for it pre-checked, unless Apple does something more devious and make it so that image hashes become &quot;essential&quot; to something else that the user would more readily like to agree to... Also, looking at a current (August 1) Apple description of their system, it seems they only plan to run the image hashing on the device (and upload a threshold-encrypted version of the result, so that only multiple, cumulative &quot;hits&quot; on several images would be detectable/decryptable on the server), which would basically make their system (as currently envisaged) inoperable without the local hash step. I've also looked at Commission's 70-page impact assessment for their most recent proposal (the one discussed at the beginning of this answer), but it only discusses things like PhotoDNA and server-side hashing. So I guess they were unware that someone might plan to do [only] client-side hashing as part of a CSAM design. If this goes to an EU court, I guess an issue will be when and why iOS would create those (threshold-encrypted) vouchers that contain the images hashes, e.g. if they'd be considered an essential part/step of an otherwise approved purpose...
Privacy against publication of criminal convictions has been considered in the High Court in NT1 &amp; NT2 v Google LLC [2018] EWHC 799 (QB), if I may run the risk of posting a legal citation myself. But note that the claimaints there are anonymized, as often happens in criminal trials as well. In some cases, the court may give an injunction against disclosing names or details, and can hand down both a public and a private judgement, with the latter being a restricted document that does have the identifying details. So this question could only apply to mentions of criminal process where the accused is actually identified. (And I think just saying &quot;R v Smith&quot; is not enough - the posted or linked text would have to give some identifying detail about which Smith it is, the nature of the crime, etc.) I have no qualms at all about talking about NT1 and NT2. The claimants brought a case against Google for making available information about their long-spent convictions, including on GDPR grounds although it took place just before the implementation of GDPR in UK law. Dealing with that argument under the prior legislation, the judge found that of the various exemptions claimed by Google, the condition The information contained in the personal data has been made public as a result of steps deliberately taken by the data subject. (found in the Data Protection Act 1998, Schedule 3, paragraph 5, implementing the Data Protection Directive that preceded GDPR) applied, because of a longstanding principle for criminal conduct. The idea is that (paragraph 111): A person who deliberately conducts himself in a criminal fashion runs the risk of apprehension, prosecution, trial, conviction, and sentence. Publicity for what happens at a trial is the ordinary consequence of the open justice principle [...] The same must be true of the details of the offending, and other information disclosed in open court, including information about himself which a criminal reveals at a trial or in the course of an application. The core principles are the same as the carve-out from defamation law for the fair and accurate reporting of criminal proceedings (paras 44-49). That &quot;made public&quot; condition can now be found in a slightly different context in the Data Protection Act 2018, Schedule 1, Part 3, paragraph 32, which mirrors Article 9(2)(e) of the GDPR for the purpose of Article 10: This condition is met if the processing relates to personal data which is manifestly made public by the data subject. Since this is virtually the same condition of European provenance, in the same context of surrounding rules, I think the precedent is a good guide. For courts themselves, law reports, and journalism or scholarship, there are other specific grounds to rely on. Individual Stack Exchange posters are surely covered under the general exemption for posting on social media in a private capacity, GDPR 2(2)(c) as interpreted through its Recital 18. For the site itself, as in the case of NT1 and NT2, there could well be a legal claim made about the inclusion of criminal conviction information in a posted answer. (In general, such a post, being free text, could contain all sorts of defamatory statements or other objectionable content.) The court would have to look at the competing interests and the level of harm. NT1 was not successful but NT2 was. The example scenario, where we are talking about a very brief mention of a criminal case, cited because it illustrates a legal point rather than because there's anything relevant about the person mentioned, is quite far from the grounds complained of by NT2. For NT2, there was a newspaper article in which he was &quot;quite inappropriately, portrayed as one of a rogues' gallery of serious criminals&quot; (para 188), eight years after the end of his sentence, and it was this that he wanted removed from search results. In particular, the academic exemption (para 13) seems strong, in the same way that it would be for a publisher of legal academic content. The test of &quot;substantial public interest&quot; does not apply, because this exemption comes through paragraph 36 in the case of criminal convictions; it's enough to show a reasonable belief that publication would be in the public interest. Google was not able to rely on the &quot;journalism&quot; version of this exemption (again, under the prior law) because they are a totally generic search engine for all kinds of data and purposes (para 100 of the 2018 judgement). The public interest test, and the accompanying &quot;legitimate interest&quot; for the data controller, do not seem too difficult in this example.
The Facebook Pixel analytics solution does not seem to support access or erasure for data subjects. While there are some GDPR compliance features, these focus on collecting consent prior to collecting data. The relationship between the pixel user and Facebook is also murky. For certain kinds of data, Facebook acts as the data processor only, and the user has all the responsibility as the data controller. For other kinds of data, Facebook and the Pixel user are joint controllers, and therefore jointly responsible. This lack of features doesn't necessarily mean that Facebook Pixel is in violation of the GDPR, since the GDPR Right to Erasure only applies under certain circumstances. However, it is really difficult to argue that a website or app that integrates Facebook Pixel would be compliant. It is also rather dubious that Facebook could be compliant themselves, since their pixels will also collect data about persons who are not Facebook members. While these problems are most apparent with the Facebook Pixel since it's explicitly intended for tracking, this problem also applies to any other embeds provided by Facebook, such as like buttons. This was the subject of the Fashion ID case, in which the ECJ determined (in 2019) that the site operator is a joint controller with regards to data collection on the website by the Facebook embed. This effectively means that third party embeds can only be loaded after the website visitor has given consent for sharing data with Facebook. The tracking of non-users by Facebook was seen as especially problematic in Belgium, where Facebook had been banned from collecting such data already in 2015 (which was upheld in 2018). Since this was pre-GDPR, FB is currently litigating whether Belgium can continue enforcing their ban. I expect that Belgium will prevail with their ban. While this has no immediate consequences for Pixel users, this would make it more likely that Pixel users could be sued or fined successfully. From an advertiser perspective, Facebook does have valuable data that make the integration of Facebook Pixel an attractive proposition. However, other analytics solutions are much easier to bring into compliance. This is ultimately a business decision: will the better understanding of your ad spend on Facebook outweigh the risk and effort of integrating the Pixel?
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.
GDPR does not cease to apply because of the location of data storage. It applies based on the location of the data processor, data controller, and data subject. If you are in the EU, you are a data subject covered by GDPR. It does not matter where the data are stored. Note that you are asked to confirm that you're aware that US laws may be less protective, but you're not asked to acknowledge that anything about the arrangement causes the "laws of your country/region" not to apply. The company also does not seem to be claiming that they don't apply, although it seems that they want you to think so, and it's not clear whether they think so. You are correct that GDPR doesn't allow its protections to be waived. A data subject may always consent to certain processing, and some processing may be performed without consent, but it's not possible to waive the right to withhold consent for processing that does require it.
It is illegal in Scotland. There is currently no law specifically against it in the rest of the UK. If you find this is unbelievable, yes it is. There are attempts now to change the laws. PS. There are no photos taken "of the act". Taking the photo is the act. The pervs use a selfy stick or just get down on the floor to take photos, or take photos on stairs. PPS. News on Jan 16th 2019: "A new law will now be introduced in the next couple of months. It could mean that perpetrators might face up to two years in prison and are added to the sex offenders register."
The GDPR gives controllers a lot of latitude. They must decide on the correct course of action taking into account the possible risks to data subjects. Specifically, no notification of the authority is necessary if “the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons.” In your scenario 1, you suggest that there is no breach because there is no evidence that the data was improperly accessed. This analysis is faulty: the controller is aware that the data was not properly secured, and cannot rule out that the data was improperly accessed. I would argue this fits the description of a “breach of security leading to the accidental or unlawful … unauthorised disclosure of … personal data” (compare the definition of a data breach in Art 4(12)). Thus, a data breach has happened. The question whether the supervisory authority has to be notified of that breach is more debatable. The controller must assess the likelihood of risks to the data subjects. Here, they can perhaps argue that the risk of disclosure is low. However, the nature of the breached data would also be relevant. If in doubt, the controller should make the notification. The goal of the GDPR is not to punish unlucky companies that suffer a breach, but to protect personal data. Thus, fixing mistakes and cooperating with the supervisory authorities is likely the best approach for most companies. In your second scenario, the data is sensitive – its disclosure has a high risk for data subjects. However, the risk of someone intercepting this data is debatable. Does the risk of interception balance out the sensitivity of the data? That's the data controller's call, but I don't think so. A notification would seem appropriate here. As a technical remark, simply offering HTTPS is not sufficient to prevent MitM attacks – users must be forced to use encrypted connections. If a controller sees MitM as a risk, they are required by Art 24 to take appropriate technical measures. Here HSTS and HSTS preload would prevent the connections from being downgraded to HTTP. Instead of offering insecure connections, the site would become inaccessible. A complementary strategy is to not serve content over HTTP, but have the HTTP server only issue a permanent redirect to the HTTPS URL.
Per GDPR Art 79, you can sue data controllers if you consider your rights to have been violated. Where you have suffered damages due to GDPR infringements, you also have a right to compensation per Art 82. However, your rights may not have been violate as far as the GDPR is concerned. Under the GDPR any kind of personal data processing needs a clear purpose, and that purpose needs a legal basis. One possible legal basis is consent, but there also are others (such as legitimate interest). Just because you didn't consent doesn't mean that your rights have been violated. Where processing is based on legitimate interest, you can object to that processing of your personal data – but your rights must be balanced against that legitimate interest (Art 21). If your friends post a photo and you only appear in the background, your friends' legitimate interest to post that photo likely outweighs your rights. In practice, suing Facebook because of GDPR infringement is not a sensible way to achieve the outcomes that you likely want. First, this is expensive. Second, it is arguable whether Facebook or your friends should be the defendant. Third, removal of existing data won't prevent the processing of new data in the future. It would be more sensible to treat this as an interpersonal rather than a legal problem, and to talk with your friends so that they don't include you in their photos that they would like to share online. I've focussed on photos because their situation is fairly clear. Voice snippets might not count as personal data when you are not identifiable in them. Personal assistant apps should not be listening continuously, but only start recording when a wake-word is recognized.