art. 4 n. 1 Dato personale – Lorenzo Albertini

Dati sanitari ceduti a Meta da centri medico-sanitari senza consenso del titolare: il caso dei tracking pixel

Interessante caso, segnalato da Eric Goldman nel suo blog, deciso (provvisoriamente) da US D.C. East. D. of California, 9 giugno 2025, No. 1:23-cv-01106-DC-CKD, Jane Doe e altri c. TENET HEALTHCARE CORPORATION, et altri.

Queste strutture raccoglievano molti dati sanitari dei clienti prodotti dalla loro interazione sui loro server e li cedevano a Meta: -direttamente dal pc del cliente, nel caso dei citt. Pixex; – a partire dal server delle strutture sanitaria nel caso di un’altra applicazione chiamata Conversions Application Programming Interface, “CAPI”.

Delle molte azioni svolte, alcune sono state mandate avanti, mentre altre sono state bloccate.

Si tratta però di normative nazionali poco interessanti nel dettaglio per l’operatore italiano (tranne quelle sulla data protection in senso stretto).

Qui interessa solo ricordare come funziona il tracciamento tramite Pixex , come riportato in sentenza:

<< Defendants deploy “various digital marketing and automatic software tools” on their Web Properties that disclose information to Meta, Google, and other third parties for “advertising purposes.” (Id. at ¶ 8–9.) Specifically, Defendants have installed source code known as “tracking pixels” on their Web Properties to share user information with third parties. (Id. at ¶¶ 34–35, 55–56, 79, 184, 233.) Meta Pixel (“Pixel”) is among the tracking pixels Defendants have installed on their Web Properties. (Id. at ¶¶ 42–43, 71, 111, 184, 233.) Pixel was developed by Meta as “a new way to report and optimize for conversions, build audiences and get rich insights about how people use [] website[s].” (Id. at ¶ 208.) Pixel enables Defendants to “measure the effectiveness of their advertising by understanding the actions people take on their websites.” (Id.)

Pixel is a “snippet of code embedded on a third-party website that tracks users’ activities as users navigate through a website.” (Id. at ¶ 192.) When a user visits a webpage containing Pixel, the code tracks and log each page the user visits, what buttons they click, as well as specific information that users input into a website. (Id.) Pixel functions by monitoring for an “event” that triggers the code on Defendants’ Web Properties, including their websites and patient portals. (Id. at ¶¶ 98, 130.) On Defendants’ Web Properties, Pixel is triggered each time a user interacts with new webpages, enters search terms in the search bar, engages with the “Find A Doctor” function, fills out forms, completes assessments, logs into the patient portal, or uses the patient portal. (Id. at ¶¶ 110, 130, 236, 242, 245–248, 273.) When an event occurs, Pixel “send[s] the information it collects to [Meta] through scripts running in a user’s internet browser, similar to how a ‘bug’ or wiretap can capture audio information.” (Id. at ¶¶ 213, 233.) In other words, Pixel redirects the content of the users communications to Meta simultaneously in “real time” while the exchange of information between the user and Defendants’ Web Properties is still occurring. (Id. at ¶¶ 232, 239.)

Pixel transmits data to Meta as a “full-string, detailed URL” consisting of information regarding a user’s browsing history, the name of the web page visited, and the search terms that the user used to find the web page. (Id. at ¶¶ 202, 255.) The information Meta receives via Pixel may include “the kinds of treatments that patients research on the hospital’s website, . . . patients’ past and future medical conditions, their past and future medical treatment, [] when and where they are receiving treatment for those conditions,” “the patient’s home address, their name, their search location, as well as their doctor’s specialty, name, and gender.” (Id. at ¶ 83.)

Pixel also sends Meta a user’s PII, including their internet protocol (IP) address, name, email, phone number, cookies, and browsing fingerprint (i.e., information that can be used to identify the specific device). (Id. at ¶¶ 204, 211, 215.) If the user has a Facebook account, Meta also receives the user’s Facebook ID (“FID”). (Id. at ¶¶ 215–217.) “A user’s FID is linked to their Facebook profile, which generally contains a wide range of demographic and other information about the user, including pictures, personal interests, work history, relationship status, and other details.” (Id. at ¶¶ 117, 120.) A user’s PII is sent to Meta in a “data packet” alongside information on the user’s interactions with Defendants’ Web Properties, allowing Meta to “link” a user’s activity on Defendants’ Web Properties to their Facebook profile. (Id. at ¶¶ 82–84, 239, 263.)

In addition to Pixel, Defendants installed and implemented Meta’s Conversions Application Programming Interface (“CAPI”) on their Web Properties’ servers. (Id. at ¶ 58.)

Unlike Pixel, which causes a user’s browser to transmit information directly to Meta, “CAPI tracks the user’s website interaction . . . records and stores that information on the website owner’s servers and then transmits the data to [Meta] from the website owner’s servers.” (Id. at ¶ 59.) CAPI is located on “the website owner’s servers (rather than a bug placed on the website users’ browsers),” meaning website owners can “circumvent any ad blockers or similar technologies.” (Id. at ¶ 61.) CAPI captures information submitted by users to Defendants’ Web Properties, including “the type of medical treatment sought, the individual’s particular health condition and the fact that the individual attempted to or did book a medical appointment.” (Id. at ¶ 64.)

Finally, Defendant Tenet “discloses the same kind of patient data” that it provides to Meta to other third parties involved in internet marketing, including Google, via tracking software installed on its websites. (Id. at ¶ 258.) Namely, Defendants deploy Google tracking tools, such as Google Analytics, Google DoubleClick, and Google AdWords, on “nearly every page of their websites, resulting in the disclosure of communications exchanged with patients to be transmitted

to Google.” (Id. at ¶¶ 259, 262.) Transmissions of information to Google “occur simultaneously with patients’ communications” with Defendants’ Web Properties and include data on “specific medical providers, treatments, conditions, appointments, payments, and registrations and logins to Defendants’ patient portal.” (Id. at ¶ 262.) Google also receives a user’s PII, including their IP address, cookies, geolocation, and other identifiers. (Id. at ¶ 259.)>>

Ricordo solo che la violazione del California Privacy Act è stata ritenuta plausibile, per cui l’azione relativa è stata fatta proseguire (v. sub C), C alifornia Invasion of Privacy Act (Count 1), p. 19 ss

Sulla identificabilità della persona, ai fini della data protection, in caso di informazioni inviate a Facebook dalla piattaforma di videostreaming

L’appello del 2 circuito , 01.05.2025, Docket No. 23‐7597‐cv, Solomon cv. Flipps Media – Fite TV.

Si tratta di info inviate dal gestore di video streaming Fite a Facebook circa l’uso della propria piattaforma da parte degli utenti, info raccolte tramite la applicazione Pixel, inclusiva del servizio PageView, fornita dallo stesso Facebook.

Le info inviate son quelle presenti nella schermata che segue ,

Sia il giudice di primo grado che quello di appello ritengono che non ci sia identificabilità della persona, alla luce del Video Privacy Protection Act of 1988, 18 U.S.C. § 2710 (da noi v. art. 4 n. 1 del reg. UE 679/2016).

<<The information transmitted by FITE to Facebook via the Pixelʹs
PageView is set forth in the ʺexemplar screenshotʺ reproduced in the Complaint.
See page 9 supra; Joint Appʹx at 20. The exemplar depicts some twenty‐nine lines
of computer code, and the video title is indeed contained in Box A following the
GET request. The words of the title, however, are interspersed with many
characters, numbers, and letters. It is implausible that an ordinary person would
look at the phrase ʺtitle%22%3A%22‐%E2%96%B7%20The%20Roast%20of%‐
20Ric%20Flairʺ ‐‐ particularly if the highlighting in Box A is removed ‐‐ and
understand it to be a video title.14 It is also implausible that an ordinary person
would understand, ʺwith little or no extra effort,ʺ the highlighted portion to be a
video title as opposed to any of the other combinations of words within the code,
such as, for example, ʺ%9C%93%20In%20the%20last%20weekend%20of%20‐
July%2C.ʺ Id.; Joint Appʹx at 20.
Nor does the Complaint plausibly allege that an ordinary person
could identify Solomon through her FID. Because the redacted sequence of
numbers in the second line of Box B is not labeled, the FID would be just one
phrase embedded in many other lines of code. And if the numbers in the
exemplar were not redacted, what an individual would see is, for example, a
phrase such as ʺc_user=123456ʺ or ʺc_user=00000000.ʺ Although a section of the
code in Box A does state ʺ[h]ost: www.facebook.com,ʺ it is not plausible that an
ordinary person, without the annotation of Box B, would see the ʺc_userʺ phrase
on FITEʹs servers and conclude that the phrase was a personʹs FID.
Notably, the Complaint lacks any details about how an ordinary
person might access the information on the Pixelʹs PageView. But even
assuming, arguendo, that an ordinary person could somehow gain access to the
Pixelʹs PageView, the Complaint is also devoid of any details about how an
ordinary person would use an FID to identify Solomon. The Complaint merely
states that entering ʺfacebook.com/[Solomonʹs FID]ʺ into any web browser would
result in Solomonʹs personal Facebook profile, and that ʺ[t]his basic method of
accessing a personʹs Facebook profile is generally and widely known among the
public.ʺ Joint Appʹx at 21. But see In re Nickelodeon, 827 F.3d at 283 (ʺTo an
average person, an IP address or a digital code in a cookie file would likely be of
little help in trying to identify an actual person.ʺ). Accordingly, we are not
persuaded that an FID is ʺvastly different,ʺ Appellant Br. at 29, from the unique
device identifiers in Nickelodeon, 827 F.3d at 262, or the Roku device serial
numbers in Eichenberger, 876 F.3d at 979 >>

La decisione sarebbe stata uguale anche in base alla norma europea.

(notizia e link alla sentenza dal blog di Eric Goldman)

La targa automobilistica è dato personale e la sua diffusione on line costituisce dunque trattamento

Cass. Sez. I, Ord. 21/02/2024, n. 4648, rel. Tricomi, sulla pubblicaizone del sito del Comune della targa di un veicolo estraneo alla infrazione contestata:

<<3.3.- Va ricordato che questa Corte ha già affermato che la targa automobilistica è un dato che consente la identificazione diretta del proprietario e che ciò che assume rilievo decisivo, in materia di protezione dei dati personali è dunque, il collegamento funzionale, ai fini identificativi, tra i dati personali e la persona fisica, in presenza di condotte astrattamente riconducibili nell’alveo del trattamento (Cass. n. 19270/2021); sia pure con la precisazione, in fattispecie concernente l’impiego di parcometri evoluti atti a registrare targa e localizzazione del veicolo in sosta, che “Nonostante dal dato personale della targa, consultando il Pubblico Registro Automobilistico, è possibile risalire solo al nominativo dell’intestatario del veicolo che, in astratto, potrebbe anche non esserne l’effettivo utilizzatore o, addirittura, essere una persona giuridica, non oggetto di tutela da parte del GDPR, o un soggetto diverso dall’effettivo proprietario, il numero di targa dei veicoli costituisce in una percentuale statisticamente preponderante un dato personale idoneo a risalire alla persona dell’utilizzatore del parcometro, consentendone, dunque, la profilazione, onde il trattamento non può dirsi irrilevante sotto questo profilo (fattispecie in cui era stato contestato ad una società di aver trattato dati personali degli utenti, raccolti attraverso una certa tipologia di parcometri, senza essere stata previamente nominata quale sub-responsabile per il trattamento e, dunque, in assenza dei requisiti di interesse pubblico che insistono in capo al titolare effettivo del trattamento stesso).” (Cass. n.35256/2023).

3.4.- La decisione, che non si è conformata a questi principi risulta, pertanto, errata e la decisione va cassata.

3.5.- Nel caso di specie, infatti la visualizzazione della targa dell’autoveicolo in questione, estraneo alla violazione contestata, si colloca nell’ambito di un più ampio rilievo fotografico che, unitamente agli altri elementi confluiti nello stesso (luogo ed ora della ripresa e rappresentazione del contesto globale in cui era evidenziata la violazione riscontrata a carico del veicolo contravvenzionato), appare idoneo a consentire una profilazione, senza che sia stato nemmeno accertato che ciò poteva essere funzionale o necessario alla compiuta esecuzione del controllo amministrativo.

3.6.- Ne consegue che, in sede di rinvio il Tribunale, a fronte del trattamento della targa dell’autoveicolo di proprietà di un terzo, connesso all’accertamento dell’infrazione commessa dal conducente di altro veicolo, dovrà verificare se tale trattamento abbia esorbitato i principi e le modalità fissate negli artt. 3, 11, 18 e 19, del D.Lgs. n. 196/2003, dovendo assumere rilievo la circostanza che il numero di targa, che poteva condurre all’identificazione del terzo proprietario, venne comunicato all’esterno mediante l’esposizione in una fotografia documentante l’infrazione altrui con indicazioni di tempo e di luogo, idonee a consentire una profilatura. In relazione a tale complessivo trattamento, si dovrà accertare se ricorreva la necessità del trattamento per il perseguimento delle finalità proprie dell’atto adottato, se ricorreva un trattamento di dati pertinenti e non eccedenti rispetto alle finalità perseguite (art. 11, comma 1,lett. d) del Codice) e se poteva avere ingresso la fattispecie derogatoria ex art.24, comma 1, lett. a), c) del D.Lgs. n. 196/2003; se la fattispecie, ricadeva o meno nell’ambito di applicazione dell’art.25, comma 2, che stabilisce “2. È fatta salva la comunicazione o diffusione di dati richieste, in conformità alla legge, da forze di polizia, dall’autorità giudiziaria, da organismi di informazione e sicurezza o da altri soggetti pubblici ai sensi dell’articolo 58, comma 2, per finalità di difesa o di sicurezza dello Stato o di prevenzione, accertamento o repressione di reati.” >>

Insegnamento esatto, anche se scontato.

Più interessante è invece il passaggio che tratta il come vada (ex ante) considerata la possibilità che il conducente non sia il proprietario (unico soggetto desumibile dal PRA) o che questi sia un ente anzichè persona fisica

Offerte pubblicitarie c.d. “Real Time Bidding” in internet e data protection: il relativo consenso costituisce “dato personale”?

Dice di si la Corte di Giustizia EU qualora l’interessato sia individuabile : il che avviene se il suo consenso sia abbinato al relativo indirizzo IP.

Questa in sintesi la risposta resa da Corte di Giustizia 7 marzo 2024, C-604/22, IAB Europe c. Gegevensbeschermingsautoriteit., con l’intervento di altri.

La CG esamina la fattispecie delle aste automatiche di presenza pubblicitaria negli spazi creati dai colossi del web (Google e social vari) , che viene cocnessa a chi offre di più. Meccanismo che però avviene “dietro le quinte”, cioè in modo non tarsparente all’utente, e che per questo è di fatto sconosciuto al grande pubblico.

La CG ne offre una spiegazione, imprescindibile per comprendere la decisione (spt. §§ 20-26), se non si è già nel settore.

Qui mi limito a ricordare il concetto di TC String (Transparency and Consent String), elemento digitale che comprende i consensi espressi.

Ed ora il passo più pertinente:

<< 43 Orbene, anche se una TC String, di per sé, non contenesse elementi che consentano l’identificazione diretta dell’interessato, rimarrebbe comunque il fatto, in primo luogo, che essa contiene le preferenze individuali di un utente specifico per quanto riguarda il suo consenso al trattamento dei dati personali che lo riguardano, nella misura in cui tale informazione «[riguarda] una persona fisica», ai sensi dell’articolo 4, punto 1, del RGPD.

44 In secondo luogo, è altresì pacifico che, quando le informazioni contenute in una TC String sono associate a un identificativo, come in particolare l’indirizzo IP del dispositivo di tale utente, esse possono consentire di creare un profilo di detto utente e di identificare effettivamente la persona specificamente interessata da tali informazioni.

45 Poiché il fatto di associare una stringa composta da una combinazione di lettere e di caratteri, come la TC String, a dati supplementari, in particolare all’indirizzo IP del dispositivo di un utente o ad altri identificatori, consente di individuare tale utente, si deve ritenere che la TC String contenga informazioni riguardanti un utente identificabile e costituisca quindi un dato personale, ai sensi dell’articolo 4, punto 1, del RGPD, il che viene corroborato dal considerando 30 del RGPD, che fa espresso riferimento ad una fattispecie del genere>>.

Nella questione pregudiziale successiva la CG esamina il quesito della titolarità del trattamento e cioè se il primo creatore della stringa cit. rimanga titolare anche dopo averla ceduta a terzi per gli impieghi successivi. E la risposta è negativa.

La targa dei veicoli costituisce “dato personale”

Cass. Sez. I, Ord. 18/12/2023, n. 35.256 rel. Campese:

<<2.2. E’ indubbio che l’ informazione di cui si discute – la targa di un autoveicolo, in quanto riferita a soggetto identificato o identificabile – deve considerarsi dato personale>>.

<<2.5. Il Collegio, inoltre, è conscio del fatto che dal dato personale della targa, consultando il Pubblico Registro Automobilistico (PRA), è possibile risalire solo al nominativo dell’ intestatario del veicolo che, in astratto, potrebbe anche non esserne l’effettivo utilizzatore o, addirittura, essere una persona giuridica – non oggetto di tutela da parte del GDPR – o un soggetto diverso dall’effettivo proprietario. 2.5.1. Tuttavia l’affermazione del tribunale secondo cui Il numero di targa dei veicoli costituisce in una percentuale statisticamente preponderante un dato personale idoneo a risalire alla persona dell’utilizzatore del parcometro, consentendone, dunque, la profilazione, onde il trattamento non può dirsi irrilevante sotto questo profilo, in quanto fondata su valutazione evidentemente fattuale, non è ulteriormente sindacabile in questa sede (se non per vizio motivazionale nei ristretti limiti in cui il già richiamato art. 360 c.p.c., comma 1, n. 5 lo consente. Nessuna specifica censura in tal senso, tuttavia, è stata prospettata dalla odierna ricorrente), sicchè la doglianza finisce con il sostanziarsi in una inammissibile richiesta di rivisitazione di detta valutazione, così mostrando, ancora una volta, di non considerare che il giudizio di legittimità non può essere surrettiziamente trasformato in un nuovo, non consentito, ulteriore grado di merito, nel quale ridiscutere gli esiti istruttori espressi nella decisione impugnata, non condivisi e, per ciò solo, censurati al fine di ottenerne la sostituzione con altri più consoni alle proprie aspettative (cfr. le pronunce di legittimità già rinvenibili alla fine del p. 1.3.4. di questa motivazione)>>

Non mi pare esatto. E’ vero che il concetto è delineato in termini ampi dall’art. 4 n.1 GDPR. E’ pure vero tuttavia che la ratio della normativa protettiva sta nel permettere all’interessato la scelta di quanto e come divulgare ciò che non è ancora divulgato: e quindi viene meno quando il dato è appunto già in pubblico dominio, come per la presenza del nome nel PRA

Le coordinate bancarie IBAN costituiscono “dato persponale”

Secondo Cass. 19.02.2021 n. 4475, rel. Campese, le coordinate IBAN costituiscono <dato personale> ai sensi della disciplina privacy.
Nel caso specifico, un’assicurazione, risarcito il danno da infiltrazione ad un condomino per conto di altri condomino e proprio assicurato, aveva poi girato <<una stampa del sistema informativo interno della medesima compagnia nonchè un atto di liquidazione ove erano riportate, tra l’altro, le loro coordinate IBAN;>> a quest’ultimo (dal cui immobile erano provenute le infiltrazioni).

Il condomino/assicurato poi produceva tale documento in assemblea condominiale.

Per la S.C. :

a) l’IBAN è dato personale (§ 2.4, sostanzialmente immotivato);

b) non rende lecito il trattamento (cioè l’aver girato tale documento al suo assicurato) il dovere contrattuale di renderlo edotto del pagamento eseguito e di dargli copia del relativo documento probatorio: poteva infatti oscurarne l’IBAN (§ 2.5.2 e § 2.5.2.1).

La sentenza non convince.

Circa 1) la lamentata pubblicità del dato, reso pubblico dalla produzione in assemblea, prevede appunto anche quest’ultimo elemento, che è però riconducibile solo al condomino/assicurato (non all’assicurazione). La SC non valorizza tale circostanza.

Inoltre andrebbe precisato che l’IBAN costituisce dato personale solo se abbinato ad un nome, non da solo (nel qual caso nessuna riconoscibilità è possibile).

Circa 2) , è dubbio che il documento con IBAN oscurato sia prova sufficiente per l’assicurato. Se il danneggiato contestasse di aver ricevuto il risarcimento, come protrebbe provarlo il condominuo responsabile/assicurato? Gli servirebbe la contabile bancaria di versamento (che contiene l’IBAN). Tra l’altro, nel caso non c’è nemmeno l’azione diretta verso la compagnia, come nella RC auto.

La SC dispone l’oscuramento della sentenza ex art. 52 cod. priv. (d’ufficio, pare, non essendo specificata istanza di parte)

La fattispecie storica è anteriore al GDPR.