Il presente documento è pubblicato in più lingue. In caso di discrepanze tra le versioni linguistiche, fa fede la versione polacca.
Versione 1.0 · Ultimo aggiornamento: 16 ottobre 2026
1. Di che cosa si tratta e che cos’è questa pagina
Questa pagina è la valutazione d’impatto sulla protezione dei dati (DPIA) di formexposed ai sensi dell’Art. 35 GDPR. Risponde innanzitutto alla questione preliminare se una DPIA sia necessaria – separatamente per ciascun trattamento, non per il servizio nel suo complesso. Laddove la risposta è affermativa, effettua la valutazione ai sensi dell’Art. 35(7)(a)–(d): una descrizione sistematica, la necessità e la proporzionalità, i rischi per gli interessati e le misure previste per affrontarli. Seguono il rischio residuo, la questione della consultazione preventiva ai sensi dell’Art. 36 e le regole per il riesame.
L’Art. 35 non impone la pubblicazione di una DPIA. La pubblichiamo per due motivi. In primo luogo, i Clienti che utilizzano la verifica di recapito o la scansione dietro il login hanno bisogno, per la propria valutazione, di fatti che conosciamo solo noi; in qualità di responsabile del trattamento siamo comunque tenuti a fornirglieli (Art. 28(3)(f) GDPR). In secondo luogo, il nostro crawler controlla siti web i cui gestori non ci conoscono. Questi devono poter leggere quali rischi vediamo per loro e per le persone presenti sulle loro pagine, e che cosa facciamo al riguardo.
Natura giuridica. La presente DPIA è una documentazione del titolare del trattamento ai sensi dell’Art. 35 GDPR, che pubblichiamo su base volontaria. Non fa parte di alcun contratto e non costituisce alcuna dichiarazione, garanzia o accordo sulla qualità nei confronti dei Clienti o di terzi. Quali servizi e garanzie dobbiamo ai Clienti è disciplinato dalle Condizioni di servizio, dall’Accordo sul trattamento dei dati e dai relativi allegati; per quanto riguarda tali obblighi, essi prevalgono su questa pagina. La pagina descrive la situazione alla data di questa versione. Le valutazioni del rischio e gli apprezzamenti sono il nostro punto di vista e non anticipano alcuna valutazione giuridica da parte di un’autorità di controllo o di un tribunale; le misure descritte come “previste” sono intenzioni senza una data vincolante. Per i Clienti, la pagina è una base per la propria valutazione, non una consulenza legale.
Questa è la prima versione della valutazione preliminare. Esamina, trattamento per trattamento, se sia necessaria una DPIA e ne riporta l’esito nella sezione 3.5.
Ogni affermazione di fatto è soggetta allo stesso principio valido per gli altri nostri documenti legali: misurato, non previsto. Ciò che è comprovato nel codice o nel database è indicato qui con il relativo riferimento alla fonte. Ciò che non è stato possibile comprovare è contrassegnato come “non verificato”. Ciò che è solo pianificato è indicato come “previsto”. Indichiamo apertamente i punti aperti, insieme alla misura prevista; una DPIA che elenca solo punti di forza non aiuta le persone interessate.
Termini: un gestore è chi gestisce un sito web controllato. Un Cliente ha un account presso formexposed. Un visitatore è chi utilizza il sito web di un Cliente, ad esempio il suo modulo di contatto. Un riferimento alla fonte indica un file, una funzione o un’impostazione nel codice sorgente, rilevati sullo stato del sistema di sviluppo all’11 ottobre 2026.
Tracciamo deliberatamente un limite alla trasparenza: i punti aperti nella protezione dei nostri server sono descritti solo in termini generali (R13). Indichiamo il rischio e il suo livello, ma non la via verso una specifica vulnerabilità; forniremo i dettagli a un’autorità di controllo su richiesta.
2. Ruoli: chi ha l’obbligo e per che cosa
L’Art. 35 pone l’obbligo in capo al titolare del trattamento. formexposed è titolare del trattamento per alcuni trattamenti, responsabile del trattamento per i propri Clienti per altri, e né l’uno né l’altro per i dati che il nostro plugin WordPress e la nostra estensione TYPO3 memorizzano sul sito web di un Cliente. La risposta a quasi tutte le domande di questo documento dipende dal ruolo a cui si riferisce la domanda. La ripartizione segue l’Informativa sulla privacy e l’Accordo sul trattamento dei dati.
| Trattamento | Ruolo di formexposed | Chi ha l’obbligo ai sensi dell’Art. 35 |
|---|---|---|
| Controllo di siti web di terzi senza istruzioni del loro gestore: controllo gratuito, controllo di potenziali clienti per agenzie, studio | Titolare del trattamento | formexposed |
| Controllo dei domini nell’account del Cliente: monitoraggio, invii di prova attivi, percorsi del browser, file esposti, polso del modulo | Titolare del trattamento per i dati dell’account e dei controlli del Cliente; responsabile del trattamento per i dati personali di terzi visibili sul sito web verificato del Cliente; finché un dominio non è verificato, titolare del trattamento come per il controllo gratuito | formexposed per la propria parte; il Cliente per i dati di terzi sul proprio sito web |
| Scansione dietro il login con un account di prova | Responsabile del trattamento: le credenziali e i contenuti dietro il login appartengono al sito web del Cliente | Il Cliente; formexposed fornisce assistenza |
| Verifica di recapito con copia di controllo | Responsabile del trattamento | Il Cliente; formexposed fornisce assistenza |
| Protezione collettiva: elenco condiviso dei domini di link provenienti da spam bloccato | Titolare del trattamento: combiniamo le segnalazioni di molti siti web, compiliamo l’elenco e lo distribuiamo | formexposed |
| Account dei Clienti, accesso, registri, supporto, invio di e-mail, pagamenti, registri probatori | Titolare del trattamento | formexposed |
| Portale clienti e report mensile agli iscritti di un’agenzia | Responsabile del trattamento | L’agenzia |
| Dati che il plugin e l’estensione memorizzano sul sito web del Cliente (quarantena, rete di sicurezza, richieste memorizzate) | Nessuno dei due: i dati non lasciano mai il sito web | Il gestore del sito web |
Ne deriva una distinzione che esplicitiamo, perché viene spesso fraintesa in entrambe le direzioni. Laddove formexposed è titolare del trattamento, effettuiamo noi stessi la valutazione e ne assumiamo l’esito. Laddove siamo responsabili del trattamento, non possiamo effettuare la valutazione del Cliente al suo posto, decidere per lui la questione della necessità né consultare l’autorità di controllo ai sensi dell’Art. 36 per suo conto. Ciò che possiamo e dobbiamo fare in tal caso è fornirgli tutto ciò di cui ha bisogno: la descrizione di cui alla lettera (a), i fatti rilevati sui rischi di cui alla lettera (c) e un elenco onesto dello stato delle misure di cui alla lettera (d). Per la verifica di recapito e la scansione dietro il login, questa pagina è esattamente questo.
Un Cliente che adotta invariate le sezioni sulla verifica di recapito come propria DPIA non ne ha effettuata alcuna. Se la copia di controllo sia giustificata per i suoi moduli, se vi siano da attendersi categorie particolari di dati personali e come informi i propri visitatori sono questioni che solo lui può decidere. La sezione 11 riassume che cosa occorre chiarire a tal fine.
3. Valutazione preliminare: è necessaria una DPIA?
3.1 Art. 35(1) e Art. 35(3)
L’Art. 35(1) richiede una DPIA quando un tipo di trattamento, allorché prevede in particolare l’uso di nuove tecnologie, considerati la natura, l’oggetto, il contesto e le finalità del trattamento, può presentare un rischio elevato per i diritti e le libertà delle persone fisiche. L’Art. 35(3) indica tre casi in cui ciò si verifica in particolare. Nessuno dei tre si applica a formexposed, e ciò va motivato anziché affermato:
- Lettera (a) – una valutazione sistematica e globale di aspetti personali relativi a persone fisiche, basata su un trattamento automatizzato, sulla quale si fondano decisioni che hanno effetti giuridici o incidono in modo analogo significativamente su dette persone. Valutiamo moduli e siti web, non aspetti personali delle persone. Il servizio non adotta alcuna decisione con effetti giuridici su alcuna persona. Ciò che più vi si avvicina è la protezione collettiva: i messaggi contenenti un link a un dominio presente nell’elenco finiscono in quarantena sui siti web collegati. Si tratta di una conseguenza automatizzata per il messaggio, non di una valutazione globale di una persona; la esaminiamo nell’ambito del criterio “Valutazione o assegnazione di un punteggio” nella sezione 3.3.
- Lettera (b) – il trattamento, su larga scala, di categorie particolari ai sensi dell’Art. 9 o di dati relativi a reati ai sensi dell’Art. 10. Non previsto e non realizzato. Tali dati possono tuttavia raggiungerci per una via: nella copia di controllo dei messaggi reali dei visitatori nella verifica di recapito. Ciò dipende dal singolo caso e non costituisce un trattamento su larga scala ai sensi di questa disposizione; viene tuttavia considerato nella valutazione dei rischi (R1).
- Lettera (c) – la sorveglianza sistematica su larga scala di una zona accessibile al pubblico. Si intende l’osservazione fisica di luoghi, non il recupero di pagine web pubbliche. Invocare questa disposizione come aggancio per un crawler di siti web sarebbe errato.
La via corretta è quindi l’Art. 35(1) stesso, applicato attraverso i nove criteri delle Linee guida in materia di valutazione d’impatto sulla protezione dei dati del Gruppo di lavoro Articolo 29 (WP248 rev.01, approvate dal Comitato europeo per la protezione dei dati), e l’elenco dell’autorità di controllo polacca ai sensi dell’Art. 35(4) (sezione 3.4).
3.2 I nove criteri delle linee guida WP248
Le linee guida indicano nove caratteristiche che fanno presumere un probabile rischio elevato. Come regola pratica, un trattamento che soddisfa due di essi richiederà nella maggior parte dei casi una DPIA. Un titolare del trattamento può giungere a una conclusione diversa in un singolo caso, ma deve allora motivarla e documentarla. Viceversa, anche un solo criterio può essere sufficiente. In questa pagina utilizziamo le seguenti denominazioni brevi:
- C1 – Valutazione o assegnazione di un punteggio, inclusiva di profilazione e previsione, ad esempio del rendimento professionale, della situazione economica, dell’affidabilità o del comportamento.
- C2 – Processo decisionale automatizzato che ha effetto giuridico o incide in modo analogo significativamente.
- C3 – Monitoraggio sistematico, ossia trattamento utilizzato per osservare, monitorare o controllare gli interessati, anche attraverso reti. Le linee guida giustificano espressamente questo criterio con il fatto che gli interessati spesso non sanno chi raccoglie i loro dati e per quale finalità.
- C4 – Dati sensibili o dati aventi carattere altamente personale: categorie particolari ai sensi degli Art. 9 e 10, ma anche dati la cui divulgazione incide in modo significativo sulla vita quotidiana, comprese le comunicazioni elettroniche la cui riservatezza deve essere tutelata.
- C5 – Trattamento di dati su larga scala, misurato in base al numero di interessati, al volume e alla gamma di dati, alla durata e all’estensione geografica.
- C6 – Creazione di corrispondenze o combinazione di insiemi di dati provenienti da trattamenti diversi o da titolari del trattamento diversi, in un modo che gli interessati non si aspetterebbero.
- C7 – Dati relativi a interessati vulnerabili, ad esempio dipendenti, minori, pazienti o altre persone in una situazione di squilibrio di potere.
- C8 – Uso innovativo o applicazione di nuove soluzioni tecnologiche od organizzative; nella prassi delle autorità di controllo, l’uso dell’intelligenza artificiale è regolarmente ricondotto a questo criterio.
- C9 – Trattamento che impedisce agli interessati di esercitare un diritto o di avvalersi di un servizio o di un contratto.
Valutiamo ciascun criterio come “soddisfatto”, “caso limite” o “non soddisfatto” e motiviamo la valutazione sulla base del codice. Un caso limite non conta come soddisfatto nel totale, ma viene indicato nell’esito; laddove più casi limite puntano nella stessa direzione, includiamo il trattamento nella valutazione.
3.3 Valutazione per trattamento
P1 – Controllo gratuito senza account (controllo di qualsiasi sito web di terzi su richiesta)
Chiunque può inserire un dominio nella home page. Il crawler recupera quindi al massimo otto pagine pubbliche di quel sito web, legge i moduli, acquisisce screenshot e produce un report visibile a chiunque conosca il suo link casuale. Il gestore del sito web non ne viene a conoscenza, a meno che non noti l’identificativo del crawler nei propri log.
- C1 – caso limite. Il report valuta la protezione di un modulo con un livello (“Esposto”, “Parzialmente protetto”, “Protetto”) e un punteggio. Per una società di capitali ciò non riguarda una persona fisica. Per ditte individuali e liberi professionisti, il dominio può essere attribuito alla persona, e il livello dice allora qualcosa sulla diligenza con cui esercita la propria attività professionale. Ciò che viene valutato è tuttavia una configurazione tecnica, non il comportamento o le caratteristiche di una persona. Lo trattiamo come caso limite.
- C2 – non soddisfatto. Nei confronti del gestore non viene deciso nulla. Nei confronti della persona che richiede il controllo si applicano limiti per indirizzo IP e sessione (
cfg/check_lib.php); un controllo respinto non ha effetti significativi. - C3 – non soddisfatto. Si tratta di un unico recupero su richiesta, al massimo una volta per dominio e settimana (
cfg/check_lib.php, impostazionefc_domain_days= 7). Nessuna persona viene osservata. La circostanza che le linee guida citano per giustificare C3 – gli interessati non sanno nulla del trattamento – è tuttavia presente. Viene considerata nella valutazione dei rischi (R5). - C4 – non soddisfatto. Vengono memorizzati la struttura del modulo e i riscontri, non i valori inseriti (
scanner/src/crawl.jsmemorizza per i campi visibili solo la lunghezza di un valore). Lo scanner legge l’inizio dei campi nascosti precompilati (fino a 24 caratteri) e degli attributi data (fino a 60 caratteri) solo durante il controllo, per riconoscere token e timestamp; non vengono memorizzati. Gli screenshot possono mostrare incidentalmente persone e nomi; il sito web di uno studio medico mostra nell’immagine la sua specializzazione. Si tratta di informazioni professionali pubbliche, non di dati relativi alla salute di una persona specifica. - C5 – caso limite. Il limite giornaliero è di 200 controlli accettati (
fc_daily_cap), ossia aritmeticamente fino a circa 73.000 siti web all’anno. Per ogni sito web si generano solo pochi dati personali, e la durata è breve (30 giorni). Rilevati sul sistema di sviluppo, nel set di dati vi sono 2 controlli anonimi. Oggi non soddisfatto; caso limite considerata la capacità prevista. - C6 – non soddisfatto. Oltre al recupero delle pagine, il servizio interroga l’età del dominio tramite il servizio RDAP rdap.org (viene trasmesso solo il nome di dominio; viene memorizzata, in cache, solo la data di registrazione) e risolve il DNS. Si tratta di dati tecnici sul dominio, non di una combinazione di insiemi di dati su persone.
- C7 – non soddisfatto.
- C8 – soddisfatto, in forma debole. Un browser automatizzato controlla le pagine, e un modello linguistico sul nostro server classifica i moduli che le regole non riconoscono (
scanner/src/classify.js). Il modello vede il titolo della pagina, l’indirizzo, le etichette dei campi e fino a 400 caratteri di testo del modulo. Non può mai rendere un modulo “inviabile”. - C9 – non soddisfatto.
Esito intermedio P1: un criterio in forma debole (C8), due casi limite (C1, C5). Nessun obbligo secondo la regola pratica. Poiché entrambi i casi limite puntano nella stessa direzione e gli interessati non sanno nulla del trattamento, includiamo P1 nella valutazione.
P2 – Controllo di potenziali clienti per agenzie
Un’agenzia con piano Business e con un proprio brand configurato può far controllare passivamente il sito web di un potenziale cliente. Riceve un breve riscontro con il proprio brand e un report dettagliato, e inoltra essa stessa il link (cfg/akquise_lib.php). Noi non contattiamo nessuno.
- C1 – caso limite, più marcato che per P1. Il breve riscontro è espressamente concepito come “apripista per il primo colloquio”. La valutazione del sito web diventa così la base per contattare commercialmente una persona.
- C5 – non soddisfatto. Al massimo 30 controlli per agenzia e mese (
prospect_monthly), cancellati dopo 90 giorni. - C8 – soddisfatto, in forma debole (la stessa tecnologia di P1).
- Altri criteri – non soddisfatti. Il riscontro viene presentato con il brand dell’agenzia, ma non collegato ad altri dati sul gestore.
Esito intermedio P2: nessun obbligo secondo la regola pratica; incluso per gli stessi motivi di P1 e perché la finalità – l’acquisizione di clienti – comporta un rischio proprio (R6).
P3 – Studio “Form Security Index”
Per uno studio viene controllato passivamente un elenco di siti web, con una limitazione a un massimo di cinque job aperti per ciclo del processo di stato, che viene eseguito ogni cinque minuti (cfg/studie_lib.php). Vengono pubblicati solo totali, e segmenti solo a partire da 20 siti web con un modulo (study_min_segment, cfg/studie_lib.php). I dati grezzi vengono cancellati alla pubblicazione (cfg/studie_lib.php).
- C5 – caso limite, soddisfatto per elenchi di grandi dimensioni. La dimensione dell’elenco non è limitata nel codice; la limitazione consente aritmeticamente più di mille controlli al giorno. Uno studio su un mercato nazionale comprende migliaia di siti web, molti dei quali gestiti da ditte individuali. A partire da tali dimensioni consideriamo il criterio soddisfatto.
- C8 – soddisfatto, in forma debole.
- C1 – non soddisfatto. Sebbene il singolo sito web venga valutato, viene pubblicato solo il totale; la valutazione non serve a esprimere un giudizio sul singolo gestore.
- Altri criteri – non soddisfatti.
Esito intermedio P3: per studi delle dimensioni previste, due criteri (C5, C8). Lo studio raggiunge quindi la soglia; formexposed effettua la valutazione in qualità di titolare del trattamento. Rilevato sul sistema di sviluppo, finora non è stato creato alcuno studio.
P4 – Controllo dei domini nell’account del Cliente
Il Cliente fa controllare regolarmente i domini presenti nel proprio account. Una volta dimostrato di avere diritto al controllo del dominio, si aggiungono gli invii di prova attivi (al massimo cinque per controllo), la ricerca di file esposti e i percorsi del browser configurati.
- C3 – non soddisfatto. Il controllo è pianificato e ricorrente, ma riguarda il sito web del Cliente stesso e viene effettuato su sua richiesta, non per osservare persone.
- C4 – caso limite, no. La ricerca di file esposti legge al massimo i primi 8 KB da percorsi come
/backup.sqlo un log di debug, per stabilire dal contenuto se il file è effettivamente esposto (cfg/dateien_lib.php). Un tale estratto può contenere dati inseriti nei moduli dai visitatori. Viene verificato solo in memoria e mai memorizzato; vengono memorizzati percorso, tipo e gravità. - C8 – soddisfatto, in forma debole.
- Altri criteri – non soddisfatti.
Esito intermedio P4: nessun obbligo. Incluso perché gli invii di prova attivi e il controllo dei file dipendono da una prova che non viene mai rinnovata (R7).
P5 – Scansione dietro il login
Per un dominio verificato, il Cliente può memorizzare un account di prova per il proprio sito web. Lo scanner accede con esso e legge i moduli su un massimo di cinque pagine indicate dell’area riservata (cfg/login_lib.php, scanner/src/login.js).
- C4 – caso limite. Le credenziali non sono dati aventi carattere altamente personale ai sensi delle linee guida, ma il loro uso improprio apre l’accesso all’area riservata. A seconda del sito web, dietro un login possono trovarsi contenuti riservati, ad esempio in un portale per soci o pazienti. Ciò dipende dal Cliente, non da noi.
- C8 – non soddisfatto. Gli accessi automatizzati sono comuni nei servizi di monitoraggio.
- Altri criteri – non soddisfatti.
Esito intermedio P5: nessun obbligo secondo la regola pratica. Per i Clienti la cui area riservata mostra contenuti riservati, ciò può cambiare; la decisione spetta allora a loro. Incluso a causa dei rischi per la sicurezza (R8).
P6 – Verifica di recapito con copia di controllo
Il Cliente inserisce un indirizzo di controllo di formexposed come copia nascosta nelle impostazioni e-mail del proprio modulo. Di conseguenza, ogni e-mail del modulo viene inviata anche alla nostra casella di controllo – il nostro messaggio di prova così come ogni messaggio reale di un visitatore. Un recupero automatizzato legge gli header e i primi 8 KB, associa l’e-mail, valuta SPF, DKIM e DMARC e la cancella (cfg/zustellung_lib.php).
- C4 – soddisfatto. Ciò che i visitatori scrivono in un modulo di contatto è una comunicazione elettronica a un’impresa dal contenuto arbitrario. Sul sito web di uno studio medico, di uno studio legale, di un servizio di consulenza o di una scuola sono da attendersi dati ai sensi dell’Art. 9 o relativi a minori. Le linee guida citano espressamente in questo criterio le comunicazioni elettroniche riservate.
- C3 – caso limite, piuttosto soddisfatto. Ogni messaggio viene copiato in modo pianificato e continuativo e valutato automaticamente, senza che il mittente se ne accorga. La finalità è verificare il percorso della posta, non osservare persone. Tuttavia, la circostanza con cui le linee guida giustificano il criterio – gli interessati non sanno chi riceve i loro dati – è pienamente presente finché il Cliente non informa i propri visitatori.
- C7 – a seconda del Cliente. Pazienti, clienti di studi legali, candidati, genitori e alunni si trovano spesso in un rapporto di dipendenza nei confronti del destinatario del loro messaggio.
- C5 – caso limite, no. Non su larga scala per il singolo Cliente. Presso formexposed le copie di molti Clienti confluiscono in un’unica casella di posta; ciò aumenta il peso di una violazione, non il numero per titolare del trattamento.
- Altri criteri – non soddisfatti. L’associazione a dominio e test non è una creazione di corrispondenze tra insiemi di dati su persone; la tecnologia non è nuova.
Esito intermedio P6: C4 soddisfatto, C3 caso limite e piuttosto soddisfatto, C7 soddisfatto per molti Clienti tipici. Nella configurazione tipica sono quindi soddisfatti due o più criteri. È necessaria una DPIA – come obbligo del Cliente, che è il titolare del trattamento. Le sezioni da 6 a 11 gli forniscono i fatti a tal fine.
P7 – Protezione collettiva (swarm)
I siti WordPress collegati segnalano una volta al giorno i domini dei link contenuti in messaggi che il loro livello di protezione ha bloccato. Un dominio che compare su almeno tre siti web diversi con almeno cinque occorrenze nell’arco di sette giorni viene inserito in un elenco condiviso; l’elenco viene restituito a tutti i siti web collegati, che spostano quindi in quarantena i messaggi con link a quel dominio (cfg/swarm_lib.php).
- C6 – soddisfatto. Le segnalazioni di molti siti web indipendenti tra loro, ossia di titolari del trattamento diversi, vengono combinate e restituite a tutti come elenco condiviso.
- C1 – soddisfatto, nella misura in cui un dominio può essere attribuito a una persona fisica. L’elenco è una classificazione come fonte di spam. Le linee guida citano come esempio di questo criterio il confronto con una banca dati condivisa sulle frodi. La maggior parte dei domini in un tale elenco appartiene a imprese o è costituita da domini usa e getta; tuttavia, vi può finire il dominio di una persona, a ragione o a causa di false segnalazioni introdotte deliberatamente.
- C9 – caso limite. Un messaggio con un link presente nell’elenco non raggiunge immediatamente il destinatario, ma resta nella sua quarantena finché non lo sblocca. Non va perso.
- C2 – non soddisfatto. La quarantena è una conseguenza automatizzata per un messaggio, senza effetti giuridici e con sblocco umano da parte del destinatario.
- Altri criteri – non soddisfatti. Le reti IP sono disattivate (
swarm_ip_enabled= 0,cfg/swarm_lib.php).
Esito intermedio P7: due criteri (C6, C1) e un caso limite (C9). La soglia è raggiunta; formexposed effettua la valutazione in qualità di titolare del trattamento. Con le reti IP attivate, C1 e C6 sarebbero soddisfatti senza riserve; la loro attivazione richiede una nuova versione della presente valutazione (sezione 12). Rilevati sul sistema di sviluppo, non vi sono né segnalazioni né voci nell’elenco.
P8 – Account dei Clienti, accesso, registri, supporto, e-mail, pagamenti
- C1 e C9 – non soddisfatti. Un comportamento anomalo nel controllo gratuito porta a una nota con l’indirizzo IP (
cfg/check_lib.php) e, se del caso, al rifiuto di ulteriori controlli. Si tratta di prevenzione degli abusi con effetti limitati, non di una valutazione di aspetti personali. - Altri criteri – non soddisfatti. Si tratta dei dati consueti di un servizio per le imprese.
Esito intermedio P8: nessuna DPIA necessaria. I trattamenti sono descritti nel Registro delle attività di trattamento.
P9 – Dati numerici del plugin, errori dei campi, registratore, badge, portale clienti, “Fix it for me”
- Il plugin e l’estensione trasmettono dati numerici giornalieri, l’inventario dei plugin e le categorie di errore, e il plugin WordPress trasmette inoltre i domini dei link per la protezione collettiva (attiva per impostazione predefinita) (P7), nessun contenuto, indirizzo, nome o IP dei visitatori; il registratore conserva i selettori per al massimo 15 minuti nel browser dell’amministratore. Nessun criterio soddisfatto.
- Al caricamento, il badge trasferisce i consueti dati di connessione nel log del server web, senza cookie. Nessun criterio soddisfatto.
- Il portale clienti tratta gli indirizzi e-mail degli iscritti con double opt-in per conto dell’agenzia. Nessun criterio soddisfatto.
- “Fix it for me” fa riscrivere il codice del modulo incollato da un modello linguistico sul nostro server; il codice non viene memorizzato. C8 in forma debole, nient’altro.
Esito intermedio P9: nessuna DPIA necessaria.
3.4 L’elenco dell’autorità di controllo polacca ai sensi dell’Art. 35(4)
L’autorità competente è il Presidente dell’Ufficio per la protezione dei dati personali (Prezes Urzędu Ochrony Danych Osobowych, UODO). Il Presidente ha pubblicato l’elenco delle tipologie di trattamenti soggetti a DPIA nella comunicazione del 17 giugno 2019 (Komunikat Prezesa Urzędu Ochrony Danych Osobowych z dnia 17 czerwca 2019 r. w sprawie wykazu rodzajów operacji przetwarzania danych osobowych wymagających oceny skutków przetwarzania dla ich ochrony, Monitor Polski 2019, voce 666). L’elenco riconduce le sue voci ai criteri delle linee guida WP248, fornisce esempi ed è espressamente non esaustivo; non sostituisce la valutazione ai sensi dell’Art. 35(1).
Secondo la nostra lettura, le seguenti tipologie di trattamento dell’elenco corrispondono nella sostanza a trattamenti di formexposed:
| Tipologia di trattamento secondo l’elenco (parafrasata) | Criterio associato | Trattamento presso formexposed | Valutazione |
|---|---|---|---|
| Confronto, valutazione o deduzione basati sull’analisi di dati provenienti da fonti diverse | C6 | P7 Protezione collettiva | si applica |
| Valutazione o assegnazione di un punteggio, inclusa la profilazione | C1 | P7 Protezione collettiva; P1 e P2 come casi limite | si applica a P7 |
| Trattamento di categorie particolari di dati personali | C4 | P6 Verifica di recapito | si applica a seconda del Cliente |
| Uso innovativo o applicazione di soluzioni tecnologiche | C8 | Da P1 a P4 (modello linguistico per la classificazione) | si applica in forma debole |
| Trattamento su larga scala | C5 | P3 Studio | si applica agli elenchi di grandi dimensioni |
| Monitoraggio sistematico di luoghi accessibili al pubblico, anche con riconoscimento di caratteristiche | C3 | – | non si applica: si intendono luoghi, non siti web |
Questa associazione è una lettura, non una citazione; la formulazione delle voci va verificata nella verifica legale. Conferma l’esito della sezione 3.3 ma non lo modifica. Per quanto ci risulta, l’UODO non ha pubblicato un elenco ai sensi dell’Art. 35(5) – trattamenti per i quali non è richiesta una DPIA.
3.5 Esito della valutazione preliminare
| Trattamento | Soddisfatti | Casi limite | Esito |
|---|---|---|---|
| P1 Controllo gratuito | C8 (debole) | C1, C5 | non obbligatoria; incluso |
| P2 Controllo di potenziali clienti | C8 (debole) | C1 | non obbligatoria; incluso |
| P3 Studio | C8 (debole), C5 per elenchi di grandi dimensioni | – | necessaria (obbligo di formexposed) |
| P4 Controllo dei domini dei Clienti | C8 (debole) | C4 (controllo dei file) | non obbligatoria; incluso |
| P5 Scansione dietro il login | – | C4 | non obbligatoria; incluso; per il Cliente a seconda dei contenuti |
| P6 Verifica di recapito | C4; C7 a seconda del Cliente | C3 (piuttosto soddisfatto), C5 | necessaria (obbligo del Cliente; questa pagina fornisce assistenza ai sensi dell’Art. 28(3)(f)) |
| P7 Protezione collettiva | C6, C1 | C9 | necessaria (obbligo di formexposed) |
| P8 Account, registri, supporto, pagamenti | – | – | non necessaria |
| P9 Dati numerici del plugin, badge, portale, “Fix it for me” | C8 (debole, solo “Fix it for me”) | – | non necessaria |
Esito sull’Art. 35(1): Per singoli trattamenti di formexposed è necessaria una DPIA. È necessaria per la protezione collettiva e per gli studi delle dimensioni previste, e formexposed la effettua in qualità di titolare del trattamento. Per la verifica di recapito è necessaria nella configurazione tipica, ma come obbligo del Cliente; formexposed ne fornisce la base. Per gli altri controlli di siti web di terzi e propri non è obbligatoria. Li includiamo comunque, perché utilizzano la stessa tecnologia, perché più casi limite puntano nella stessa direzione e perché gli interessati – gestori senza account e persone presenti sulle pagine controllate – non sanno nulla del trattamento. Per account, registri, supporto e pagamenti non è necessaria alcuna valutazione.
Le sezioni da 6 a 10 si applicano quindi ai trattamenti da P1 a P7. Laddove un’affermazione si riferisce a uno solo di questi trattamenti, ciò è indicato.
4. Responsabile della protezione dei dati: la valutazione ai sensi dell’Art. 37
Non è stato designato alcun responsabile della protezione dei dati. L’Art. 37(1) vincola allo stesso modo il titolare del trattamento e il responsabile del trattamento; la questione è quindi nostra. I tre casi previsti dalla legge:
| Art. 37(1) | Condizione | Esito |
|---|---|---|
| lettera (a) | Autorità pubblica o organismo pubblico | Non applicabile; LW IT Solutions Company Lukas Wójcik è una ditta individuale privata. |
| lettera (b) | Le attività principali consistono in trattamenti che richiedono il monitoraggio regolare e sistematico degli interessati su larga scala | L’attività principale è il controllo e il monitoraggio di siti web e moduli, in modo regolare e sistematico. Tuttavia, nessuna persona viene monitorata: il crawler non osserva comportamenti, e la verifica di recapito valuta le e-mail solo in relazione a recapito e autenticità. Non soddisfatta. |
| lettera (c) | Le attività principali consistono nel trattamento su larga scala di dati ai sensi dell’Art. 9 o 10 | Non per progettazione. Categorie particolari possono raggiungerci tramite la copia di controllo della verifica di recapito; ciò è incidentale, non un’attività principale. Non soddisfatta. |
A nostro giudizio non sussiste quindi l’obbligo di designarlo. Se il diritto polacco imponga una designazione ulteriore ai sensi dell’Art. 37(4) è una questione aperta per la verifica legale. Poiché non è stato designato alcun responsabile della protezione dei dati, il parere di cui all’Art. 35(2) non si applica. Se la verifica legale accerta che sussiste un obbligo di designazione, il parere del responsabile della protezione dei dati allora designato verrà richiesto prima dell’approvazione della presente valutazione (sezione 12). La persona di contatto per domande sulla presente valutazione è il titolare all’indirizzo contact@lukaswojcik.com.
5. Metodo, fonti e limiti di questa versione
I fatti contenuti in questo documento provengono dal codice sorgente dell’applicazione e dello scanner, dallo schema del database, nonché dai conteggi delle righe e dalle impostazioni del sistema di sviluppo, rilevati l’11 ottobre 2026. Il database e i server sono stati consultati in sola lettura. Laddove una rilevazione contraddice un’intenzione – compresa un’affermazione contenuta nei nostri documenti legali – riportiamo la rilevazione. Non applichiamo codici di condotta approvati ai sensi dell’Art. 40, il cui rispetto dovrebbe essere tenuto in considerazione ai sensi dell’Art. 35(8).
- È stato rilevato il sistema di sviluppo. Il servizio non è ancora stato lanciato. I dati sono quindi esigui e in parte artefatti dei test: 112 controlli, di cui 110 senza dominio di un Cliente; 432 screenshot; 2 domini, di cui 1 verificato; nessuna verifica di recapito attivata; nessun account di prova memorizzato per la scansione dietro il login; nessuno studio; nessuna segnalazione nella protezione collettiva. Le rilevazioni devono essere ripetute prima del lancio e successivamente a intervalli regolari.
- Non rilevati in questa versione e da integrare prima dell’approvazione sono: la configurazione del sistema di produzione, compreso se e come vi sia configurata la casella di controllo e se vi sia configurata la coppia di chiavi per la scansione dietro il login; se il software del modello linguistico registri le richieste; lo stato dell’amministrazione dei server (R13); il contratto con il fornitore del servizio di posta.
- Non è stato possibile rilevare quanti messaggi reali dei visitatori passeranno attraverso la copia di controllo e da quali settori proverranno i Clienti. Entrambi gli aspetti determinano il peso di R1 e R2 e devono essere accertati dopo il lancio.
- I riferimenti alla fonte rimandano a file e funzioni nel codice sorgente del sistema di sviluppo. Ciò che conta è la funzione descritta, non la sua posizione nel file.
Il presente documento è una bozza. Non è ancora stato approvato dal titolare del trattamento (sezione 12), e due delle sue conclusioni – la valutazione della scala per P1 e P3 e il peso della verifica di recapito – dipendono da dati che saranno disponibili solo dopo il lancio.
6. (a) Descrizione sistematica dei trattamenti e delle finalità
6.1 Come è strutturato il sistema di controllo
formexposed funziona su server propri in Polonia, senza un fornitore di hosting esterno: un server web con l’applicazione e il database, e un server di scansione con il servizio di controllo e un modello linguistico locale, entrambi nella stessa rete interna. Un controllo si svolge come segue:
- L’applicazione crea un job nel database – nel rispetto dei limiti e dei blocchi indicati nella sezione 6.3.
- Il servizio di controllo sul server di scansione preleva il job, verifica una seconda volta la blocklist, i nomi host e, per i controlli anonimi, l’età del dominio, e avvia un container isolato esattamente per questo job: una propria rete con proprie regole di filtraggio, nessun privilegio particolare, un file system di sola lettura, limiti di memoria e di processi e un limite di tempo (
scanner/src/worker.js). - All’interno del container, un browser automatizzato recupera al massimo otto pagine pubbliche, prima la home page, poi preferibilmente le pagine di contatto, di note legali e di supporto. Prima legge il file robots.txt; un’esclusione per FormExposedBot o per tutti i crawler che riguarda la home page pone fine al controllo, così come un robots.txt irraggiungibile o un errore del server durante il recupero (
scanner/src/net.js). I divieti relativi a singoli sottopercorsi non vengono rispettati separatamente. Il polso del modulo, il recupero della prova, lo strumento per gli header e la ricerca di file esposti non leggono il robots.txt. Oltre alle otto pagine, vi sono fino a tre pagine con un clic su “Rifiuta” nel banner dei cookie, fino a tre pagine in visualizzazione per smartphone, sonde attive per i domini verificati e fino a cinque pagine dietro un login; le pagine vengono caricate una dopo l’altra, non in parallelo. Ogni richiesta del browser – compresi reindirizzamenti e contenuti incorporati – passa attraverso un filtro che respinge reti private e altre porte. - Il container scrive un risultato e gli screenshot in una directory temporanea. Il servizio di controllo trasmette il risultato e le immagini all’applicazione tramite la rete interna e cancella la directory temporanea, anche in caso di errore (
scanner/src/worker.js). - L’applicazione elabora il risultato, lo confronta con il controllo precedente per i domini dei Clienti e segnala le modifiche alle destinazioni configurate dal Cliente.
6.2 Che cosa memorizza il crawler – e che cosa no
| Elemento | Che cosa viene memorizzato | Che cosa non viene memorizzato | Riferimento alla fonte |
|---|---|---|---|
| Pagine | Indirizzo, stato HTTP, header, Content Security Policy, host di terzi richiesti (al massimo 120) | Contenuto della pagina come testo o HTML | scanner/src/crawl.js |
| Campi del modulo | Tipo, nome, etichetta, placeholder, campo obbligatorio, visibilità, lunghezza di un valore esistente | Valori dei campi; per i campi nascosti, i primi 24 caratteri del valore vengono solo letti durante il controllo (per riconoscere i token) | scanner/src/crawl.js |
| Indirizzi dei destinatari nel modulo | solo il dominio | l’indirizzo | scanner/src/crawl.js |
| Script | Inventario con checksum; indirizzi e testo iniziale senza identificativi di account dei servizi pubblicitari e di analisi | Identificativi di account e di pixel | scanner/src/crawl.js |
| Ascoltatori indiscreti | quali pixel pubblicitari e strumenti di registrazione vengono caricati prima e dopo il clic su “Rifiuta” nel banner dei cookie, e se mascherano i dati inseriti | Identificativi degli account presso questi servizi | scanner/src/mitleser.js, scanner/src/einwilligung.js |
| Testo del modulo | fino a 400 caratteri vengono inviati al modello linguistico locale se le regole non riconoscono il tipo | Comunicazione a terzi; memorizzazione del testo | scanner/src/classify.js |
| Screenshot (crawler) | area visibile della prima pagina; per ogni modulo visibile, un’immagine dell’elemento del modulo | – | scanner/src/crawl.js |
| Screenshot (controllo attivo) | Immagine della pagina di risposta all’invio di prova; inoltre stato, indirizzo di destinazione, titolo e i primi 300 caratteri del suo testo | – | scanner/src/active.js |
| Screenshot (percorsi del browser) | Immagine del modulo con i campi di input oscurati, compressa, al massimo 32 KB | Dati inseriti | scanner/src/browser.js |
| Dietro il login | come per i campi del modulo sopra | Screenshot, cookie, link | scanner/src/login.js |
Questi elementi non contengono dati personali per progettazione, ma li contengono incidentalmente: il nome di una persona di contatto accanto al modulo, una foto del team nella home page, un numero di telefono in un’etichetta, il dominio e-mail di una persona, un nome in un placeholder. Dietro il login si aggiungono dati dell’account di prova e, a seconda del sito web, di altri utenti.
6.3 Chi avvia un controllo e che cosa si applica in tal caso
| Avvio | Livello di attendibilità nel job | Invii di prova | Risultato accessibile tramite | Cancellazione |
|---|---|---|---|---|
| Qualcuno inserisce un dominio nella home page (controllo gratuito) | anonimo | no | Report a un link casuale | 30 giorni, immagini comprese (cfg/check_lib.php) |
| Plugin o estensione senza account | plugin | no | Report a un link casuale | 30 giorni |
| Agenzia per un potenziale cliente | registrato | no | Breve riscontro e report a un link casuale | 90 giorni (cfg/akquise_lib.php) |
| Cliente, dominio senza prova | registrato | no | Account; report a un link casuale | 13 mesi, l’ultimo controllo viene conservato |
| Cliente, dominio con prova | verificato | sì, al massimo cinque per controllo | Account; report a un link casuale | 13 mesi, l’ultimo controllo viene conservato (cfg/fristen_lib.php) |
| Studio | interno | no | solo totali dopo la pubblicazione | alla pubblicazione; senza pubblicazione nessun limite di tempo (R4) |
| Controllo interno dalla riga di comando da parte del fornitore | interno; per i nostri domini di test e demo anche “verificato” | no; con il livello “verificato” sì (solo i nostri domini di test e demo) | solo internamente | nessun limite di tempo (R4) |
A monte del controllo gratuito vi sono diversi livelli (cfg/check_lib.php): un arresto di emergenza; reCAPTCHA; lo stesso dominio al massimo una volta ogni sette giorni (dopodiché viene mostrato il report esistente); limiti per indirizzo IP, per sessione (come valore hash, mai l’identificativo di sessione stesso) e per l’intero servizio al giorno; la blocklist derivante da opt-out e robots.txt; la verifica che il dominio punti a indirizzi pubblici; e un blocco per domini molto recenti o sconosciuti. Le anomalie – molti domini diversi da un unico indirizzo IP, molte richieste in poco tempo – vengono annotate con l’indirizzo IP e attivano un segnale senza contenuto (cfg/check_lib.php).
6.4 Controllo dei domini nell’account del Cliente
Il Cliente dimostra di avere diritto al controllo di un dominio: tramite record DNS, meta tag, file o tramite il nostro plugin (cfg/verify_lib.php). Solo allora il dominio viene considerato verificato. Il pianificatore del monitoraggio programma controlli regolari solo per domini attivi, monitorati e verificati (cfg/monitor_lib.php).
- Gli invii di prova attivi sono vincolati a due barriere: l’applicazione imposta la modalità attiva per i Clienti solo per i domini verificati (per i nostri domini di test e demo, il fornitore può creare un controllo con il livello “verificato” tramite uno strumento interno da riga di comando), e il servizio di controllo verifica nuovamente il livello di attendibilità e l’arresto di emergenza
fc_active_enabled(scanner/src/worker.js). Può essere inviato solo un modulo che le regole riconoscono con elevata certezza come modulo di contatto generico, che non ha campi obbligatori per dati personali reali e il cui dominio non sembra appartenere a un’autorità pubblica, a un istituto di istruzione, a una clinica, a uno studio medico, alla polizia o a un tribunale (scanner/src/classify.js). Il modello linguistico non può rendere inviabile un modulo (scanner/src/classify.js). Per ogni controllo vengono effettuati al massimo cinque invii (fc_active_max_posts), chiaramente contrassegnati, con il mittentedummy@formexposed.com, un indirizzo sotto.invalidper testare la convalida dell’e-mail e una riga di header aggiuntiva innocua per rilevare l’header injection (scanner/src/active.js). - I percorsi del browser verificano in un browser i percorsi dei moduli configurati fino al punto immediatamente precedente l’invio. Sono consentite solo richieste GET e HEAD; tutto il resto viene interrotto, così come gli indirizzi contenenti parole relative a disconnessione, cancellazione, acquisto o pagamento (
scanner/src/browser.js). Per il controllo, i campi obbligatori vengono compilati con valori fittizi che non lasciano mai il browser. - I file esposti vengono cercati settimanalmente, solo per i domini verificati, con al massimo un recupero per percorso, al massimo 8 KB, e il contenuto non viene mai memorizzato (
cfg/dateien_lib.php). - Una seconda sonda indipendente è stata predisposta ed è disattivata per impostazione predefinita (
browser_probe_enabled= 0). Se attivata, riceverebbe solo dominio, indirizzo, selettore, passaggi e scelta del browser, mai credenziali, screenshot o dati dei visitatori (cfg/formular_probe_lib.php).
6.5 Scansione dietro il login
Presupposti: la funzione è configurata, il dominio è verificato e il Cliente ha un piano a pagamento ed è proprietario o amministratore del workspace (cfg/login_lib.php); conferma che l’account è un account di prova con il minor numero possibile di diritti (cfg/login_lib.php).
- Nome utente e password vengono cifrati immediatamente sul server web con la chiave pubblica del server di scansione: una chiave monouso per ogni record (X25519), derivazione della chiave (HKDF-SHA256), AES-256-GCM, vincolata al dominio (
cfg/login_lib.php). Solo il servizio di controllo sul server di scansione possiede la chiave privata (scanner/src/geheim.js). Chi dispone del server web, del database o di un backup ha solo testo cifrato. - L’interfaccia mostra solo il primo carattere e la lunghezza del nome utente (
cfg/login_lib.php). Le credenziali non vengono mai visualizzate, mai registrate e mai restituite tramite l’API. - Per un controllo, l’applicazione allega il testo cifrato al job. Il servizio di controllo lo decifra, svuota immediatamente il campo nel job e trasmette le credenziali al container solo tramite lo standard input, mai come argomenti della riga di comando (
scanner/src/worker.js). I residui nei job interrotti vengono eliminati dal processo di stato dopo un’ora (cfg/login_lib.php). - All’interno del container, il browser effettua l’accesso. Si interrompe se la pagina di login reindirizza a un altro host, se il modulo di login presenta un CAPTCHA (non aggiriamo i CAPTCHA) o se dopo l’invio è ancora visibile un campo password (
scanner/src/login.js). Svuota quindi il campo password nella memoria della pagina e dimentica le credenziali (scanner/src/login.js). - Legge al massimo cinque pagine dello stesso dominio indicate dal Cliente. Gli indirizzi contenenti parole relative a disconnessione, cancellazione, rimozione o disdetta vengono bloccati (
scanner/src/login.js). Dietro il login non viene inviato nulla, non vengono acquisiti screenshot, e cookie e link non finiscono nel risultato (scanner/src/login.js). - La cancellazione è definitiva: il testo cifrato viene sovrascritto con dati casuali della stessa lunghezza, la riga viene cancellata e i job in sospeso vengono eliminati (
cfg/login_lib.php). Quando il dominio viene cancellato, la riga scompare automaticamente tramite una chiave esterna.
6.6 Verifica di recapito
La verifica di recapito risponde alla domanda se un’e-mail del modulo di contatto arrivi davvero e ne valuta le caratteristiche di autenticità. È facoltativa, disattivata per impostazione predefinita e richiede che sia configurata una casella di controllo (cfg/zustellung_lib.php).
- Se il Cliente la attiva, il dominio riceve un tag casuale. Il Cliente inserisce l’indirizzo di controllo con questo tag come copia nascosta nel proprio modulo.
- Da quel momento ogni e-mail del modulo viene inviata anche alla casella di controllo: i nostri invii di prova contrassegnati e tutti i messaggi reali dei visitatori. Le e-mail arrivano direttamente nella casella presso Namecheap, Inc. (Private Email), Phoenix, Arizona, USA – arrivano solo se i record MX del nostro dominio puntano lì; tramite un inoltro, ad esempio presso il registrar del dominio Namecheap, Inc., non raggiungono la casella – e vi restano finché non vengono recuperate.
- Il processo di stato recupera la casella ogni cinque minuti (
srv/cron_status.php). Per ogni e-mail legge gli header e al massimo i primi 8 KB del testo, senza contrassegnarle come lette (cfg/zustellung_lib.php). - Dagli header determina il tag e quindi il dominio, e dal testo, se del caso, l’identificativo del nostro test (
cfg/zustellung_lib.php). Vengono memorizzati l’ora, il dominio e, se del caso, l’identificativo del test (cfg/zustellung_lib.php), per 180 giorni (cfg/zustellung_lib.php). - Dagli header valuta SPF, DKIM e DMARC e memorizza il risultato in relazione al dominio: i risultati delle verifiche, il dominio dell’indirizzo del mittente, i domini delle firme e l’indirizzo del server di posta mittente (
cfg/zustellung_lib.php). Se il risultato peggiora, al Cliente viene inviato una volta un avviso che può indicare il dominio del mittente (cfg/zustellung_lib.php). - Contrassegna quindi ogni e-mail recuperata per la cancellazione, compresa quella che non è stato possibile associare ad alcun dominio, e la rimuove dalla casella al termine del ciclo (
cfg/zustellung_lib.php). Se il ciclo si interrompe prima, le e-mail restano fino al successivo ciclo riuscito. - Vale come prova di recapito solo la copia esattamente del test in questione (
cfg/zustellung_lib.php). Se non arriva entro tre ore (delivery_wait_h), il servizio segnala “Recapito mancante”.
Il testo dei messaggi reali non viene mai scritto nel database, né l’indirizzo del visitatore. Entrambi vengono comunque letti: il recupero carica in memoria i primi 8 KB di ogni e-mail per cercare l’identificativo del test.
6.7 Protezione collettiva (swarm)
- Il livello di protezione del plugin WordPress blocca un messaggio come spam e conta i domini dei link in esso contenuti. Una volta al giorno il plugin ci segnala questi domini con il relativo numero di occorrenze, al massimo 60 al giorno; nessun indirizzo, nessun testo, nessun indirizzo IP (
cfg/swarm_lib.php). - Una volta al giorno compiliamo da ciò l’elenco: un dominio vi viene inserito se nell’arco di sette giorni è stato segnalato da almeno tre siti web diversi e con almeno cinque occorrenze (
swarm_min_sites,swarm_window_days,cfg/swarm_lib.php). I grandi servizi di un elenco fisso di eccezioni e i domini dei nostri Clienti, in entrambi i casi compresi i sottodomini, non vengono mai inseriti nell’elenco (cfg/swarm_lib.php). - L’elenco viene inviato a tutti i siti web collegati con la risposta alla segnalazione giornaliera. Il loro livello di protezione sposta i messaggi con link a domini presenti nell’elenco in quarantena, non nel cestino.
- Ciò che non compare più nel nuovo elenco viene escluso; le segnalazioni vengono cancellate dopo 30 giorni (
cfg/swarm_lib.php). - Le reti IP (/24 o /48) sono state predisposte, ma restano disattivate fino al completamento della verifica legale (
cfg/swarm_lib.php).
6.8 Uso dell’intelligenza artificiale
Un modello linguistico funziona sul nostro server di scansione, non presso un fornitore di IA. Viene utilizzato in due punti: nel servizio di controllo classifica i moduli il cui tipo non è riconosciuto dalle regole; a tal fine vede il titolo della pagina, l’indirizzo della pagina, le etichette dei pulsanti di invio, i tipi di campo, i nomi, le etichette e i placeholder, e fino a 400 caratteri di testo del modulo (scanner/src/classify.js). Viene interpellato solo se le regole restituiscono “sconosciuto”; i moduli classificati in questo modo non vengono mai inviati e non contano ai fini del punteggio e del giudizio. Punteggio, giudizio, prevenzione degli abusi, protezione collettiva e regole antispam sono regole fisse, non IA. In “Fix it for me” riscrive il codice del modulo incollato; il codice non viene memorizzato. Il modello non adotta decisioni su persone. Maggiori informazioni nella pagina Regolamento UE sull’IA: come formexposed utilizza l’IA.
6.9 Basi giuridiche
| Trattamento | Base giuridica |
|---|---|
| P1 Controllo gratuito: controllo del dominio richiesto; limiti e prevenzione degli abusi | nei confronti della persona richiedente, Art. 6(1)(b); nei confronti del gestore e delle persone raffigurate, Art. 6(1)(f); prevenzione degli abusi, Art. 6(1)(f) |
| P2 Controllo di potenziali clienti | Art. 6(1)(f) (legittimo interesse dell’agenzia e di formexposed) |
| P3 Studio | Art. 6(1)(f) |
| P4 Controllo dei domini dei Clienti | Art. 6(1)(b) nei confronti del Cliente; per i dati di terzi sul suo sito web, le istruzioni del Cliente ai sensi dell’Art. 28 |
| P5 Scansione dietro il login | Istruzioni del Cliente ai sensi dell’Art. 28; la base giuridica del Cliente |
| P6 Verifica di recapito | Istruzioni del Cliente ai sensi dell’Art. 28; la base giuridica del Cliente (nel nostro testo suggerito per i Clienti, Art. 6(1)(f)) |
| P7 Protezione collettiva | Art. 6(1)(f) (difesa comune dallo spam su molti siti web) |
Il nostro legittimo interesse per P1–P3 consiste nel mostrare ai gestori e ai loro fornitori di servizi le debolezze dei loro moduli prima che vengano sfruttate per spam o abusi, e nel fornire il servizio. I dati provengono da fonti accessibili al pubblico. Il bilanciamento degli interessi è illustrato nella sezione 7; se l’Art. 6(1)(f) consenta il controllo di siti web di terzi su richiesta è una questione aperta per la verifica legale.
6.10 Destinatari e trasferimenti verso paesi terzi
| Destinatario | Che cosa | Trattamento | Stato |
|---|---|---|---|
| Nessuno al di fuori di formexposed | Risultati dei controlli, screenshot, classificazione da parte del modello linguistico | P1–P5 | Il servizio di controllo e il modello linguistico funzionano sui nostri server; nel percorso di controllo del crawler non è stata rilevata alcuna chiamata a terzi diversa da quelle al sito web controllato stesso, ai servizi di cui esso incorpora contenuti (come per qualsiasi visitatore) e al servizio RDAP rdap.org per l’età del dominio (solo il nome di dominio); le sorveglianze del monitoraggio sono elencate nella riga successiva |
| Chiunque conosca il link | Report con riscontri e screenshot | P1, P2, P4 | link casuale a 128 bit (cfg/check_lib.php), pagine con noindex (www/report.php) |
| Servizi interrogati dal monitoraggio di un dominio del Cliente | Blocklist DNS (SpamCop, PSBL, Mailspike, SURBL): domini e indirizzi IP dei server, nessun dato dei visitatori; Google Web Risk solo se configurato: l’indirizzo della home page; autorità di marcatura temporale Certum e DigiCert: solo un valore hash del registro probatorio; RDAP tramite il registro IANA: solo il nome di dominio; pagine di stato dei fornitori: non viene trasmesso nulla; wpvulnerability.net: identificativo di un plugin (senza versione) o di un tema e la versione di WordPress | P4 | in uso; dettagli nel Registro delle attività di trattamento e nella pagina Sub-responsabili del trattamento |
| Namecheap, Inc. (Private Email), Phoenix, Arizona, USA | Copie di controllo compresi i messaggi reali dei visitatori | P6 | Contratto non ancora stipulato; luogo del trattamento e meccanismo di trasferimento ancora da esaminare |
| Namecheap, Inc. (USA) | Registrar e DNS; fino alla configurazione della casella, inoltro delle e-mail generali indirizzate ad indirizzi del nostro dominio, non delle copie di controllo (queste raggiungono la casella solo tramite record MX che puntano direttamente a essa) | – (nessuna copia di controllo) | Meccanismo di trasferimento da esaminare |
| Canali di avviso scelti dal Cliente (e-mail, webhook, Slack, Discord, Microsoft Teams, Google Chat, Telegram) | Evento, dominio, link; per la verifica di autenticità, il dominio del mittente se non appartiene al sito web | P4, P6 | destinazione scelta dal Cliente; in parte al di fuori dell’UE. Inviamo i messaggi Telegram tramite il nostro bot; il relativo meccanismo di trasferimento è una questione aperta per la verifica legale |
| Tutti i siti web collegati | Elenco dei domini di link | P7 | tramite la risposta al plugin |
| Seconda sonda | Dominio, indirizzo del modulo, selettore, passaggi | P4 | disattivata |
6.11 Conservazione, misurata, non prevista
La cancellazione avviene per lo più di notte alle 03:00 nel processo di stato (srv/cron_status.php, cfg/fristen_lib.php); le segnalazioni della protezione collettiva e le righe dei potenziali clienti vengono cancellate ogni giorno dalle 04:00, le associazioni della verifica di recapito a ogni recupero; i report anonimi e quelli relativi a potenziali clienti vengono cancellati tramite la loro data di scadenza (cfg/check_lib.php). Gli screenshot vengono cancellati dal disco insieme alla relativa scansione (cfg/fristen_lib.php).
| Dati | Periodo secondo il codice | Riferimento alla fonte | Riscontro |
|---|---|---|---|
| Controllo gratuito, immagini comprese | 30 giorni | cfg/check_lib.php | efficace |
| Controllo di potenziali clienti, immagini comprese | 90 giorni | cfg/akquise_lib.php; srv/cron_status.php (righe dei potenziali clienti) | efficace |
| Controlli di un dominio del Cliente | 13 mesi; l’ultimo viene conservato finché esiste il dominio | cfg/fristen_lib.php | efficace |
| Risultati dei percorsi del browser, immagini oscurate comprese | 13 mesi | cfg/fristen_lib.php | efficace |
| Dati di un dominio cancellato | immediatamente; dati orfani di notte | cfg/fristen_lib.php (fe_domain_loeschen(), fe_fristen_lauf()) | efficace, compresi l’inventario degli script e le modifiche agli script, che oltre a ciò non hanno un proprio periodo di conservazione (vedi Registro delle attività di trattamento) |
| Studio: dati grezzi, immagini comprese | alla pubblicazione | cfg/studie_lib.php | senza pubblicazione, nessun limite di tempo; l’elenco degli host controllati resta senza limite di tempo anche dopo la pubblicazione |
| Controlli interni senza dominio e senza report | nessuno | – | nessuna cancellazione; rilevati: 85 controlli con 369 immagini dal 22 settembre 2026 (R4) |
| Associazioni della verifica di recapito | 180 giorni | cfg/zustellung_lib.php | efficace |
| Risultato della verifica di autenticità relativo al dominio | fino al risultato successivo o alla cancellazione del dominio | cfg/zustellung_lib.php | sovrascritto, non limitato nel tempo |
| Copie di controllo nella casella | fino al successivo recupero riuscito (intervallo di cinque minuti) | cfg/zustellung_lib.php | copie e backup presso il fornitore della casella non verificati |
| Credenziali per la scansione dietro il login | fino alla cancellazione da parte del Cliente o del dominio; nel job al massimo fino al termine dell’esecuzione, residui dopo un’ora | cfg/login_lib.php | efficace; nei backup solo come testo cifrato per un massimo di 14 giorni |
| Segnalazioni nella protezione collettiva | 30 giorni | cfg/swarm_lib.php | efficace |
| Limiti del controllo gratuito (IP, paese, hash della sessione) | 7 giorni | srv/cron_status.php | efficace |
| Note su comportamenti anomali con indirizzo IP | 90 giorni dopo la risoluzione | srv/cron_status.php | note non risolte senza limite di tempo; rilevate: 3 note, tutte risolte |
| Indirizzo IP, paese, browser relativi a un opt-out | 12 mesi; l’esclusione resta | cfg/fristen_lib.php | efficace |
| Backup del database | 14 giorni | cfg/backup_lib.php | efficace; i backup sono attualmente conservati nella stessa ubicazione del database e non sono cifrati separatamente; è prevista una copia cifrata in una seconda ubicazione (R13) |
7. (b) Valutazione della necessità e proporzionalità
Il parametro di riferimento sono le finalità dichiarate: mostrare ai gestori se i loro moduli sono protetti da spam e abusi (da P1 a P5), verificare se le e-mail dei moduli arrivano e appaiono autentiche (P6) e difendersi congiuntamente dallo spam su molti siti web (P7). Queste finalità sono legittime. La questione ai sensi dell’Art. 35(7)(b) è più ristretta: questo trattamento è necessario in questa misura per la finalità, e l’ingerenza è proporzionata al beneficio?
| Componente | Necessario per la finalità? | Proporzionato nella forma realizzata? |
|---|---|---|
| Recupero di poche pagine pubbliche, struttura dei moduli, misure di protezione rilevate | Sì. Senza di essi non c’è alcun riscontro. | Sì. Al massimo otto pagine (più le visualizzazioni di cui alla sezione 6.1), un divieto della home page nel robots.txt viene rispettato, nessun valore dei campi visibili, indirizzi dei destinatari solo come dominio. |
| Screenshot per modulo | Sì, come prova nel report: il gestore vede a quale modulo ci si riferisce. | In larga misura. I campi sono vuoti perché il crawler non digita nulla. L’immagine mostra tuttavia l’area circostante l’elemento del modulo senza oscurare nulla (R3). |
| Screenshot della home page | Non necessario per il riscontro in sé. Serve a riconoscere nel report il sito web controllato. | Solo in misura limitata; ulteriore minimizzazione prevista. Le home page mostrano spesso persone: foto del team, persone di contatto, testimonianze di clienti con nomi. Vedi R3 e sezione 9.3. |
| Lettura dei valori dei campi nascosti (primi 24 caratteri, solo durante il controllo) | Sì: da essi vengono riconosciuti token e timestamp. | Sì. Viene memorizzato solo il risultato del riconoscimento, non il valore, anche dietro il login (R8). |
| Pagina di risposta all’invio di prova (immagine e 300 caratteri di testo) | Sì, come prova di come ha risposto il modulo. | Sì. La risposta si riferisce al nostro messaggio di prova contrassegnato, privo di dati personali. |
| Classificazione da parte del modello linguistico | Utile, non necessaria: senza di essa più moduli restano “sconosciuti”. | Sì. Locale, senza comunicazione a terzi, senza la facoltà di inviare. |
| Invii di prova attivi | Sì. Se una protezione funziona emerge solo quando viene testata. | Sì, con un limite e un contrassegno. Il presupposto – la prova di controllo – non viene tuttavia mai rinnovato (R7). |
| Ricerca di file esposti | Sì per il Cliente, i cui dati dei moduli possono essere esposti lì. | Sì. Solo domini verificati, al massimo 8 KB, contenuto mai memorizzato. |
| Scansione dietro il login | Sì per i moduli dell’area riservata che altrimenti resterebbero non controllati. | In larga misura. Cifratura e cancellazione sono realizzate con cura; il login accetta tuttavia connessioni non cifrate e certificati difettosi (R8). |
| Copia di controllo dei messaggi reali dei visitatori | Non per la prova di recapito. Questa si basa solo sulla copia del nostro test (cfg/zustellung_lib.php). I messaggi reali arrivano insieme perché una copia nascosta nel modulo non distingue tra un test e un messaggio reale. Sono utili per la verifica di autenticità (SPF, DKIM, DMARC) perché mostrano il percorso di invio effettivo. | In parte. Il contenuto non viene memorizzato ma viene letto, e resta presso il fornitore della casella, il cui contratto è ancora in sospeso, fino al recupero (R1, R2). Una soluzione meno invasiva è tecnicamente possibile: con il nostro plugin, la copia nascosta potrebbe essere limitata ai messaggi di prova contrassegnati (sezione 9.3). |
| Memorizzazione del dominio del mittente dei messaggi reali | In parte: mostra se il modulo invia con l’indirizzo del visitatore come mittente (una causa frequente della classificazione come spam). | Con riserva. Per una persona con un proprio dominio, il dominio è un dato personale, e finisce nell’avviso al Cliente e ai suoi canali (R1). |
| Elenco condiviso dei domini di link | Sì. Un link di spam che compare contemporaneamente su molti siti web è un segnale forte di cui un singolo sito web non dispone. | Sì, con soglie minime, eccezioni e quarantena anziché cancellazione. Le reti IP non sarebbero proporzionate senza una nuova valutazione. |
| Dati grezzi dello studio | Fino alla valutazione, sì. | Senza un periodo massimo, no (R4). |
| Report a un link casuale | Sì. Inoltrare il report – ad esempio al fornitore di servizi che gestisce il sito web – è la finalità del controllo gratuito. | Sì. Link casuale a 128 bit, noindex, report gratuito solo come estratto (cfg/check_lib.php, FE_FREE_DETEKTOREN), cancellazione dopo 30 giorni. |
Liceità. Per P1–P3 e P7 ci basiamo sull’Art. 6(1)(f). A favore del bilanciamento: i dati sono pubblici e vengono recuperati come farebbe qualsiasi visitatore; non viene inviato nulla; i dati personali sono incidentali e di scarsa entità; i periodi sono brevi; il gestore può escludere ulteriori controlli da parte del crawler tramite un divieto della home page nel robots.txt e qualsiasi ulteriore controllo tramite la nostra pagina di opt-out, immediatamente e senza prova; il beneficio – un modulo protetto – va anche a vantaggio del gestore e dei suoi visitatori. Contro: il gestore non sa nulla del controllo, il report è destinato a terzi e, nel caso delle ditte individuali, valuta una persona. Riteniamo il bilanciamento sostenibile finché restano in vigore le misure di cui alla sezione 9.1; la conferma legale è in sospeso.
Informazioni agli interessati (Art. 13 e 14). Informiamo i gestori e le persone presenti sulle pagine controllate tramite la pagina del crawler, indicata nell’identificativo di ogni recupero, tramite l’Informativa sulla privacy e tramite la pagina di opt-out. Informare individualmente le persone che compaiono incidentalmente in uno screenshot sarebbe possibile solo se le identificassimo – il che costituirebbe un’ulteriore e più grave ingerenza. In tale misura ci basiamo sull’Art. 14(5)(b). I visitatori i cui messaggi passano attraverso la copia di controllo vengono informati dal Cliente; l’Accordo sul trattamento dei dati lo prescrive, e a tal fine forniamo un blocco di testo.
Minimizzazione dei dati (Art. 5(1)(c)). È visibile in molti punti e fondata nel codice: nessun valore dei campi, indirizzi dei destinatari solo come dominio, identificativi di account negli indirizzi degli script nascosti, nessun contenuto della copia di controllo nel database, nessuno screenshot dietro il login, solo domini nella protezione collettiva. In due punti è possibile e prevista un’ulteriore minimizzazione (sezione 9.3): per lo screenshot della home page senza oscuramento e per il dominio del mittente dei messaggi reali.
Limitazione della conservazione (Art. 5(1)(e)). Dal 27 settembre 2026 il ciclo notturno rispetta i periodi indicati nell’Informativa sulla privacy per i dati dei Clienti ed elimina i dati rimasti senza un dominio associato dal periodo precedente (cfg/fristen_lib.php). Restano aperti due percorsi senza limite di tempo: i controlli interni e gli studi non pubblicati (R4).
Esattezza (Art. 5(1)(d)). Un riscontro può essere errato: un modulo appare non protetto perché la protezione si carica solo dopo un’interazione, oppure il crawler è stato trattato da un firewall diversamente da un visitatore. Per un gestore il cui sito web viene fatto circolare pubblicamente come “Esposto”, si tratta di una questione di reputazione. Il report indica quindi il metodo, mostra le prove e segnala i limiti di un controllo dall’esterno.
Esito sulla proporzionalità: Il controllo di siti web di terzi e propri è, nella forma realizzata, sostanzialmente proporzionato. In tre punti vi è una necessità di miglioramento rimediabile con mezzi ordinari e per la quale sono previste misure (sezione 9.3): gli screenshot della home page, i controlli interni senza limite di tempo e il login non cifrato per la scansione dietro il login. La verifica di recapito è proporzionata per la copia di prova e per la verifica di autenticità; per i messaggi reali dei visitatori lo è solo finché il loro contenuto non viene memorizzato, il percorso tramite il fornitore della casella è garantito contrattualmente e il Cliente informa i propri visitatori. Oggi manca il secondo di questi tre punti.
8. (c) Valutazione dei rischi per i diritti e le libertà degli interessati
Viene valutato il rischio per gli interessati, non per formexposed. La probabilità è valutata come remota, possibile, probabile o concretizzata; “concretizzata” significa che l’evento non è una previsione ma uno stato rilevato. La gravità è valutata come limitata, significativa, grave o molto grave, a seconda di ciò che la persona rischia di perdere: la riservatezza del proprio messaggio, il controllo su un account, la propria reputazione professionale, la possibilità di esercitare un diritto. Il livello risulta da entrambe e descrive lo stato attuale con le misure di cui alla sezione 9.1.
| N. | Rischio | Trattamento | Probabilità | Gravità | Livello |
|---|---|---|---|---|---|
| R1 | Messaggi reali dei visitatori nella copia di controllo, comprese possibili categorie particolari | P6 | Concretizzata una volta attivata | Grave | Elevato |
| R2 | Percorso della copia di controllo tramite il fornitore della casella senza contratto stipulato e con possibile collegamento con paesi terzi | P6 | Probabile finché manca il contratto | Grave | Elevato |
| R3 | Screenshot di siti web di terzi senza oscuramento | P1–P4 | Probabile | Limitata | Medio |
| R4 | Dati dei controlli e screenshot senza percorso di cancellazione | P3, controlli interni | Concretizzata | Significativa | Elevato |
| R5 | Controllo e valutazione pubblica di siti web di terzi all’insaputa del gestore; uso improprio come strumento di ricognizione | P1 | Possibile | Significativa | Medio |
| R6 | Controllo di potenziali clienti come base per contatti non richiesti | P2 | Probabile | Limitata | Medio |
| R7 | La prova di controllo non viene mai rinnovata | P4, P5 | Possibile | Significativa | Medio |
| R8 | Credenziali e contenuti nella scansione dietro il login | P5 | Possibile | Grave | Medio; elevato per account reali |
| R9 | Invii di prova attivi e controllo dei file sul sito web del Cliente | P4 | Remota | Significativa | Basso |
| R10 | Classificazione da parte di un modello linguistico | P1–P4 | Remota | Limitata | Basso |
| R11 | Blocklist condivisa basata sulle segnalazioni di molti siti web | P7 | Possibile | Limitata | Da basso a medio; elevato con reti IP |
| R12 | Report e screenshot a un link pubblico | P1, P2, P4 | Possibile | Limitata | Basso |
| R13 | Debolezze dell’infrastruttura: backup, accesso ai server, server di scansione | tutti | Possibile | Grave | Elevato |
| R14 | Diritti degli interessati per persone che non ci conoscono | P1–P6 | Probabile | Limitata | Basso |
R1 – Messaggi reali dei visitatori nella copia di controllo
Questo è il rischio più grave del servizio, e non deriva da un errore ma dalla progettazione. Una copia nascosta nel modulo non distingue tra il nostro messaggio di prova e il messaggio di un visitatore. Se un Cliente attiva la verifica di recapito, ogni messaggio inviato tramite quel modulo raggiunge la nostra casella di controllo (cfg/zustellung_lib.php). Il recupero carica in memoria gli header e i primi 8 KB del testo per cercare il nostro identificativo di test (cfg/zustellung_lib.php). Per un normale modulo di contatto ciò significa nome, indirizzo e-mail, numero di telefono e il messaggio completo.
Ciò che il visitatore scrive dipende da lui, e il campo invita a contenuti personali: una richiesta di appuntamento con la descrizione dei sintomi a uno studio medico, l’esposizione di una controversia legale a uno studio legale, una candidatura, una richiesta riguardante un figlio a una scuola. I nostri documenti legali affermano che le copie “non dovrebbero contenere categorie particolari di dati personali”. Si tratta di una richiesta al Cliente, non di una misura di protezione: né lui né noi sappiamo in anticipo che cosa scriverà un visitatore.
A ciò si aggiungono due vie collaterali. In primo luogo, la verifica di autenticità memorizza in relazione al dominio il dominio dell’indirizzo del mittente (cfg/zustellung_lib.php). Se il modulo invia con l’indirizzo del visitatore come mittente, si tratta del dominio del visitatore – irrilevante per un grande fornitore di posta, ma un dato personale per una persona con un proprio dominio. Questo dominio compare anche nell’avviso inviato al Cliente e ai canali da lui scelti (cfg/zustellung_lib.php). In secondo luogo, memorizza l’indirizzo del server di posta mittente (cfg/zustellung_lib.php); di norma si tratta del server del sito web, non di quello del visitatore.
Probabilità – concretizzata una volta attivata. La questione non è se arrivino messaggi reali, ma quanti. Rilevato sul sistema di sviluppo, la funzione non è attivata per alcun dominio. Gravità – grave. La riservatezza di un messaggio a un’impresa è importante per molte persone, e per alcuni dei Clienti tipici sono da attendersi dati ai sensi dell’Art. 9. La gravità è attenuata dal fatto che il contenuto non finisce nel database, resta nella casella solo per breve tempo e non viene letto da alcuna persona presso formexposed. Livello – elevato.
R2 – Percorso della copia di controllo tramite il fornitore della casella senza contratto stipulato
Prima che il nostro recupero veda una copia di controllo, questa si trova nella casella presso Namecheap, Inc. (Private Email), Phoenix, Arizona, USA. Vi arriva solo se i record MX del nostro dominio puntano direttamente a questa casella; l’inoltro presso il registrar del dominio Namecheap, Inc. non è una tappa delle copie di controllo (tramite inoltro non raggiungono la casella). Per la tappa che resta, gli aspetti contrattuali sono ancora aperti: il contratto con il fornitore della casella non è stato stipulato, le sue ubicazioni di archiviazione, i suoi sub-responsabili e i suoi periodi di backup non sono stati accertati, e resta aperto se per il suo luogo di trattamento siano necessarie e si applichino una decisione di adeguatezza o clausole contrattuali tipo. Per le nostre e-mail transazionali si tratta di una questione di configurazione contrattuale. Per le copie di controllo è più grave: in questo caso si tratta di dati che riceviamo in qualità di responsabile del trattamento, e ogni fornitore di servizi lungo il percorso è un sub-responsabile del trattamento del quale rispondiamo ai sensi dell’Art. 28(4).
Inoltre, “cancellato dopo il recupero” vale solo per la nostra visione della casella. Se il fornitore conservi le e-mail cancellate nei propri backup o in un cestino, e per quanto tempo, non è stato verificato. Se un recupero si interrompe, le e-mail restano fino al successivo ciclo riuscito (cfg/zustellung_lib.php); se il processo di stato non funziona, restano a tempo indeterminato. Infine, la protezione del recupero stesso è uno dei punti da verificare sul sistema di produzione prima del lancio (sezione 9.3).
Probabilità – probabile finché manca il contratto: ogni copia di controllo segue questo percorso. Gravità – grave, per gli stessi motivi di R1. Livello – elevato. La lista di controllo per la configurazione dell’applicazione segnala la casella mancante come avviso; non esiste un blocco che impedisca la verifica di recapito in assenza di un contratto documentato.
R3 – Screenshot di siti web di terzi senza oscuramento
Il crawler acquisisce uno screenshot dell’area visibile della prima pagina e un’immagine dell’elemento del modulo di ogni modulo visibile (scanner/src/crawl.js). Nel farlo non oscura nulla. Diverso è il caso dei percorsi del browser: lì i campi di input vengono mascherati prima dello screenshot (scanner/src/browser.js). Sono quindi “ripulite” solo le immagini dei percorsi del browser, non quelle del crawler e non l’immagine della pagina di risposta di un controllo attivo.
Poiché il crawler non digita nulla, i campi del modulo sono vuoti. Tuttavia, la home page di una piccola impresa mostra spesso il titolare, il team, testimonianze di clienti con nomi e foto, o una finestra di chat con l’immagine di un dipendente. Tutto ciò è pubblico; lo screenshot ne fa una copia che viene conservata presso di noi, compare nel report e può essere inoltrata con il link.
Probabilità – probabile. Nel set di dati del sistema di sviluppo sono stati rilevati 432 screenshot. Gravità – limitata: il contenuto è già pubblico, e i periodi per i controlli senza account sono brevi. Livello – medio, perché le persone raffigurate non ne sono a conoscenza e l’immagine della home page non è necessaria per il riscontro.
R4 – Dati dei controlli e screenshot senza percorso di cancellazione
Il ciclo notturno cancella i controlli tramite due percorsi: tramite la data di scadenza di un report (cfg/check_lib.php) e tramite il periodo previsto per i controlli di un dominio del Cliente (cfg/fristen_lib.php, solo per i controlli con un dominio). Un controllo che non ha né un report né un dominio sfugge a entrambe le reti. Si tratta dei controlli con livello di attendibilità “interno”: studi e controlli che il fornitore crea dalla riga di comando.
- Gli studi cancellano i propri dati grezzi alla pubblicazione (
cfg/studie_lib.php). Se uno studio non viene mai pubblicato – perché ha troppo pochi siti web con un modulo (cfg/studie_lib.phprifiuta in tal caso la pubblicazione) o perché viene lasciato in sospeso – controlli, moduli, riscontri e screenshot restano senza limite di tempo. - I controlli interni dalla riga di comando non hanno alcun percorso di cancellazione. Rilevati l’11 ottobre 2026: 85 controlli di questo tipo su siti web di terzi con 978 moduli e 369 screenshot, il più vecchio del 22 settembre 2026, nessuno con un report o un dominio.
- Le note su comportamenti anomali nel controllo gratuito contengono l’indirizzo IP e vengono cancellate 90 giorni dopo la loro risoluzione (
srv/cron_status.php). Una nota che non viene mai risolta resta. Rilevate: tre note, tutte risolte.
Probabilità – concretizzata. Gli 85 controlli non sono uno scenario ma dati esistenti. Sul sistema di sviluppo si tratta di controlli di un test sul campo; sul sistema di produzione si applica lo stesso codice. Gravità – significativa: per questi dati non esiste alcun periodo di conservazione. Per quanto riguarda il principio di limitazione della conservazione (Art. 5(1)(e)), si tratta di un punto aperto con una misura prevista (sezione 9.3, priorità “prima”), e riguarda proprio persone che non sanno nulla del controllo. I controlli interni sono descritti nel Registro delle attività di trattamento; l’Informativa sulla privacy non li menziona ancora separatamente (sezione 9.4). Livello – elevato.
R5 – Controllo e valutazione pubblica di siti web di terzi all’insaputa del gestore
Chiunque può far controllare qualsiasi sito web accessibile al pubblico, senza account e senza alcun legame con esso. Il gestore non viene informato. Il risultato è un report che valuta il sito web come “Esposto”, “Parzialmente protetto” o “Protetto” e che chiunque abbia il link può vedere. Per gli interessati sono ipotizzabili due conseguenze. Una ditta individuale riceve pubblicamente una valutazione – anche se solo per i destinatari del link – che può essere un riscontro errato. E il report mostra a uno spammer quale modulo può essere compilato senza ostacoli.
A ciò si contrappone una serie di blocchi (cfg/check_lib.php): al massimo un controllo per dominio ogni sette giorni, dopodiché lo stesso report; limiti per indirizzo IP e sessione; un limite giornaliero per l’intero servizio; nessun controllo di domini molto recenti, tipici degli abusi; una nota e un segnale in caso di comportamenti anomali; robots.txt e opt-out, verificati due volte (cfg/check_lib.php e nel servizio di controllo). Il report gratuito è un estratto: mostra solo i riscontri di base, non le prove di tutti i rilevatori. E non dice nulla che un bot non potrebbe scoprire da solo in pochi secondi – un modulo non protetto è visibile dall’esterno.
Probabilità – possibile. Gravità – significativa per una ditta individuale il cui modulo viene preso di mira dopo un report o la cui valutazione è errata. Livello – medio.
R6 – Controllo di potenziali clienti come base per contatti non richiesti
Nell’interfaccia, il controllo di potenziali clienti è descritto come “apripista per il primo colloquio”. Come l’agenzia utilizzi il breve riscontro spetta all’agenzia; tecnicamente può inviarlo anche a un gestore che non lo ha richiesto. Noi non contattiamo nessuno (cfg/akquise_lib.php), e le Condizioni di servizio obbligano l’agenzia a rispettare le norme in materia di pubblicità e sollecitazione commerciale. Un’e-mail non richiesta con il riscontro costituisce tuttavia marketing diretto anche tra imprese, che in Polonia (Art. 398 della legge sulle comunicazioni elettroniche (Prawo komunikacji elektronicznej, PKE)) e in Germania (§ 7(2) della legge tedesca contro la concorrenza sleale (Gesetz gegen den unlauteren Wettbewerb, UWG)) richiede il consenso preventivo. L’interfaccia non lo segnala; i testi del controllo di potenziali clienti parlano solo di “passivo” e di “elenco di opt-out”.
Probabilità – probabile, perché la funzione serve all’acquisizione di clienti e non possiamo verificare se il destinatario abbia prestato il consenso. Gravità – limitata: per il gestore si tratta di un fastidioso messaggio di marketing con una valutazione del proprio sito web. Livello – medio. Il rischio risiede nella condotta dell’agenzia; poiché la funzione proviene da noi, è prevista un’avvertenza nell’interfaccia (sezione 9.3).
R7 – La prova di controllo non viene mai rinnovata
Gli invii di prova attivi, la ricerca di file esposti e la scansione dietro il login richiedono che il Cliente abbia dimostrato di avere diritto al controllo del dominio. Questa prova viene verificata una sola volta (cfg/verify_lib.php) e mai più. Nel codice non esiste alcun percorso attraverso il quale un dominio perda la propria prova. Se il dominio cambia proprietario, un’agenzia termina il proprio incarico o il gestore rimuove il record DNS, i controlli proseguono – fino a una volta al giorno, con fino a cinque invii di prova e, se memorizzato, con il login di un account di prova di cui il nuovo gestore potrebbe non essere a conoscenza. Non è invece possibile trasferire la prova a un altro host tramite ridenominazione: il nome host di un dominio con prova di controllo non può essere modificato.
Probabilità – possibile: i cambi di dominio e di incarico sono all’ordine del giorno per le agenzie. Gravità – significativa per il nuovo gestore e i suoi dipendenti, che ricevono messaggi di prova contrassegnati e il cui sito web viene sottoposto alla ricerca di file esposti senza il loro consenso. Livello – medio. I messaggi di prova si spiegano da sé e rimandano alla pagina del crawler e all’opt-out; l’opt-out funziona anche contro i controlli dei Clienti.
R8 – Credenziali e contenuti nella scansione dietro il login
La cifratura delle credenziali è realizzata con cura: dopo la memorizzazione il server web non può più leggerle, il database e il backup contengono solo testo cifrato, il record è vincolato al proprio dominio, le credenziali entrano nel container solo tramite lo standard input e vengono poi cancellate dalla memoria (sezione 6.5). Restano due lacune; un terzo punto riguarda solo la lettura, non la memorizzazione.
- Il login non cifrato è consentito. La verifica dell’indirizzo ammette
httpoltre ahttps(cfg/login_lib.php,scanner/src/login.js). Se il Cliente inserisce una pagina di login conhttp, nome utente e password viaggiano in chiaro su internet a ogni controllo. - Gli errori di certificato non interrompono il login. Attualmente il login non si interrompe se il certificato del sito del Cliente non è valido (
scanner/src/login.js). Il certificato non protegge quindi pienamente le credenziali nel percorso verso il sito del Cliente. È prevista l’interruzione in caso di errori di certificato (sezione 9.3, priorità “prima”). - I valori dei campi nascosti dietro il login vengono letti, non memorizzati. Il crawler legge i primi 24 caratteri del valore dei campi nascosti (
scanner/src/crawl.js), e la stessa funzione di estrazione viene eseguita dietro il login (scanner/src/login.js). Lì i campi nascosti contengono spesso un numero di cliente, un identificativo utente o l’indirizzo e-mail dell’account che ha effettuato l’accesso; nella mappa dei campi e nei riscontri finiscono tuttavia solo il nome del campo, il tipo, l’etichetta e il risultato del riconoscimento.
A ciò si aggiunge ciò che il codice non può impedire: il Cliente conferma di utilizzare un account di prova con il minor numero possibile di diritti (cfg/login_lib.php), ma può inserire un account amministratore reale. Le pagine che lo scanner legge in tal caso sono determinate dal Cliente; gli indirizzi contenenti parole relative a disconnessione e cancellazione sono bloccati, ma non altre azioni che un sito web attiva tramite una semplice richiesta.
Probabilità – possibile. Gravità – grave se è coinvolto un account con ampi diritti; l’area riservata con i dati di tutti gli utenti è allora aperta. Livello – medio per un account di prova con pochi diritti, elevato per un account reale. Rilevato sul sistema di sviluppo, non è memorizzato alcun account di prova.
R9 – Invii di prova attivi e controllo dei file sul sito web del Cliente
Un invio di prova raggiunge le persone che leggono le e-mail dei moduli del Cliente – i suoi dipendenti o un fornitore di servizi. Non contiene dati personali: il mittente è dummy@formexposed.com, testo e oggetto sono contrassegnati e indicano l’identificativo del controllo (scanner/src/active.js). Il rischio risiede in una classificazione errata: se lo scanner scambiasse un modulo di candidatura, di prenotazione o di consulenza per un modulo di contatto, il messaggio di prova finirebbe in un processo che ha conseguenze. A ciò si contrappongono le regole rigorose per “inviabile” (scanner/src/classify.js), il blocco per i domini di autorità pubbliche, istituti di istruzione, cliniche, studi medici, polizia e tribunali (scanner/src/classify.js) e l’esclusione del modello linguistico da questa decisione (scanner/src/classify.js). Dalla risposta vengono memorizzati lo stato, l’indirizzo di destinazione, il titolo, 300 caratteri di testo e un’immagine; si riferiscono al nostro messaggio di prova.
Il controllo dei file legge al massimo 8 KB da percorsi tipici. Se lì è effettivamente esposto un dump del database, questi 8 KB possono contenere dati inseriti nei moduli dai visitatori. Vengono solo verificati alla ricerca di una firma e scartati (cfg/dateien_lib.php); vengono memorizzati percorso, tipo e gravità.
Probabilità – remota. Gravità – significativa. Livello – basso. Rilevato sul sistema di sviluppo, nel set di dati c’è un controllo attivo, senza alcun invio accettato.
R10 – Classificazione da parte di un modello linguistico
Per i moduli che le regole non riconoscono, il modello linguistico riceve il titolo della pagina, l’indirizzo, i testi dei pulsanti, le descrizioni dei campi e fino a 400 caratteri di testo del modulo (scanner/src/classify.js). Tra questi può esserci un nome, ad esempio “La Sua persona di contatto: …”. Funziona sul nostro server; nel codice nulla viene inviato a terzi. Non è stato verificato se il software del modello registri le richieste. Il suo risultato determina solo il tipo di modulo visualizzato e non può rendere un modulo inviabile; una classificazione errata porta a un riscontro peggiore, non a un’azione.
Probabilità – remota. Gravità – limitata. Livello – basso.
R11 – Blocklist condivisa basata sulle segnalazioni di molti siti web
Un dominio presente nell’elenco fa sì che i messaggi con link a esso finiscano in quarantena su tutti i siti web collegati. Se il dominio appartiene a una persona – un artigiano, un fotografo, un blog – i suoi messaggi contenenti un link al proprio sito web raggiungono i destinatari in ritardo. Un tale dominio può finire nell’elenco perché gli spammer ne fanno un uso improprio, o perché qualcuno invia deliberatamente a più siti web messaggi destinati a essere bloccati che lo contengono.
A ciò si contrappongono (cfg/swarm_lib.php): un minimo di tre siti web diversi e cinque occorrenze nell’arco di sette giorni; eccezioni fisse per i grandi servizi; mai i domini dei nostri Clienti; rimozione manuale tramite uno strumento sul server; quarantena anziché cancellazione; l’elenco viene ricostruito ogni giorno, e ciò che non viene più segnalato viene escluso. Gli interessati non possono vedere l’elenco e non dispongono di una via propria per chiederne la rimozione, se non tramite noi.
Probabilità – possibile. Gravità – limitata, perché nulla va perso e il destinatario può sbloccare il messaggio. Livello – da basso a medio. Con le reti IP attivate sarebbero interessate le reti di interi provider, gli indirizzi IP sono dati personali e la gravità salirebbe a significativa: elevato.
R12 – Report e screenshot a un link pubblico
I report del controllo gratuito, del controllo di potenziali clienti e dei controlli dei domini dei Clienti sono accessibili senza login a un link casuale. Il link contiene 128 bit di casualità e non può essere indovinato (cfg/check_lib.php). Le pagine recano noindex, l’applicazione invia una referrer policy che trasmette solo l’origine (www/.htaccess), e gli screenshot vengono forniti solo insieme al report a cui appartengono; un altro numero di immagine restituisce “non trovato” (www/shot.php). Il rischio non è crittografico ma umano: un link viene inoltrato, copiato in un ticket, condiviso in una chat. Chi lo apre viene registrato solo nel registro degli accessi alle pagine come qualsiasi visualizzazione di pagina (60 giorni), in cui il link stesso compare solo in forma mascherata; non esiste un elenco dei lettori per report.
Probabilità – possibile. Gravità – limitata, perché il report mostra solo informazioni pubbliche e scade rispettivamente dopo 30 o 90 giorni; i report sui domini dei Clienti restano accessibili finché esiste il controllo (13 mesi, l’ultimo più a lungo). Livello – basso.
R13 – Debolezze dell’infrastruttura
I punti seguenti sono elencati come aperti nel nostro dossier di revisione interno e non vengono minimizzati qui. Li descriviamo con la precisione di cui i Clienti hanno bisogno per la propria valutazione, ma non in modo così preciso da indicare la strada a un attaccante; forniremo i dettagli a un’autorità di controllo su richiesta.
- I backup del database sono attualmente conservati nella stessa ubicazione del database e non sono cifrati separatamente; è prevista una copia cifrata in una seconda ubicazione (
cfg/backup_lib.php). Fino ad allora non proteggono dalla perdita dell’ubicazione, e chi ottiene il database ottiene anche i backup. Le credenziali per la scansione dietro il login vi sono contenute solo come testo cifrato. - Nessuna cifratura del database a riposo. Fanno eccezione i campi cifrati singolarmente (credenziali degli account di prova, segreto del secondo fattore).
- Le connessioni all’interno della nostra rete interna non sono cifrate in modo uniforme.
- Amministrazione dei server. La sicurezza dell’accesso amministrativo ai nostri server non raggiunge ancora lo standard che intendiamo garantire per l’esercizio; il rafforzamento dell’amministrazione dei server prosegue.
- Ambiente di controllo. Il server di scansione apre siti web di terzi in un browser. I container di controllo sono isolati – rete propria, nessun privilegio particolare, sola lettura, limitati (
scanner/src/worker.js). La separazione tra l’ambiente di controllo e le altre parti del servizio viene ulteriormente rafforzata (sezione 9.3).
Probabilità – possibile. Gravità – grave, perché in caso di emergenza tutto verrebbe colpito contemporaneamente. Livello – elevato. I singoli punti possono essere risolti con mezzi ordinari (sezione 9.3).
R14 – Diritti degli interessati per persone che non ci conoscono
Chi compare incidentalmente in uno screenshot o il cui messaggio è passato attraverso una copia di controllo di solito non sa che esistiamo. Anche se lo sa, non dispone di una chiave per i “propri” dati: non li memorizziamo per persona, ma per dominio e controllo. Possiamo rispondere a una richiesta di accesso ai sensi dell’Art. 15 solo se la persona indica il dominio; possiamo allora esaminare i controlli e le immagini esistenti. Per i messaggi reali dei visitatori non c’è nulla da comunicare, perché non li memorizziamo – a eccezione del dominio del mittente di cui a R1. L’opt-out funziona solo per i gestori di un dominio, non per le persone raffigurate; per loro resta la via tramite contact@lukaswojcik.com.
Probabilità – probabile come situazione strutturale. Gravità – limitata, perché i dati hanno vita breve e non sono organizzati per persona. Livello – basso.
9. (d) Misure previste per affrontare i rischi
Ogni misura reca uno stato, e gli stati non sono decorativi. Attuata oggi – verificata significa: letta nel codice del sistema di sviluppo e, ove possibile, rilevata rispetto al database. Parziale significa: il meccanismo esiste ma non raggiunge ancora pienamente il suo scopo. Prevista significa: proposta dalla presente valutazione e non realizzata; se e quando lo decide il titolare. Ancora da definire sono procedure e decisioni che nessun codice può sostituire. Una DPIA che presenta misure previste come attuate perde il suo valore proprio nella situazione in cui è necessaria.
9.1 Attuate oggi – verificate
| Misura | Rischio affrontato | Riferimento alla fonte |
|---|---|---|
| Il crawler legge il robots.txt prima di ogni controllo; un’esclusione che riguarda la home page, un robots.txt irraggiungibile o un errore del server pongono fine al controllo (i sottopercorsi non vengono rispettati singolarmente; polso, recupero della prova, strumento per gli header e ricerca di file non lo leggono) | R5, liceità | scanner/src/net.js |
| Opt-out senza prova, con effetto immediato, per il dominio e la sua variante www, per controlli anonimi, potenziali clienti, studi e controlli dei Clienti (il monitoraggio in corso termina con il successivo controllo programmato); verificato due volte (applicazione e servizio di controllo); revocato solo da noi su richiesta e con prova | R5, R7, Art. 21 | cfg/check_lib.php; cfg/akquise_lib.php; cfg/studie_lib.php; scanner/src/worker.js |
| Controllo gratuito: arresto di emergenza, reCAPTCHA, un controllo per dominio e settimana, limiti per indirizzo IP e sessione, limite giornaliero, nessun dominio nuovo, solo indirizzi pubblici, nota e segnale senza contenuto in caso di anomalie | R5 | cfg/check_lib.php |
| Per i limiti, la sessione viene memorizzata solo come valore hash, mai l’identificativo di sessione | Minimizzazione | cfg/check_lib.php |
| Nessun valore dei campi (l’inizio dei campi nascosti e degli attributi data viene solo letto durante il controllo, sezione 6.2); indirizzi dei destinatari solo come dominio; identificativi di account negli indirizzi degli script nascosti | Minimizzazione | scanner/src/crawl.js |
| Il report gratuito è un estratto: solo riscontri di base, nessuna prova da tutti i rilevatori | R5 | cfg/check_lib.php, FE_FREE_DETEKTOREN |
Report a un link casuale a 128 bit, noindex, immagini solo per il proprio report, al di fuori della directory web pubblica; il link compare nel registro degli accessi alle pagine solo in forma mascherata | R12 | cfg/check_lib.php; www/report.php; www/shot.php |
| Cancellazione: report anonimi dopo 30 giorni, potenziali clienti dopo 90 giorni, controlli dei Clienti dopo 13 mesi (l’ultimo per dominio viene conservato finché esiste il dominio), i dati di un dominio cancellato immediatamente (per le eccezioni vedi sezione 6.11), le immagini in ogni caso insieme a essi | Limitazione della conservazione | cfg/check_lib.php; cfg/fristen_lib.php |
| Studio: pubblicazione solo come totale, segmenti solo a partire da 20 siti web con un modulo, dati grezzi cancellati alla pubblicazione | R4 in parte, P3 | cfg/studie_lib.php |
| Container di controllo: propria rete isolata, nessun privilegio particolare, sola lettura, limiti di memoria e di processi, limite di tempo; filtro contro destinazioni private per ogni richiesta, service worker bloccati e connessioni WebSocket chiuse affinché nulla aggiri il filtro; richieste del server web solo sulle porte web e solo esattamente all’indirizzo pubblico verificato in precedenza | R13 | scanner/src/worker.js; scanner/src/net.js |
| Controllo attivo per i Clienti solo per un dominio verificato (internamente anche per i nostri domini di test e demo) e con l’arresto di emergenza attivato, verificato due volte; al massimo cinque invii; solo moduli di contatto chiaramente riconosciuti senza dati personali obbligatori; nessun dominio di autorità pubbliche, istituti di istruzione, cliniche, studi medici, polizia o tribunali; il modello linguistico non può sbloccare nulla; messaggio di prova senza dati personali, contrassegnato, con rimando alla pagina del crawler e all’opt-out | R9 | scanner/src/worker.js; scanner/src/classify.js; scanner/src/active.js |
| Percorsi del browser: solo GET e HEAD, indirizzi pericolosi bloccati, i valori fittizi non lasciano il browser, immagini con campi di input oscurati | R3 (per queste immagini), R9 | scanner/src/browser.js |
| Controllo dei file: solo domini verificati, un recupero per percorso, al massimo 8 KB, contenuto mai memorizzato | R9 | cfg/dateien_lib.php |
| Seconda sonda: disattivata per impostazione predefinita; riceverebbe solo un elenco fisso di elementi innocui, firmato | Destinatari | cfg/formular_probe_lib.php |
| Scansione dietro il login: solo dominio verificato, piano a pagamento, proprietario o amministratore, conferma “account di prova”; cifratura con la chiave pubblica del server di scansione, vincolata al dominio; credenziali mai visualizzate, registrate o restituite tramite l’API; trasmissione solo tramite lo standard input; campo nel job svuotato immediatamente, residui dopo un’ora; nessuno screenshot, nessun invio, nessun indirizzo di disconnessione o cancellazione, interruzione in presenza di CAPTCHA; cancellazione definitiva con sovrascrittura | R8 | cfg/login_lib.php; scanner/src/login.js; scanner/src/geheim.js; scanner/src/worker.js |
| Verifica di recapito: disattivata per impostazione predefinita; il recupero legge solo gli header e 8 KB, senza contrassegno di lettura; contenuto e indirizzo del visitatore mai nel database; ogni e-mail recuperata viene cancellata, comprese quelle non associabili; associazioni cancellate dopo 180 giorni; prova solo tramite la copia esattamente di questo test | R1, R2 | cfg/zustellung_lib.php |
| Protezione collettiva: solo domini, reti IP disattivate; soglie minime; eccezioni per i grandi servizi e i domini dei Clienti; quarantena anziché cancellazione; elenco ricostruito ogni giorno; segnalazioni cancellate dopo 30 giorni | R11 | cfg/swarm_lib.php |
| Modello linguistico sul nostro server, senza la facoltà di inviare | R10 | scanner/src/classify.js |
| I segnali tramite Telegram contengono solo una frase fissa senza variabili | Destinatari | cfg/check_lib.php |
| Test di ripristino settimanale del backup, con allarme in caso di errore | Disponibilità | cfg/backup_lib.php; srv/cron_status.php |
9.2 Parziali – presenti, ma non ancora in grado di raggiungere il loro scopo
| Misura | Perché non è ancora pienamente efficace |
|---|---|
| Screenshot “ripuliti” | Sono oscurate solo le immagini dei percorsi del browser. Le immagini del crawler – home page ed elementi dei moduli – e l’immagine della pagina di risposta di un controllo attivo non lo sono (R3). |
| Periodi per i dati dei controlli | Efficaci per i controlli anonimi, di potenziali clienti e dei Clienti; non per i controlli interni e gli studi non pubblicati; note sulle anomalie non risolte senza limite di tempo (R4). |
| Cancellazione delle copie di controllo | Efficace nella nostra visione della casella. Se il ciclo si interrompe, le e-mail restano; ciò che il fornitore della casella conserva nei propri backup non è stato verificato (R2). |
| Protezione delle credenziali nella scansione dietro il login | Solida a riposo e nel servizio di controllo; non nel percorso verso il sito web: http è consentito, gli errori di certificato vengono ignorati (R8). |
| Prova di controllo | Viene verificata una sola volta e poi vale per sempre; il nome host di un dominio con prova di controllo non può tuttavia essere modificato, affinché la prova non passi a un altro host (R7). |
| Informazioni agli interessati | Presenti per i gestori tramite la pagina del crawler, l’identificativo, l’Informativa sulla privacy e l’opt-out; per i visitatori nella verifica di recapito, dipendenti dall’adozione del blocco di testo da parte del Cliente; l’applicazione non lo verifica. |
| Richiesta ai Clienti di non far confluire categorie particolari nella copia di controllo | Indicata nei documenti legali, ma non supportata tecnicamente: durante la configurazione l’applicazione non chiede il tipo di sito web e non avverte in caso di domini che sembrano riguardare salute, diritto o istruzione (R1). |
9.3 Previste – non attuate
| Misura | Rischio affrontato | Priorità |
|---|---|---|
| Percorso di cancellazione per i controlli interni: cancellare i controlli senza dominio e senza report dopo un periodo fisso (proposta: 30 giorni); cancellare i dati grezzi di uno studio al più tardi un periodo fisso dopo la sua conclusione, anche senza pubblicazione (proposta: 90 giorni); cancellare una tantum gli 85 controlli esistenti con 369 immagini | R4 | Prima |
| Abilitare la verifica di recapito solo dopo che il contratto con il fornitore della casella è stato stipulato, le ubicazioni di archiviazione, i sub-responsabili e i periodi di backup sono stati documentati, il meccanismo di trasferimento per il fornitore della casella è stato chiarito e i record MX del nostro dominio puntano direttamente alla casella; fino ad allora, mantenere la funzione bloccata nel sistema di produzione | R2 | Prima |
| Verificare e documentare la sicurezza del recupero della casella sul sistema di produzione prima che la verifica di recapito venga abilitata | R2 | Prima |
Scansione dietro il login solo tramite https e con un certificato valido; rifiutare gli indirizzi http; errori di certificato al login come motivo di interruzione | R8 | Prima |
| Non memorizzare i valori dei campi nascosti dietro il login (solo nome, tipo e lunghezza) – già attuato in questo modo, nessun ulteriore passaggio | R8 | Completata |
| Limitare la copia di controllo ai messaggi di prova dove è in uso il plugin o l’estensione: copia nascosta solo per gli invii con il nostro identificativo di test | R1 | Alta |
| Non memorizzare il dominio del mittente dei messaggi reali né riportarlo negli avvisi se non è né il dominio del sito web né quello di un servizio di invio noto; nell’avviso, invece, “dominio del mittente estraneo” | R1 | Alta |
| Avviso durante la configurazione della verifica di recapito per domini che sembrano riguardare salute, diritto, servizi sociali o istruzione, con rimando alla DPIA del Cliente | R1 | Alta |
| Rinnovare regolarmente la prova di controllo (proposta: prima di ogni controllo attivo, verificare se il record DNS, il meta tag, il file o il collegamento del plugin esistono ancora; altrimenti proseguire in modo passivo e informare il Cliente) | R7 | Alta |
| Smettere di fotografare la home page, o farlo solo con immagini e volti oscurati; limitare le immagini dei moduli all’elemento del modulo (come oggi) e mascherare i campi di input come per i percorsi del browser | R3 | Alta |
| Avvertenza nell’interfaccia del controllo di potenziali clienti: inviare il breve riscontro senza richiesta via e-mail o telefono costituisce marketing diretto anche tra imprese e richiede il consenso preventivo (Art. 398 della legge polacca sulle comunicazioni elettroniche; in Germania § 7(2) UWG, sebbene per le chiamate alle imprese sia sufficiente il consenso presunto) | R6 | Alta |
| Infrastruttura: completare il rafforzamento dell’amministrazione dei server; copia cifrata del backup in una seconda ubicazione; cifrare in modo uniforme le connessioni nella rete interna; rafforzare ulteriormente la separazione tra il server di scansione e l’applicazione | R13 | Alta |
| Periodo per le note sulle anomalie non risolte (proposta: risoluzione entro 30 giorni, altrimenti cancellazione dell’indirizzo IP) | R4 | Media |
| Una pagina o un modulo tramite cui chiunque possa richiedere la rimozione di un dominio dalla protezione collettiva | R11, R14 | Media |
| Prima di attivare le reti IP nella protezione collettiva: una nuova versione della presente valutazione | R11 | Condizione |
| Accertare se il software del modello linguistico memorizzi le richieste e, in caso affermativo, disattivare tali log | R10 | Bassa |
9.4 Procedure e decisioni ancora da definire
Oltre alle garanzie tecniche, l’Art. 35(7)(d) richiede anche procedure. Queste sono ancora in sospeso:
- Violazione dei dati personali. Rilevazione: il titolare, l’allarme errori dell’applicazione, segnalazioni tramite il punto di segnalazione delle vulnerabilità o contact@lukaswojcik.com. Decisione sulla notifica all’UODO entro 72 ore (Art. 33(1)): il titolare. Informazione ai Clienti interessati in qualità di titolari del trattamento: senza ingiustificato ritardo, se possibile entro 48 ore, come promesso nell’Accordo sul trattamento dei dati. Da definire: una descrizione scritta della procedura e una prima esercitazione; per la verifica di recapito, inoltre, come accertare quali Clienti sono interessati da una violazione presso il fornitore della casella.
- Settori. Da definire: se la verifica di recapito venga offerta, offerta con un avviso o esclusa per i siti web dei settori sanità, diritto, servizi sociali e istruzione.
- Controlli interni. Da definire: per che cosa il fornitore utilizza i controlli interni dalla riga di comando, chi può crearli e per quanto tempo restano i loro risultati; e se, oltre che nel Registro delle attività di trattamento, debbano essere menzionati nell’Informativa sulla privacy.
- Studi. Da definire: chi compila gli elenchi, da quali fonti, con quale dimensione massima, e una verifica prima di ogni studio per accertare se rispetta i presupposti della presente valutazione.
- Opinioni degli interessati (Art. 35(9)). Per questa versione non sono state raccolte. L’Art. 35(9) ne richiede la raccolta solo “se del caso”; a nostro giudizio, attualmente non è questo il caso. I gestori dei siti web controllati e i visitatori dei siti web dei Clienti non dispongono di un canale proprio verso di noi; rivolgersi specificamente a loro costituirebbe di per sé un nuovo trattamento dei loro dati, e il servizio non è ancora stato lanciato, per cui non esiste ancora una cerchia di interessati effettivi. I loro interessi vengono considerati indirettamente: tramite robots.txt e opt-out, tramite i periodi brevi e tramite il fatto che il contenuto delle copie di controllo non viene memorizzato. A ogni riesame ai sensi della sezione 12 valutiamo nuovamente se sia opportuno raccogliere le loro opinioni, ad esempio tramite feedback sulla pagina del crawler o dai Clienti della verifica di recapito.
10. Rischio residuo e consultazione preventiva ai sensi dell’Art. 36
L’Art. 36(1) richiede la consultazione preventiva dell’autorità di controllo qualora la DPIA indichi che il trattamento presenterebbe un rischio elevato in assenza di misure adottate dal titolare del trattamento per attenuare il rischio. La questione non è quindi se siano stati individuati rischi elevati – ne sono stati individuati quattro – ma se un rischio elevato permanga una volta adottate le misure.
Per i trattamenti di cui formexposed è titolare del trattamento (da P1 a P4, P7), i rischi elevati R4 e R13 possono essere risolti con mezzi ordinari: un percorso di cancellazione e una pulizia dei dati esistenti, un backup cifrato in un’altra sede e il rafforzamento di due server. Con le misure di cui alla sezione 9.3 scendono a un livello da basso a medio. R3, R5, R6 e R7 sono a livello medio e scendono a basso con le misure proposte. La protezione collettiva senza reti IP resta a un livello da basso a medio. La consultazione preventiva non è necessaria per questa parte se le misure contrassegnate come “prima” e “alta” vengono attuate prima del lancio. Se una di queste misure non è stata attuata prima del lancio, per il trattamento in questione permane un rischio elevato. Tale trattamento verrà allora avviato solo una volta attuata la misura, oppure l’UODO verrà prima consultato ai sensi dell’Art. 36(1).
Per la verifica di recapito (P6) la situazione è diversa, per un motivo che nessuna misura elimina del tutto: ciò che un visitatore scrive dipende da lui. Con un contratto stipulato, un recupero protetto, la limitazione ai messaggi di prova ove possibile e la rinuncia al dominio del mittente, R2 scende a basso e R1 a medio. Per i Clienti i cui visitatori forniscono tipicamente dati ai sensi dell’Art. 9, R1 può tuttavia restare elevato. L’obbligo di consultazione spetta allora al Cliente in qualità di titolare del trattamento, non a formexposed. A tali Clienti raccomandiamo di non configurare la copia di controllo per il modulo di contatto generale, ma solo per moduli senza contenuti sensibili, oppure di rinunciare alla verifica di recapito.
Rischio residuo, dichiarato onestamente. Oggi, con le misure di cui alla sezione 9.1, quattro rischi sono a livello elevato: R1 e R2 (verifica di recapito), R4 (dati dei controlli senza percorso di cancellazione) e R13 (infrastruttura). Con le misure di cui alla sezione 9.3, R2, R4 e R13 scendono a un livello da basso a medio. R1 resta a livello medio e dipende in modo permanente dalle decisioni dei Clienti. Nessuno degli altri rischi supera il livello medio dopo le misure.
L’Art. 36 non è una sanzione, e consultare non è un’ammissione. È la via che il Regolamento prevede per la situazione in cui una procedura utile comporta un rischio che il titolare del trattamento non controlla pienamente. Un Cliente che intende utilizzare la verifica di recapito per messaggi contenenti dati relativi alla salute trova qui i fatti per tale decisione.
11. Di che cosa hanno bisogno i Clienti per la propria DPIA (Art. 28(3)(f))
Per la verifica di recapito e la scansione dietro il login, il titolare del trattamento è il Cliente. Questa pagina gli fornisce la descrizione (sezioni 6.5 e 6.6), i rischi dal nostro punto di vista (R1, R2, R8) e lo stato delle misure (sezione 9). Solo il Cliente può rispondere alle seguenti domande:
- Che cosa scrivono i miei visitatori? È da attendersi che tramite il modulo arrivino dati relativi a salute, religione, origine, appartenenza sindacale, orientamento sessuale, reati o riguardanti minori? In tal caso una DPIA per la copia di controllo è di norma necessaria, e la copia di controllo per questo modulo andrebbe riconsiderata.
- Ho bisogno della copia di controllo per tutti i messaggi? Per dimostrare che il nostro messaggio di prova arriva, è sufficiente per quel messaggio. Se il modulo lo consente, imposti la copia nascosta solo per i messaggi di prova.
- Come informo i miei visitatori? L’Accordo sul trattamento dei dati lo prescrive; il Testo per l’informativa sulla privacy del Suo sito web descrive il percorso della copia e il nostro ruolo.
- Di quale base giuridica dispongo? Il nostro testo suggerito indica l’Art. 6(1)(f) (ricezione affidabile delle richieste). Per i dati ai sensi dell’Art. 9, questa base da sola non è sufficiente.
- Quali canali di avviso scelgo? Gli avvisi della verifica di autenticità possono indicare il dominio del mittente. Chi invia avvisi a servizi di chat al di fuori dell’UE lo trasferisce lì.
- Per la scansione dietro il login: L’account di prova è davvero un account di prova con i diritti minimi necessari? La pagina di login è raggiungibile solo tramite
https? L’account di prova vede dati di altri utenti? Se sì: su quali delle pagine indicate? - Quando cancello? La verifica di recapito e l’account di prova possono essere disattivati e cancellati in qualsiasi momento; l’account di prova viene allora sovrascritto in modo permanente.
Ulteriori documenti per la valutazione del Cliente: l’Accordo sul trattamento dei dati, le misure tecniche e organizzative, l’elenco dei sub-responsabili del trattamento e il Registro delle attività di trattamento. Rispondiamo a domande su singoli fatti all’indirizzo contact@lukaswojcik.com.
12. Riesame, versione e approvazione
L’Art. 35(11) richiede un riesame per valutare se il trattamento sia effettuato conformemente alla DPIA, almeno quando insorgono variazioni del rischio. Riesaminiamo la presente valutazione almeno una volta all’anno e inoltre prima di ciascuno dei seguenti eventi; ciascuno di essi comporta una nuova rilevazione, non solo una rilettura:
- avvio dell’esercizio in produzione, con dati del sistema di produzione anziché del sistema di sviluppo;
- prima attivazione della verifica di recapito sul sistema di produzione e stipula del contratto con il fornitore della casella;
- attivazione delle reti IP nella protezione collettiva;
- il primo studio, e ogni studio con un elenco più ampio del precedente;
- attivazione della seconda sonda o di un nuovo destinatario nel percorso di controllo;
- qualsiasi nuovo utilizzo del modello linguistico che vada oltre la classificazione dei moduli e “Fix it for me”;
- qualsiasi modifica agli screenshot, ai periodi o ai presupposti per i controlli attivi.
| Voce | Contenuto |
|---|---|
| Titolare del trattamento | LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polonia · NIP 7252266190 · contact@lukaswojcik.com |
| Autorità di controllo competente | Prezes Urzędu Ochrony Danych Osobowych (UODO), ul. Moniuszki 1A, 00-014 Warszawa, Polonia |
| Responsabile della protezione dei dati | Non designato; valutazione ai sensi dell’Art. 37 nella sezione 4 |
| Base dei fatti | Codice sorgente dell’applicazione e del servizio di controllo, schema del database, conteggi delle righe e impostazioni del sistema di sviluppo, rilevati l’11 ottobre 2026, in sola lettura |
| Documenti correlati | Informativa sulla privacy, Accordo sul trattamento dei dati, Misure tecniche e organizzative, Sub-responsabili del trattamento, Registro delle attività di trattamento, Regolamento UE sull’IA, Uso consentito e abusi, FormExposedBot, Opt-out |
| Versione | 1.0 dell’11 ottobre 2026, prima versione |
| Riesami ai sensi dell’Art. 35(11) | Nessuno finora (prima versione). Ogni riesame viene annotato qui con data, motivo ed esito. |
| Approvazione | Non ancora approvata. Approvazione da parte del titolare dopo la verifica legale e dopo una decisione sulle misure di cui alla sezione 9.3 e sulle questioni di cui alla sezione 9.4. Finora non è stata richiesta una consulenza esterna in materia di protezione dei dati. |
Un’ultima osservazione appartiene al documento e non a una lettera di accompagnamento. Le parti di formexposed che si spingono più a fondo nei domini altrui – gli invii di prova e il login con credenziali di terzi – sono realizzate con la massima cautela: due barriere, limiti rigidi, una cifratura che esclude persino noi. I rischi della presente valutazione risiedono per lo più altrove: in ciò che arriva incidentalmente – messaggi reali in una copia nascosta, persone in uno screenshot, controlli che nessuno cancella più. Si tratta di una posizione di partenza favorevole, perché ciò che è incidentale può essere fermato senza modificare il servizio.