Informativa sulla privacy

1. In breve

Tutto ciò che è contenuto nella presente informativa è stato verificato rispetto al codice sorgente dell'applicazione. Per ottenere informazioni al riguardo è possibile rivolgersi a noi tramite i dati di contatto indicati nella sezione 2.

BrickDb è un servizio di ThreeB IT GmbH, privo di inserzioni pubblicitarie. La presente informativa descrive quali dati vengono effettivamente trattati — non ciò che di solito si legge in testi di questo tipo.

• Per la misurazione dell'audience con Google Analytics viene chiesto il consenso dell'utente. Senza di esso la misurazione non ha luogo: non viene caricato alcuno script, non viene impostato alcun identificativo e nulla viene inviato a Google. Maggiori dettagli nella sezione 10.
• Senza il consenso dell'utente, all'apertura di una pagina non viene stabilita alcuna connessione con terzi. Anche i caratteri tipografici risiedono sul nostro server.
• Le fotografie sono visibili soltanto all'utente e ai membri ai quali egli, in una collezione condivisa, ha concesso i dettagli privati; nella pagina pubblica di una collezione non compaiono. Maggiori dettagli nella sezione 8.2. I metadati incorporati — tra cui le coordinate GPS — vengono rimossi durante l'elaborazione.
• Sul dispositivo non viene memorizzato nulla che consenta di riconoscere l'utente prima che questi abbia scelto attivamente un'impostazione, effettuato l'accesso o prestato il consenso. Ciò di cui il browser ha bisogno sul piano puramente tecnico per la sicurezza dei moduli, e ciò che sorregge l'accesso dell'utente, è indicato per intero nella sezione 6.1; ciò che l'app deposita sul dispositivo è indicato nella sezione 6.5. La decisione sulla misurazione dell'audience può essere modificata in qualsiasi momento in fondo a ogni pagina.

2. Titolare del trattamento

Il titolare del trattamento ai sensi dell'articolo 4, punto 7, del GDPR è:

ThreeB IT GmbH
Bergstrang 105
49479 Ibbenbüren
Germania
Telefono: +49 (5451) 893922-0
E-mail: hello@brickdb.net

Rappresentata dagli amministratori (Geschäftsführer) Thimo Buchheister e Thorsten Brügge.

Non è stato designato un responsabile della protezione dei dati.

3. Visita del sito web

Quando si accede a www.brickdb.de o a uno degli ulteriori indirizzi ai quali BrickDb è raggiungibile (www.brickdb.at, www.brickdb.ch, www.brickdb.dk, www.brickdb.nl, www.brickdb.be, www.brickdb.fr, www.brickdb.it, www.brickdb.lu, www.brickdb.es, www.brickdb.co.uk, www.brickdb.us, www.brickdb.com.mx, www.brickdb.eu, www.brickdb.net), il server web tratta i dati che un browser deve trasmettere per ragioni tecniche affinché una pagina possa essere fornita: l'indirizzo IP, la data e l'ora della richiesta, l'indirizzo richiesto, la quantità di dati trasferiti e il codice di stato, l'identificativo del browser e del sistema operativo (user agent) nonché la preferenza linguistica inviata dal browser (Accept-Language).

Questi dati si generano necessariamente a ogni connessione in Internet. Vengono trattati per fornire la pagina, per garantirne il funzionamento tecnico e per respingere gli attacchi.

Della preferenza linguistica viene fatto un ulteriore uso, strettamente limitato: l'indicazione della regione in essa contenuta (ad esempio DE da de-DE) viene letta mentre si risponde alla richiesta, per preselezionare un paese: nell'elenco degli eventi e per i prezzi nelle pagine dei set e delle minifigure, vale a dire quali prezzi dei negozi vengono mostrati, quale negozio Amazon è collegato e in quale valuta sono visualizzati i prezzi. Se l'utente ha effettuato l'accesso e ha indicato un paese nel proprio profilo (sezione 7.2), viene utilizzato invece tale paese. Un paese che l'utente ha scelto e salvato sul sito stesso (sezione 6.1, bd-country) prevale su entrambi. L'indicazione della regione non viene memorizzata, non viene combinata con altri dati e non viene trasmessa; il paese scelto è visibile nella pagina — nell'elenco degli eventi anche nella barra degli indirizzi — e lì può essere annullato con un clic.

Negli indirizzi che sono attribuiti a un paese (ad esempio www.brickdb.de o www.brickdb.fr) il paese risulta dall'indirizzo stesso. Su www.brickdb.net e www.brickdb.eu, che non sono attribuiti a un singolo paese, si aggiunge un ulteriore dato: la rete di distribuzione anteposta al sito (Azure Front Door, un servizio del responsabile del trattamento Microsoft indicato nella sezione 4) ricava lì, al margine della rete, dall'indirizzo IP della richiesta un codice paese di due lettere (ad esempio SE) e lo trasmette all'applicazione. Esso serve allo stesso scopo dell'indicazione della regione: preselezionare un paese per i prezzi e gli eventi. L'applicazione non riceve nient'altro che tale codice, in particolare nessuna posizione più precisa; il codice non viene né memorizzato, né registrato nei log, né combinato con altri dati. Non viene impiegato alcun servizio di geolocalizzazione di terzi; l'indirizzo IP non viene comunicato a tale scopo a nessuno che non lo tratti comunque per fornire la pagina. La base giuridica al riguardo è l'articolo 6, paragrafo 1, lettera f), del GDPR; il legittimo interesse consiste nel mostrare all'utente i prezzi e gli eventi relativi al suo paese senza chiederglielo prima. L'utente può in qualsiasi momento sostituire tale preselezione scegliendo egli stesso un paese sul sito (sezione 6.1, bd-country).

Base giuridica: articolo 6, paragrafo 1, lettera f), del GDPR. Il legittimo interesse consiste nel funzionamento tecnicamente corretto e sicuro del servizio.

Periodo di conservazione: l'applicazione stessa non tiene alcun registro degli accessi. I registri che si generano a livello di infrastruttura vengono conservati soltanto per il tempo necessario alla sicurezza operativa, al massimo per 30 giorni, salvo che siano necessari per chiarire un concreto incidente di sicurezza.

4. Hosting

Il servizio è gestito su Microsoft Azure; il fornitore è Microsoft Ireland Operations Limited, One Microsoft Place, South County Business Park, Leopardstown, Dublin 18, Irlanda. Come luogo del trattamento è stata scelta la regione Azure Germany West Central (Frankfurt am Main); la banca dati e l'archiviazione dei file si trovano pertanto in Germania.

Microsoft è al riguardo responsabile del trattamento ai sensi dell'articolo 28 del GDPR sulla base del Microsoft Products and Services Data Protection Addendum.

Le richieste a BrickDb passano attraverso la rete di distribuzione Azure Front Door di Microsoft. Essa riceve la connessione in una sede vicina all'utente — che può trovarsi fuori dalla Germania e fuori dall'UE e dal SEE — e la inoltra; l'applicazione e tutti i dati memorizzati restano in Germany West Central (Frankfurt am Main). Anche ciò avviene nell'ambito del trattamento per nostro conto, sulla base del Microsoft Products and Services Data Protection Addendum; nella misura in cui ciò comporti un trasferimento verso un paese terzo, vale quanto il paragrafo seguente dice di Microsoft alla voce «Trasferimento verso paesi terzi».

Trasferimento verso paesi terzi: un accesso da paesi terzi non può essere del tutto escluso nell'ambito di operazioni di assistenza e manutenzione. Microsoft fonda tali trasferimenti sulle clausole contrattuali tipo della Commissione europea ed è inoltre certificata nell'ambito dell'EU-US Data Privacy Framework.

5. Caratteri tipografici e contenuti esterni

I caratteri tipografici utilizzati sono forniti dal nostro server. Non vengono caricati caratteri da server di terzi — in particolare non da Google Fonts. Non sono presenti mappe, video, plug-in di social media o altri contenuti incorporati di terzi.

Senza il consenso dell'utente, all'apertura di una pagina non viene stabilita alcuna connessione con terzi e nessun indirizzo IP viene trasmesso a terzi.

L'unica eccezione è la misurazione dell'audience di cui alla sezione 10, ed essa non è una limitazione di tale frase, bensì la sua condizione: lo script di Google viene caricato soltanto dopo che l'utente ha acconsentito nel banner di consenso. Finché l'utente non ha acconsentito o rifiutato, non viene caricato nulla di Google — nemmeno una segnalazione preliminare definita "senza cookie".

6. Memorizzazione sul dispositivo

BrickDb non imposta alcun cookie a fini di marketing o pubblicitari. Viene memorizzato esclusivamente ciò che registra un'impostazione scelta consapevolmente, ciò che la sicurezza dei moduli richiede, ciò che sorregge l'accesso dell'utente quando questi accede — e, se l'utente ha acconsentito alla misurazione dell'audience di cui alla sezione 10, i cookie di analisi ivi descritti. Prima del consenso dell'utente non viene impostato nessuno dei cookie di analisi.

6.1 Che cosa viene memorizzato

Le prime cinque voci contengono esclusivamente l'ultimo valore selezionato. Non contengono alcun numero identificativo né nulla da cui si possa riconoscere una persona o un dispositivo. Tutte e cinque sono memorizzazioni di prima parte; nessun terzo vi ha accesso. Ciascuna di esse vale soltanto per l'indirizzo sul quale è stata impostata: una scelta effettuata su www.brickdb.de non viene letta su www.brickdb.fr. bd-country nasce quando l'utente sceglie e salva un paese, bd-market-hint quando l'utente chiude l'avviso secondo cui per il suo paese esiste un indirizzo proprio — esso fa soltanto in modo che tale avviso non gli venga mostrato di nuovo a ogni apertura di pagina. bd-analytics-consent è inoltre impostato come HttpOnly, perché nessuno script nel browser deve leggerlo: se la misurazione dell'audience sia attiva lo decide il server, prima che la pagina esista.

La sesta voce è impostata dal framework web impiegato su ogni pagina che contiene un modulo — quindi anche sulla pagina in cui si trova il banner di consenso. Protegge tali moduli dall'essere inviati da un sito altrui (cross-site request forgery), non contiene alcun dato sull'utente, è HttpOnly e SameSite=Strict e termina con la sessione. Nel caso del banner di consenso è il motivo per cui nessuno dall'esterno può far registrare un consenso a nome dell'utente.

Le due voci successive nascono soltanto quando l'utente accede. bd.auth mantiene la sessione di accesso dell'utente; il suo contenuto è cifrato, è HttpOnly e Secure e viene inviato soltanto a questo sito (SameSite=Lax). Non si prolunga da sé: la sessione termina con la validità dell'accesso e non soltanto quando l'utente smette di fare clic. Alla disconnessione viene rimosso. I due cookie di handshake sono impostati dal framework soltanto per la durata di una singola procedura di accesso; legano il ritorno dalla pagina di accesso esattamente alla procedura che l'utente ha avviato e vengono poi rimossi.

L'ultima voce è costituita dai cookie di analisi di cui alla sezione 10. Vengono impostati esclusivamente dopo il consenso dell'utente e contengono un identificativo casuale con cui vengono riconosciute le visite ricorrenti dallo stesso browser.

6.2 Perché per tutte le voci, tranne i cookie di analisi, non è necessario alcun consenso

La disposizione determinante è il § 25 della legge tedesca sulla protezione dei dati nelle telecomunicazioni e nei servizi digitali (TDDDG). Essa riguarda ogni memorizzazione di informazioni sul dispositivo terminale e ogni accesso ad esse — quindi non soltanto i cookie, ma espressamente anche il local storage. Ai sensi del § 25, comma 2, n. 2, TDDDG il consenso non è necessario quando la memorizzazione è strettamente necessaria per poter fornire un servizio espressamente richiesto dall'utente.

È questo il caso, e per ragioni che possono essere verificate in base al comportamento dell'applicazione:

• Prima di una scelta attiva non viene memorizzato nulla. La semplice apertura della pagina non scrive alcuna voce. Una voce nasce esclusivamente quando vengono azionati i selettori dell'aspetto o della lingua, quando l'utente sceglie e salva un paese oppure quando chiude l'avviso relativo a un altro indirizzo nazionale.
• Il ritorno all'impostazione predefinita elimina di nuovo la voce. Se viene scelto "Sistema", la voce corrispondente viene rimossa anziché sovrascritta.
• Viene memorizzata esattamente l'impostazione che è stata espressamente richiesta, e nient'altro.
• Per bd-analytics-consent vale lo stesso per una ragione propria: esso registra la decisione che l'utente ha appena preso. Senza di esso la domanda dovrebbe essere posta di nuovo a ogni pagina — anche a chi ha appena rifiutato.
• Il cookie antiforgery è il caso più chiaro dei tre: senza di esso un modulo di questo sito non può più essere protetto da abusi dall'esterno, e ciò riguarda anche il pulsante con cui l'utente acconsente alla misurazione dell'audience o la rifiuta. Non viene memorizzato perché si intende misurare qualcosa, bensì affinché l'immissione che conta sia quella dell'utente stesso.
• Per i tre cookie di accesso ciò vale nel modo più evidente: senza di essi un accesso non può essere né eseguito né mantenuto. Chi accede richiede esattamente il servizio che essi rendono, ed essi nascono soltanto nel momento in cui viene richiesto — chi non accede non ne riceve nessuno.

Un'impostazione che viene ricordata su richiesta espressa è pertanto strettamente necessaria per la prestazione del servizio richiesto; per la sicurezza dei moduli e per l'accesso ciò vale in ogni caso. Per tali voci non viene quindi chiesto alcun consenso.

Opposizione ed eliminazione: le voci relative all'aspetto e alla lingua possono essere rimosse in qualsiasi momento scegliendo di nuovo "Sistema" nel selettore oppure cancellando i dati del browser. Il sito funziona invariato senza di esse; appare allora nell'aspetto e nella lingua stabiliti rispettivamente dal sistema operativo e dal browser. Le voci relative al paese e all'avviso chiuso si rimuovono cancellando i dati del browser; senza di esse il paese viene di nuovo preselezionato come descritto nella sezione 3.

6.3 Cookie di analisi — soltanto dopo il consenso

Ai cookie della misurazione dell'audience il § 25, comma 2, n. 2, TDDDG non si applica: una misurazione dell'audience non è necessaria per il servizio richiesto dall'utente, e il sito funziona completamente senza di essa. Essi ricadono pertanto nel § 25, comma 1, TDDDG e vengono impostati soltanto dopo che l'utente ha acconsentito nel banner di consenso. Il banner compare sulla prima pagina che viene aperta e offre il consenso e il rifiuto come due pulsanti della stessa dimensione, affiancati — l'uno e l'altro richiedono un solo clic.

6.4 Dati di connessione tecnicamente necessari

L'interfaccia utente è generata sul server e durante l'utilizzo mantiene una connessione WebSocket con il server. Il relativo stato della sessione risiede esclusivamente nella memoria di lavoro del server, non viene memorizzato sul dispositivo terminale e termina con la chiusura della pagina.

6.5 Nell'app

L'app BrickDb per dispositivi mobili e computer mostra le stesse pagine, ma non deposita nulla in una memoria del browser. Le impostazioni relative all'aspetto e alla lingua risiedono lì nell'archivio delle impostazioni del sistema operativo e contengono, come nella sezione 6.1, soltanto l'ultimo valore scelto.

Se l'utente accede nell'app, la sua sessione viene depositata nella memoria protetta del dispositivo — nel Portachiavi (Keychain) su iOS e macOS, nella memoria protetta da Keystore su Android. Vengono depositate quattro cose: il token di accesso, il token di aggiornamento, il momento di scadenza e l'indicazione della modalità con cui l'utente ha effettuato l'accesso.

Si aggiunge il token di identità, ed è l'unico di questi elementi che contiene dati relativi alla persona dell'utente. Viene emesso da Auth0 al momento dell'accesso e depositato lì perché l'app vi legge chi ha davanti. Contiene l'identificativo dell'account dell'utente presso il fornitore di identità, il nome e l'indirizzo e-mail dell'utente, l'indicazione se l'indirizzo sia confermato, nonché un valore tecnico monouso proveniente dalla procedura di accesso. Tali dati si trovano pertanto sul dispositivo, anche se ai sensi della sezione 7.1 non vengono acquisiti nella nostra banca dati. Una password non è tra questi, perché l'app non ne accetta alcuna (sezione 7.1).

Tutti e cinque gli elementi vengono rimossi alla disconnessione. Sul dispositivo non viene tenuta alcuna copia della collezione dell'utente, e nessuna modifica viene memorizzata temporaneamente per una trasmissione successiva.

7. Account utente

7.1 Accesso

BrickDb può essere utilizzato senza account: il catalogo, la ricerca e lo scanner sono disponibili senza accesso. Un account è necessario soltanto per tenere una propria collezione.

L'accesso avviene tramite il fornitore di identità Auth0 (Okta, Inc.), mediante un tenant nell'Unione europea. Sono offerte tre modalità: un account con indirizzo e-mail e password, l'accesso con un account Google esistente oppure l'accesso con il proprio Apple Account ("Accedi con Apple"). Quale di esse utilizzare è una scelta dell'utente. Ciò vale allo stesso modo per il sito web e per l'app.

Il modulo di accesso è una pagina di Auth0, non di BrickDb. Una password non viene immessa, accettata o inoltrata in nessuna pagina di BrickDb; anche la modifica della password avviene presso Auth0. Chi accede tramite Google o Apple non ha presso Auth0 alcuna password — le credenziali risiedono allora presso Google o Apple, e nemmeno BrickDb le vede. Con "Accedi con Apple" l'utente può inoltre scegliere di nascondere il proprio indirizzo e-mail: BrickDb riceve allora un indirizzo del servizio di inoltro di Apple (che termina con @privaterelay.appleid.com), tramite il quale Apple inoltra all'utente le nostre e-mail.

Che cosa riceve BrickDb. Dopo un accesso riuscito Auth0 consegna i dati che sono stati richiesti: un identificativo pseudonimo dell'account dell'utente, i dati del profilo registrati con l'accesso e l'indirizzo e-mail dell'utente. Di essi non viene memorizzato nulla, tranne l'identificativo pseudonimo e il momento in cui il record è stato creato — questo è l'intero contenuto del nostro record dell'account. Il nome, il profilo e l'indirizzo e-mail restano presso Auth0 e vengono letti lì quando servono (sezione 7.2); non vengono acquisiti nella nostra banca dati.

L'autenticazione a due fattori è offerta e mai richiesta. Chi lo desidera può registrare un'app di autenticazione (TOTP), una chiave del dispositivo come Face ID, Touch ID o Windows Hello, una chiave di sicurezza hardware e codici di recupero. Senza una tale registrazione a nessuno viene chiesto nulla al riguardo. I codici tramite SMS o tramite e-mail deliberatamente non sono offerti.

Che cosa tratta Auth0 in tale contesto. Auth0 tratta le credenziali di accesso stesse nonché i dati tecnici di ogni procedura di accesso — momento, indirizzo IP nonché identificativo del browser e del dispositivo — per eseguire l'accesso e per riconoscere i tentativi di accesso abusivi. Alla creazione di un account e a ogni modifica della password Auth0 verifica inoltre se la password scelta sia comparsa in una violazione di dati divenuta nota e, in tal caso, la rifiuta. In occasione di un accesso ordinario tale verifica non ha luogo.

Base giuridica: articolo 6, paragrafo 1, lettera b), del GDPR — senza account le funzioni relative alla collezione non possono essere fornite. Per il riconoscimento dei tentativi di accesso abusivi e per la verifica rispetto alle password divenute note, articolo 6, paragrafo 1, lettera f), del GDPR; il legittimo interesse consiste nella sicurezza degli account. Auth0 è al riguardo responsabile del trattamento ai sensi dell'articolo 28 del GDPR.

Trasferimento verso paesi terzi: il tenant si trova nell'Unione europea ed è lì che ha luogo l'accesso. La controparte contrattuale è tuttavia Okta, Inc. (Auth0), con sede negli Stati Uniti, cosicché un accesso da tale paese — ad esempio nell'ambito dell'assistenza e della manutenzione — non può essere escluso. Okta fonda tali trasferimenti sulle clausole contrattuali tipo della Commissione europea, allegate come documenti distinti all'accordo sul trattamento dei dati del 15 dicembre 2023.

Periodo di conservazione: il record dell'account esiste finché l'utente non elimina il proprio account. L'eliminazione nella pagina dell'account elimina anche l'account presso Auth0 e con esso i dati ivi registrati (sezione 14).

7.2 Profilo: nome, testo di presentazione, paese e indirizzo facoltativo

L'utente può registrare un nome, un cognome, un breve testo su di sé, il proprio paese, uno dei nostri disegni di avatar e — facoltativamente — un indirizzo postale completo.

Nulla di ciò viene memorizzato presso BrickDb. Tali dati sono detenuti dal fornitore di identità Auth0 presso l'account di accesso dell'utente; BrickDb li legge e li scrive lì, anziché tenerne una copia: il nostro record dell'account non contiene nient'altro che un identificativo pseudonimo e il momento della sua creazione. Se l'utente elimina il proprio account ai sensi della sezione 14, viene eliminato l'account Auth0 e con esso questo profilo.

Ogni dato è facoltativo. Nulla di ciò è necessario, nulla è presupposto per l'utilizzo di BrickDb e all'utente non viene negata alcuna funzione se lascia vuoto un campo. Ogni dato può essere modificato o cancellato in qualsiasi momento.

Perché, in particolare, viene chiesto l'indirizzo. Due finalità, entrambe indicate qui prima che il campo venga offerto, e non soltanto dopo:

• Valutazione a fini assicurativi. BrickDb offrirà una valutazione di una collezione a fini assicurativi. Una tale valutazione è legata al luogo in cui la collezione è conservata; un assicuratore non la accetta senza tale indicazione.
• Un mercato previsto, con BrickDb come fiduciario. BrickDb intende offrire un mercato nel quale BrickDb agisce come fiduciario tra acquirente e venditore. L'indirizzo postale di una parte è ciò che rende una tale operazione imputabile e una controversia risolvibile.

Nessuno dei due servizi esiste ancora. L'indirizzo non viene utilizzato per nient'altro: non per la pubblicità, non per la profilazione, non per alcuna forma di scoring, e non viene trasmesso a terzi.

Il paese dell'utente viene inoltre utilizzato per preselezionare un paese nell'elenco degli eventi e per i prezzi nelle pagine dei set e delle minifigure, con precedenza sulla preferenza linguistica del browser descritta nella sezione 3. A tal fine viene letto presso Auth0 all'apertura di una tale pagina, non viene per questo memorizzato da BrickDb e non viene trasmesso, e la scelta può essere annullata nella pagina con un clic.

Il paese e la lingua che l'utente sceglie sul sito. Se l'utente, dopo aver effettuato l'accesso, sceglie e salva un paese e una lingua per il sito, entrambi vengono registrati presso il suo account di accesso presso Auth0, in aggiunta alle voci nel browser (sezione 6.1), affinché la scelta valga anche su un altro dispositivo e a un altro indirizzo di BrickDb. Nemmeno di questi BrickDb tiene una copia propria. Se l'utente non ha effettuato l'accesso, la scelta resta soltanto nel browser.

Base giuridica: per nome, cognome, testo di presentazione, paese e lingua scelta, articolo 6, paragrafo 1, lettera b), del GDPR — il trattamento fa parte della prestazione richiesta. Per l'indirizzo, articolo 6, paragrafo 1, lettera a), del GDPR — consenso, prestato compilando il campo e revocabile in qualsiasi momento cancellandolo. La revoca non incide per il resto sull'account dell'utente e non pregiudica la liceità del trattamento effettuato fino a quel momento.

Il profilo è compreso nella copia dei dati dell'utente di cui alla sezione 14 e viene eliminato con l'account ai sensi della stessa sezione.

7.3 Invio di e-mail

BrickDb invia e-mail soltanto quando vi è un'occasione concreta: la conferma dell'indirizzo e-mail dell'utente e la reimpostazione della sua password, un invito a una collezione quando qualcuno invita l'utente (sezione 8.1a), un invito a scegliere la propria password quando l'amministrazione crea un account per l'utente (sezione 8.9), la nostra risposta a una richiesta di assistenza, nonché una notifica alla nostra casella di posta quando qualcuno ne presenta una — quest'ultima è rivolta a noi e non all'utente, ma contiene ciò che il richiedente ha scritto (la sezione 8.7 tratta entrambe) —, una notifica alla nostra casella di posta quando qualcuno segnala un contenuto, e la motivazione inviata all'utente quando viene accolta una segnalazione relativa a un contenuto che egli ha pubblicato (entrambe sezione 8.8). Non vi sono né newsletter né e-mail pubblicitarie.

Il fornitore del servizio di invio è Twilio Inc. (“SendGrid”), 101 Spear Street, 5th Floor, San Francisco, CA 94105, USA. SendGrid riceve a tal fine l'indirizzo del destinatario, un nome visualizzato, ove ne esista uno, l'oggetto e il contenuto completo del messaggio, nonché i dati tecnici di recapito (momento, stato del recapito, risposta del server di posta ricevente). L'indirizzo e-mail dell'utente viene pertanto trasmesso a un terzo, e ciò per prima cosa — ancora prima che con esso avvenga qualsiasi altra cosa. Per questo ciò è indicato qui e non soltanto più avanti nella sezione 12.

Base giuridica: articolo 6, paragrafo 1, lettera b), del GDPR — la conferma di un indirizzo, la reimpostazione di una password e il recapito di un invito fanno parte della prestazione richiesta. SendGrid è al riguardo responsabile del trattamento ai sensi dell'articolo 28 del GDPR sulla base del Twilio Data Protection Addendum.

Trasferimento verso paesi terzi: l'invio avviene tramite l'infrastruttura globale di SendGrid; il trattamento ha quindi luogo negli Stati Uniti e non, come l'hosting di cui alla sezione 4, in Germania. Twilio fonda tali trasferimenti sulle clausole contrattuali tipo della Commissione europea ed è inoltre certificata nell'ambito dell'EU-US Data Privacy Framework.

Misurazione delle aperture e dei clic: sì per le e-mail dell'account, no per le nostre. Le e-mail relative all'account dell'utente — conferma dell'indirizzo, reimpostazione della password — vengono integrate da SendGrid, prima dell'invio, con un'immagine invisibile, e i loro link vengono reindirizzati tramite SendGrid. Quando il programma di posta dell'utente visualizza un tale messaggio, carica questa immagine e trasmette in tal modo a SendGrid il momento e l'indirizzo IP; lo stesso avviene quando si fa clic su un link. Da ciò presso SendGrid nasce l'informazione se e quando un tale messaggio è stato aperto. Base giuridica: articolo 6, paragrafo 1, lettera f), del GDPR — il nostro legittimo interesse a che le e-mail dell'account arrivino e non finiscano nella cartella dello spam. L'utente può opporsi ai sensi dell'articolo 21 del GDPR tramite i dati di contatto indicati nella sezione 2, e può disattivare il caricamento delle immagini nel proprio programma di posta — in tal caso la misurazione delle aperture non ha luogo.

Le e-mail che BrickDb invia direttamente non contengono né una tale immagine né link reindirizzati — oggi si tratta degli inviti a una collezione, delle due e-mail di assistenza di cui alla sezione 8.7, la nostra risposta a una richiesta e la notifica che essa ci invia, nonché delle due e-mail relative alle segnalazioni di cui alla sezione 8.8. Nessuna di esse richiede alcunché a un server quando viene aperta; ogni invio disattiva espressamente entrambe le misurazioni presso SendGrid.

Periodo di conservazione: BrickDb non crea alcuna copia di un messaggio inviato. Presso il fornitore del servizio di invio i dati di recapito restano consultabili nel suo registro delle attività per un breve periodo che dipende dal suo piano tariffario.

Stato della presente versione: questa sezione descrive il percorso di invio così come esiste attualmente. Fino a quando non si è aggiunta la notifica relativa a una richiesta di assistenza sopra indicata, qui si leggeva “così come esiste dal 10 settembre 2026”.

8. Dati della collezione e fotografie

Le indicazioni che seguono descrivono il trattamento che ha luogo con un account di cui alla sezione 7.

8.1 Dati della collezione

Viene memorizzato ciò che l'utente stesso inserisce: numero del set, denominazione, indicazioni sulla condizione, note, data di acquisto, prezzo pagato, indicazioni sul venditore nonché i momenti della creazione e dell'ultima modifica. Tali dati sono collegati a un numero identificativo pseudonimo.

Allo stesso modo viene memorizzato ciò che l'utente inserisce nelle altre aree: singole minifigure e pezzi sfusi con gli stessi dati, esemplari di numeri di riviste e di libri con il loro grado di condizione, lo stato di un polybag allegato, le osservazioni dell'utente sulla condizione, come e quando sono stati acquistati, il prezzo pagato, l'indicazione sul venditore e le note dell'utente, collezioni con il loro nome, la loro descrizione, la loro visibilità ai sensi della sezione 8.1a e i loro membri con il rispettivo ruolo, inviti che l'utente ha emesso, con l'indirizzo e-mail indicato a tal fine, firme che l'utente registra per un esemplare, la sua lista dei desideri, i suoi contributi alla risoluzione di codici delle bustine e codici a barre delle scatole, e le elaborazioni in blocco di foto di scatole che l'utente avvia.

Gli esemplari di numeri di riviste e di libri non si trovano in alcuna collezione; li vede soltanto l'utente.

Luoghi di conservazione. L'utente può registrare dove sono conservate le sue cose: stanze, posizioni in una stanza e scomparti in una posizione, ciascuno con il nome che l'utente assegna, il suo livello e la sua posizione nell'elenco dell'utente, e per ogni esemplare — set, minifigure, pezzi sfusi, numeri di riviste e libri — in quale luogo si trova. I luoghi di conservazione dell'utente appartengono all'utente, non a una collezione: soltanto l'utente può crearli, modificarli o assegnarli. Dove si trova un esemplare in una collezione condivisa lo vedono, in sola lettura, i membri il cui ruolo in tale collezione è Proprietario o Editor; i membri con il ruolo Lettore o Assicurazione non lo vedono mai, e una collezione pubblicata non lo mostra mai (sezione 8.1a). Se l'utente elimina il proprio account (sezione 14), i suoi luoghi di conservazione vengono eliminati, e prima il luogo viene rimosso da ogni esemplare che lo indicava — anche da un esemplare che resta in una collezione condivisa con altri.

I campi di testo libero non vengono analizzati. Si prega di non inserirvi categorie particolari di dati personali ai sensi dell'articolo 9 del GDPR.

Base giuridica: articolo 6, paragrafo 1, lettera b), del GDPR — il trattamento è necessario per la prestazione del servizio richiesto.

8.1a Chi può vedere una collezione

Ogni esemplare che appartiene all'utente si trova in una collezione, e una collezione ha una di tre impostazioni, che l'utente sceglie e può modificare in qualsiasi momento: privata (la vedono soltanto i suoi membri — l'impostazione predefinita per una nuova collezione), chiunque abbia il link oppure chiunque, compresi i motori di ricerca.

Una collezione resa pubblica mostra il suo nome e la sua descrizione, i numeri dei set, i nomi dei set, quanti esemplari di ciascuno l'utente possiede e in quale condizione si trovano — e nient'altro. Nessuna fotografia, nessuna nota, nessun tag, nessun soprannome, nessun luogo di conservazione, nessun prezzo pagato, nessuna stima di valore, nessuna data di acquisto e nulla sul venditore. Non nomina né l'utente né un altro membro e non dice nemmeno quante persone ne fanno parte. Tali campi non vengono semplicemente nascosti in quella pagina — non vi vengono affatto trasmessi.

Un link non è una password. Una collezione con l'impostazione “chiunque abbia il link” viene fornita a ogni persona che apre tale indirizzo, che l'utente glielo abbia dato o no. L'impostazione “chiunque abbia il link” chiede inoltre ai motori di ricerca di non includere la pagina; essi di norma vi si attengono e non vi sono obbligati. Riportare una collezione a privata pone immediatamente fine alla fornitura, ma non recupera una copia che qualcuno — o un motore di ricerca — ha già preso.

Una collezione condivisa con membri designati nominativamente è cosa diversa da una pubblica: ciò che un membro vede dipende dal ruolo che l'utente ha assegnato. Il ruolo Lettore vede esattamente ciò che mostra anche la pagina pubblica. Il ruolo Editor vede tutto, compresi i campi sopra elencati. Il ruolo Assicurazione vede i set, la loro condizione e le cifre di valutazione, e nient'altro.

Una collezione pubblica può essere segnalata. La sua pagina reca il modulo di segnalazione di cui alla sezione 8.8, utilizzabile da chiunque possa vedere la pagina. Se l'amministrazione accoglie una segnalazione al riguardo, la collezione viene riportata a privata; non viene eliminato nulla e l'utente può pubblicarla di nuovo.

Base giuridica: articolo 6, paragrafo 1, lettera a), del GDPR — l'utente presta il consenso scegliendo l'impostazione e lo revoca ripristinandola.

8.2 Fotografie

Le fotografie caricate vengono mostrate all'utente e ai membri della collezione il cui ruolo comprende i dettagli privati — vale a dire Proprietario ed Editor ai sensi della sezione 8.1a. Se l'esemplare si trova in una collezione in cui non c'è nessun altro, la fotografia è vista soltanto da chi l'ha caricata. Nella pagina pubblica di una collezione le fotografie non compaiono, e nemmeno le vedono i membri con il ruolo Lettore o Assicurazione. Le fotografie non vengono pubblicate, non vengono trasmesse a terzi e non vengono utilizzate per addestrare modelli.

I metadati vengono rimossi. Al caricamento ogni immagine viene ricodificata: l'orientamento annotato nell'immagine viene incorporato stabilmente nei dati dell'immagine e in seguito viene rimosso l'intero profilo dei metadati — EXIF, IPTC e XMP, e quindi in particolare le coordinate GPS, il momento dello scatto e gli identificativi del dispositivo. Viene memorizzata soltanto l'immagine ripulita; il file trasmesso in origine non viene conservato.

Il nome originale del file non viene ripreso. Ogni file riceve un identificativo generato casualmente; dal percorso di archiviazione non si può desumere nulla sulla persona che ha caricato il file né sulla sua provenienza.

Versioni ridimensionate. Per la visualizzazione vengono generate all'occorrenza versioni ridotte di una fotografia, che vengono memorizzate temporaneamente. Esse contengono gli stessi dati dell'immagine — già ripuliti dai metadati —, sono soggette alle stesse restrizioni di accesso e vengono eliminate insieme alla fotografia.

Le immagini in un formato che non può essere ricodificato — tra cui HEIC/HEIF, il formato standard degli iPhone più recenti — vengono rifiutate anziché memorizzate. Il messaggio di errore indica i formati accettati (JPEG, PNG, WebP, GIF). Non viene quindi archiviato nulla che non sia stato prima ripulito.

Per ogni fotografia vengono memorizzati: l'identificativo casuale del file, una didascalia assegnata dall'utente, l'ordinamento e il momento del caricamento.

Base giuridica: articolo 6, paragrafo 1, lettera b), del GDPR.

8.3 Immagine dell'avatar

L'utente può caricare una propria immagine come avatar oppure utilizzare uno dei disegni messi a disposizione da BrickDb. I disegni messi a disposizione sono nostre opere grafiche e non sono dati personali; un'immagine caricata lo è.

Un avatar caricato passa attraverso la stessa ripulitura di ogni altra fotografia: l'orientamento viene incorporato nei dati dell'immagine e l'intero profilo dei metadati — EXIF, IPTC e XMP, e quindi in particolare le coordinate GPS, il momento dello scatto e gli identificativi del dispositivo — viene rimosso. In seguito l'immagine viene ritagliata al suo quadrato centrale, ridotta a 256 per 256 pixel e ricodificata come WebP. Viene memorizzata soltanto tale immagine; il file trasmesso non viene conservato, e un'immagine che non può essere ricodificata viene rifiutata anziché memorizzata.

Chi può vederlo. Un avatar viene memorizzato affinché possa essere mostrato accanto al nome dell'utente. BrickDb non ha attualmente alcuna schermata in cui una persona veda il profilo di un'altra — oggi, quindi, soltanto l'utente vede il proprio. Non appena ciò cambierà, questa sezione lo dirà espressamente: un avatar è pensato per essere visibile ad altri, ed è proprio per questo che è trattato qui separatamente dalla sezione 8.2.

Per ogni account viene memorizzato esattamente un avatar; un ulteriore caricamento lo sostituisce. Esso è compreso nella copia dei dati dell'utente di cui alla sezione 14 e viene eliminato quando l'utente elimina il proprio account ai sensi della sezione 14.

Base giuridica: articolo 6, paragrafo 1, lettera b), del GDPR.

8.4 Proposte di eventi

Quando viene proposto un evento memorizziamo il titolo, la descrizione facoltativa, il luogo dell'evento, il paese e il calendario. Per un evento che dura l'intera giornata si tratta della data di inizio e della data di fine non inclusa. Per un evento con orario si tratta degli istanti di inizio e di fine e del fuso orario del luogo dell'evento. Si aggiungono la data facoltativa di apertura delle iscrizioni, l'URL della fonte, il collegamento con l'account e il momento dell'invio. Memorizziamo inoltre lo stato di moderazione, il momento di una decisione di moderazione e un ordine interno di notifica per la coda di verifica. Tale ordine non invia alcuna e-mail.

L'amministrazione verifica le proposte manualmente. Le proposte in attesa e quelle respinte non sono pubbliche. Dopo l'approvazione i dati dell'evento e l'URL della fonte sono visibili pubblicamente; l'identità dell'account non viene pubblicata. Si prega di inviare soltanto dati di eventi che l'utente è autorizzato a pubblicare, senza dati di contatto personali o informazioni private su di sé o su altri.

L'invio e la moderazione costituiscono la prestazione del servizio richiesto (articolo 6, paragrafo 1, lettera b), del GDPR). Il mantenimento del calendario pubblico approvato risponde al legittimo interesse nostro e degli altri visitatori a disporre di informazioni affidabili sugli eventi (articolo 6, paragrafo 1, lettera f), del GDPR). Contro un trattamento fondato su legittimi interessi l'utente può opporsi tramite i dati di contatto indicati nella sezione 2. L'esportazione dei dati ai sensi dell'articolo 15 del GDPR nella pagina dell'account contiene le proposte di eventi dell'utente in ogni stato di moderazione.

Con l'eliminazione dell'account le proposte in attesa e quelle respinte vengono eliminate insieme ai relativi ordini di notifica. Gli eventi approvati restano pubblici; il collegamento con la persona che li ha proposti viene anonimizzato: lo sostituisce un nuovo valore casuale, senza account né corrispondenza che riconduca alla persona. I dati approvati restano nel calendario per gli altri visitatori; per questo insieme di dati anonimizzato non è previsto un termine di scadenza fisso. Per le copie di backup vale la sezione 13. Gli altri diritti di cui alla sezione 14 restano fermi.

8.5 Lettura del numero del set da una fotografia

Quando l'utente invia espressamente una fotografia di una confezione di vendita per la lettura del numero del set, BrickDb trasmette al massimo 8 MB dal browser ai propri server web e API. Il server API inoltra la fotografia, invariata, a un terzo server proprio, il servizio di lettura (la container app “brickdb-ocr”). Esso è eseguito nello stesso ambiente Azure e nella stessa regione (Germany West Central, Frankfurt am Main) degli altri server di cui alla sezione 4, è raggiungibile soltanto dall'interno di tale ambiente e non ha accesso né alla banca dati né all'archiviazione dei file. Come i server web e API, anche il servizio di lettura tiene l'immagine esclusivamente nella memoria di lavoro; restituisce al server API soltanto i possibili numeri di set letti su di essa, e la sua voce di registro annota soltanto come si è conclusa la richiesta (ad esempio letta o respinta) e quanto è durata, nulla sulla fotografia. Su nessuno dei tre server l'immagine viene memorizzata, registrata nei log o utilizzata per addestrare modelli; non viene trasmessa a terzi e viene scartata al termine della richiesta. Gestiamo noi stessi tutti e tre i server su Microsoft Azure; Microsoft è al riguardo responsabile del trattamento ai sensi della sezione 4. Base giuridica: articolo 6, paragrafo 1, lettera b), del GDPR — il trattamento costituisce la prestazione di lettura richiesta dall'utente.

Affinché tale funzione ad alta intensità di calcolo resti disponibile, ogni processo del server consente sei richieste per indirizzo IP di origine nell'arco di un minuto scorrevole. Tale limite è verificato sia dal server web sia dal server API, perché il server API è raggiungibile anche direttamente. Ogni processo del server conta per conto proprio, e di ciascun server possono essere in esecuzione più processi contemporaneamente; il limite vale pertanto per processo e non come un totale unico per l'intero BrickDb. Affinché, in caso di richiesta tramite il server web, il server API conti l'indirizzo dell'utente e non quello del server web, il server web gli trasmette l'indirizzo dell'utente insieme alla richiesta; il servizio di lettura non lo riceve. Su entrambi i server l'indirizzo — per IPv6 soltanto la sua parte di rete — è tenuto soltanto come chiave nella memoria di lavoro del rispettivo processo del server; non viene né registrato nei log, né memorizzato in modo permanente, né trasmesso a terzi. Dopo un minuto non influisce più su alcuna decisione e viene rimosso quando tale indirizzo effettua una nuova richiesta o quando la pulizia attivata dalle richieste ha bisogno di spazio. Ogni processo del server tiene al massimo 1.024 chiavi di indirizzo; finché tutti i posti sono ancora attivi, un nuovo indirizzo viene respinto anziché scalzarne uno. Base giuridica: articolo 6, paragrafo 1, lettera f), del GDPR. Il legittimo interesse è la disponibilità tecnicamente sicura, affidabile ed equa del servizio.

8.6 Suggerimento sulla condizione di una confezione a partire da una fotografia

Separatamente dalla lettura del numero del set, l'utente può richiedere espressamente, per una fotografia di una confezione di vendita, un suggerimento sulla condizione visibile della scatola. Soltanto se l'utente ha richiesto tale valutazione e ha confermato la richiesta, BrickDb trasmette la fotografia dal proprio server API al servizio Azure OpenAI di Microsoft Ireland Operations Limited, One Microsoft Place, South County Business Park, Leopardstown, Dublin 18, Irlanda, quale responsabile del trattamento ai sensi dell'articolo 28 del GDPR. Prima l'immagine viene ricodificata, liberata da tutti i metadati e ridotta a un massimo di 1.024 pixel sul lato più lungo. La connessione è stabilita dal server, non dal browser dell'utente; l'apertura di una pagina non la attiva mai.

Il trattamento ha luogo nella EU Data Zone di Azure, quindi all'interno dell'UE; la distribuzione è collocata nella regione Germany West Central e il trattamento può avvenire in qualsiasi Stato membro dell'UE. Secondo quanto indicato da Microsoft, gli input e gli output non vengono utilizzati per addestrare i modelli e non vengono trasmessi ai fornitori dei modelli. Monitoraggio standard degli abusi: Microsoft esamina gli input in modo automatizzato per individuare usi abusivi. Un input contestato in tale esame può essere conservato da Microsoft come campione ed esaminato da dipendenti autorizzati di Microsoft nel SEE; Microsoft non indica al riguardo alcuna durata massima fissa. Al di là di ciò il servizio non conserva la fotografia.

BrickDb stesso resta privo di stato: la fotografia e il risultato non vengono memorizzati presso BrickDb, non vengono registrati nei log e non vengono utilizzati per addestrare modelli; entrambi vengono scartati al termine della richiesta. Il risultato è un suggerimento sperimentale e non calibrato relativo soltanto alla condizione visibile della confezione — non esiste un tasso di accuratezza misurato, non dice nulla sul contenuto, sul sigillo o sulla completezza, non inserisce nulla nella collezione dell'utente, ed è l'utente stesso ad accettarlo o sostituirlo espressamente. Si prega di fotografare soltanto la confezione: nessuna persona, nessun indirizzo né altri dati personali, e soltanto immagini che l'utente è autorizzato a inviare.

Base giuridica: articolo 6, paragrafo 1, lettera a), del GDPR — il consenso dell'utente, prestato con ogni singola richiesta. Esso è facoltativo; senza di esso non viene trasmessa alcuna fotografia e la questione della condizione resta un'indicazione che l'utente fornisce da sé. Per il futuro l'utente lo revoca non richiedendo un'ulteriore valutazione. Non è un consenso a un addestramento; un eventuale opt-in successivo, revocabile separatamente, costituirebbe una dichiarazione a sé.

8.7 Richieste di assistenza

Nella pagina di assistenza è presente un modulo di assistenza, e l'utente può utilizzarlo senza account e senza accesso. Esso chiede un indirizzo e-mail per la risposta, un oggetto e il messaggio; il nome è facoltativo. La lingua non viene chiesta — risulta dalla lingua in cui la pagina è stata visualizzata, affinché la risposta avvenga nella lingua in cui è stata posta la domanda. Scrivendoci invece all'indirizzo indicato nella sezione 2 ci si raggiunge altrettanto bene, ma da ciò non nasce alcuna pratica; tale messaggio è allora semplicemente un'e-mail nella nostra casella di posta.

Ciò che l'utente invia viene memorizzato come pratica con un numero di pratica: l'indirizzo e-mail per la risposta, il nome facoltativo, la lingua in cui l'utente ha scritto, l'oggetto, il testo della richiesta, lo stato di lavorazione, il canale di arrivo nonché i momenti dell'arrivo e della chiusura.

In questa versione nessuna pratica è collegata a un account utente — nemmeno quella che l'utente invia dopo aver effettuato l'accesso. La route che riceve il modulo è aperta a tutti e non accerta alcun accesso, cosicché il campo previsto per tale collegamento resta vuoto. Ciò che ne consegue per i diritti dell'utente è indicato più sotto nel paragrafo sull'eliminazione. A una pratica appartiene inoltre un campo per una chiave di accesso a una pagina di stato, e anche una tale chiave non viene emessa in questa versione, cosicché anche tale campo resta vuoto. Se ne venisse emessa una, ne verrebbe memorizzata soltanto la somma di controllo, mai la chiave stessa.

Qualcuno ne viene informato subito. Una pratica presentata dall'utente ci viene comunicata per e-mail alla nostra casella di posta, affinché non resti inosservata. Tale notifica contiene il numero di pratica, l'indirizzo e il nome indicati dall'utente, l'oggetto e il testo completo del messaggio. È inviata tramite il fornitore del servizio di posta indicato nella sezione 7.3, cosicché tali dati vengono trattati negli Stati Uniti sulla base ivi descritta. Diversamente dalle e-mail dell'account di cui a quella sezione, essa non contiene alcuna immagine invisibile né link reindirizzati. Ciò che l'utente stesso vede è il numero di pratica nella pagina, non appena il modulo è stato inviato; la nostra risposta all'utente è un'e-mail a sé, più sotto alla voce "Come rispondiamo".

Protezione dagli invii di massa. Affinché il modulo non possa essere usato per sommergerci, BrickDb consente cinque invii per connessione Internet nell'arco di un quarto d'ora scorrevole. A tal fine tiene una forma abbreviata dell'indirizzo IP dell'utente come chiave nella memoria di lavoro di un processo web — per IPv6 soltanto la parte di rete, per IPv4 l'indirizzo. Non viene registrata nei log, non viene scritta nella pratica, non viene memorizzata nella banca dati e non viene trasmessa, e trascorso il quarto d'ora non influisce più su alcuna decisione. Vengono tenute al massimo 1.024 chiavi di questo tipo; se tutti i posti sono occupati, una nuova viene respinta anziché scalzarne una esistente. Non esiste alcun captcha, e a tal fine non viene caricato nulla da terzi. Base giuridica: articolo 6, paragrafo 1, lettera f), del GDPR. Il legittimo interesse è la disponibilità tecnicamente corretta, sicura ed equa del servizio.

Base giuridica: gestione e riscontro della richiesta dell'utente (articolo 6, paragrafo 1, lettera b), del GDPR, nella misura in cui essa riguarda il suo rapporto d'uso, altrimenti articolo 6, paragrafo 1, lettera f), del GDPR — il nostro legittimo interesse a poter rispondere alle richieste relative a questo servizio). Contro un trattamento fondato su legittimi interessi l'utente può opporsi tramite i dati di contatto indicati nella sezione 2.

Periodo di conservazione: una pratica chiusa viene eliminata 24 mesi dopo la sua chiusura. Il termine decorre dalla chiusura, non dall'arrivo — una pratica per la quale l'utente è ancora in attesa non viene eliminata, per quanto vecchia sia. L'eliminazione avviene nell'ambito di una pulizia periodica e quindi eventualmente alcuni giorni dopo la scadenza del termine, mai prima. Per le copie di backup vale la sezione 13.

In caso di eliminazione dell'account ai sensi dell'articolo 17 del GDPR, l'eliminazione dell'account nella pagina dell'account anonimizza tutte le pratiche collegate all'account dell'utente: l'indirizzo e-mail, il nome e tale collegamento vengono rimossi e la chiave di accesso perde validità, mentre la pratica stessa viene anonimizzata anziché eliminata, perché l'oggetto, il testo e le nostre risposte sono la nostra documentazione di una conversazione alla quale abbiamo partecipato anche noi. Poiché in questa versione nessuna pratica reca un tale collegamento, questo passaggio in pratica non raggiunge nulla: una richiesta di assistenza non è compresa né nell'esportazione dei dati ai sensi dell'articolo 15 del GDPR né nell'eliminazione dell'account nella pagina dell'account, indipendentemente dal fatto che l'utente avesse effettuato l'accesso al momento dell'invio. L'elenco di ciò che l'esportazione non contiene indica le richieste di assistenza proprio per questo motivo.

I diritti dell'utente di cui alla sezione 14 restano invariati, ed ecco come esercitarli per una pratica: occorre rivolgersi a noi tramite i dati di contatto indicati nella sezione 2 e indicare il numero di pratica o l'indirizzo utilizzato. Una cosa va saputa al riguardo — la rimozione dei campi non anonimizza il testo libero. Se l'utente ha scritto nella richiesta stessa il proprio nome, un numero d'ordine o altri dati su di sé, questi si trovano ancora nel testo. In tal caso basta comunicarcelo; oscureremo o elimineremo manualmente la pratica in questione.

Note interne: mentre una pratica è in lavorazione scriviamo inoltre delle note per noi stessi — che cosa è stato tentato, che cosa abbiamo trovato, a quale stato di lavorazione abbiamo portato la pratica e chi lo ha fatto. Tali note sono nostre e non dell'utente: sono legate alla persona che le ha scritte, non diventano mai parte di una risposta all'utente e pertanto non sono comprese nell'esportazione dei dati dell'utente ai sensi dell'articolo 15 del GDPR né vengono anonimizzate con l'eliminazione del suo account. Vengono eliminate insieme alla pratica, allo stesso termine. Chi desidera sapere se una nota lo menziona per nome può scriverci tramite i dati di contatto indicati nella sezione 2 indicando il numero di pratica.

Come rispondiamo: rispondiamo per e-mail all'indirizzo che l'utente ha indicato, e nella lingua in cui ha scritto. Tale risposta cita ancora una volta l'oggetto e il messaggio dell'utente, affinché questi ritrovi la pratica — all'atto dell'invio non ne riceve alcuna copia. La nostra risposta non contiene alcun link e alcun tracciamento: non viene caricato nulla, e non veniamo a sapere se l'utente la apre. Se in seguito resta ancora qualcosa di aperto, è sufficiente rispondere a tale e-mail lasciando il numero di pratica nell'oggetto.

E-mail all'indirizzo di assistenza: le e-mail inviate a support@brickdb.net — anche una risposta a una delle nostre risposte, che deve essere inviata lì — diventano una pratica. Il nostro fornitore del servizio di posta (sezione 7.3) le riceve per nostro conto per il sottodominio support.brickdb.net e le consegna a BrickDb; vengono pertanto trattate negli Stati Uniti sulla base ivi descritta. Se l'oggetto reca il numero di una pratica aperta, se l'e-mail proviene dall'indirizzo proprio di tale pratica e se il dominio del mittente l'ha firmata o autorizzata (DKIM o SPF, verificati alla ricezione), essa viene aggiunta a tale pratica; ogni altra e-mail ne apre una nuova, e la pratica annota se il mittente ha potuto essere confermato in tal modo. Vengono memorizzati l'indirizzo e il nome del mittente, l'oggetto, la lingua indicata dall'e-mail e il suo testo — mai i suoi allegati: un allegato non viene memorizzato da nessuna parte, la pratica annota soltanto quanti erano. Un'e-mail che il nostro controllo antispam classifica come spam, che proviene da uno dei nostri indirizzi o che arriva dopo che nell'ultima ora sono già state accettate cinque e-mail dallo stesso mittente (o sessanta in totale) non diventa una pratica; affinché una richiesta autentica rimasta così bloccata possa comunque essere trovata e ricevere risposta, annotiamo brevemente quando è arrivata, perché è stata respinta, l'indirizzo del mittente e l'oggetto — mai il testo —, e ciò per 30 giorni. La base giuridica, il periodo di conservazione e i diritti dell'utente sono per il resto quelli del modulo di cui sopra.

Stato della presente versione: il modulo per le richieste di assistenza su /support è in funzione, e così pure la risposta per e-mail sopra descritta. È sempre possibile raggiungerci anche tramite i dati di contatto indicati nella sezione 2 e nell'Impressum — è questa la via da seguire se il modulo, per qualsiasi motivo, non accetta la richiesta.

8.8 Segnalazioni relative ai contenuti

A ogni evento nella pagina degli eventi appartiene un modulo di segnalazione, e così pure alla pagina di ogni collezione pubblicata (sezione 8.1a), e l'utente può utilizzarlo senza account e senza accesso — ciò che è oggetto di una segnalazione può essere visto anche da chi non ha effettuato l'accesso, cosicché un ostacolo posto davanti escluderebbe proprio la persona per la quale il modulo esiste. Vengono chiesti un motivo tratto da un elenco fisso, una descrizione facoltativa di ciò che non va e un indirizzo e-mail facoltativo. Soltanto per un unico motivo — „Altro“ — la descrizione è obbligatoria, perché una segnalazione il cui intero contenuto è tale parola dovrebbe prima essere letta per poter essere classificata. La lingua non viene chiesta — risulta dalla lingua in cui la pagina è stata visualizzata.

Ciò che l'utente invia viene memorizzato come segnalazione con un riferimento proprio, che ha l'aspetto di BDR-000042: di quale tipo di contenuto si tratta e la chiave propria di tale contenuto, il motivo scelto dall'utente, la sua descrizione, se ne ha scritta una, l'indirizzo e-mail, se ne ha indicato uno, la lingua in cui ha scritto, lo stato di lavorazione nonché i momenti dell'arrivo e della decisione. Una descrizione può essere lunga al massimo 2.000 caratteri, un indirizzo al massimo 254; tutto ciò che è più lungo viene respinto con l'indicazione del campo, anziché essere memorizzato in forma abbreviata.

Nessuna segnalazione è collegata a un account utente — nemmeno quella che l'utente invia dopo aver effettuato l'accesso. La route che riceve il modulo è aperta a tutti e non accerta alcun accesso, e non esiste un campo per un tale collegamento: BrickDb deliberatamente non sa quale segnalazione provenga dall'utente. Ciò che ne consegue per i diritti dell'utente è indicato più sotto nel paragrafo sull'esportazione e sull'eliminazione. Non esiste inoltre alcuna pagina di stato relativa a una segnalazione né una chiave di accesso ad essa, cosicché non viene memorizzato nemmeno nulla del genere.

Qualcuno ne viene informato subito. Una segnalazione inviata dall'utente ci viene comunicata per e-mail alla nostra casella di posta, affinché non resti inosservata. Tale notifica contiene il riferimento, il tipo di contenuto, il motivo, la chiave del contenuto segnalato e il testo completo della descrizione dell'utente. Non contiene alcun indirizzo dell'utente: il messaggio è destinato a noi, e l'indirizzo dell'utente resta nella coda, dove soltanto un amministratore può vederlo. È inviata tramite il fornitore del servizio di posta indicato nella sezione 7.3, cosicché tali dati vengono trattati negli Stati Uniti sulla base ivi descritta; come la notifica di assistenza, non contiene alcuna immagine invisibile né link reindirizzati. Ciò che l'utente stesso vede è il riferimento nella pagina, non appena il modulo è stato inviato.

Protezione dagli invii di massa. Affinché il modulo non possa essere usato per sommergerci, BrickDb consente quattro segnalazioni per connessione Internet nell'arco di dieci minuti scorrevoli. A tal fine tiene una forma abbreviata dell'indirizzo IP dell'utente come chiave nella memoria di lavoro di un processo web — per IPv6 soltanto la parte di rete, per IPv4 l'indirizzo. Non viene registrata nei log, non viene scritta nella segnalazione, non viene memorizzata nella banca dati e non viene trasmessa, e trascorsi i dieci minuti non influisce più su alcuna decisione. Vengono tenute al massimo 1.024 chiavi di questo tipo; se tutti i posti sono occupati, una nuova viene respinta anziché scalzarne una esistente. Non esiste alcun captcha, e a tal fine non viene caricato nulla da terzi. Base giuridica: articolo 6, paragrafo 1, lettera f), del GDPR. Il legittimo interesse è la disponibilità tecnicamente corretta, sicura ed equa del servizio.

Chi legge una segnalazione e che cosa comporta la decisione. Una segnalazione finisce in una coda all'indirizzo /admin/reports, che soltanto un amministratore può aprire; non esiste una pagina in cui qualcun altro possa consultarla — nemmeno tramite il riferimento. La segnalazione viene respinta oppure accolta, e se viene accolta il contenuto segnalato viene rimosso: un evento contro il quale una segnalazione è accolta scompare dal calendario pubblico. Una collezione pubblicata contro la quale una segnalazione è accolta viene riportata a privata: da quel momento la vedono soltanto i suoi membri, nulla di essa viene eliminato e chi ne è proprietario può pubblicarla di nuovo — una collezione pubblicata di nuovo può essere nuovamente segnalata. Agiamo contro il contenuto, non contro la persona che lo ha inserito.

Una decisione su qualcosa che una persona ha pubblicato viene annotata anche presso di lei. Se l'amministrazione accoglie o respinge una segnalazione relativa a una collezione o a un evento proposto da un membro, la decisione viene annotata nel registro di audit di cui alla sezione 8.9, presso l'account della persona che ha pubblicato il contenuto: di quale segnalazione si trattava, il tipo di contenuto e la sua chiave, e come è cambiato lo stato della segnalazione. La persona che ha effettuato la segnalazione non è menzionata in tale voce, e le note della moderazione non ne fanno parte.

Base giuridica: articolo 6, paragrafo 1, lettera f), del GDPR. Il legittimo interesse consiste nel mantenere i contenuti pubblicati da BrickDb liberi da materiale illecito e offensivo, nel poter ricevere un'obiezione — anche da chi non ha un account — e nel poter dimostrare a posteriori come un reclamo è stato trattato. Se una segnalazione riguarda contenuti contro i quali siamo tenuti a intervenire, il suo trattamento serve al tempo stesso ad adempiere un obbligo legale (articolo 6, paragrafo 1, lettera c), del GDPR). Contro un trattamento fondato su legittimi interessi l'utente può opporsi tramite i dati di contatto indicati nella sezione 2.

Se una segnalazione è accolta, la persona che ha pubblicato il contenuto riceve da noi una motivazione per e-mail. Ciò vale per una collezione pubblicata e per un evento proposto da un membro; per un evento che abbiamo ripreso da un calendario altrui non c'è nessuno a cui potremmo scrivere. Il messaggio indica il riferimento della segnalazione, di quale contenuto si tratta (il suo tipo e il suo titolo o nome), che cosa abbiamo fatto e per quanto tempo ciò vale, il motivo con cui la segnalazione è stata presentata, la sezione delle nostre condizioni d'uso in base alla quale abbiamo deciso, l'indicazione che non sono stati impiegati mezzi automatizzati, e come l'utente può opporsi — rispondendo all'e-mail oppure tramite il modulo di assistenza, indicando il riferimento. Non vi è indicato chi ha inviato la segnalazione, né vi figurano la descrizione della segnalazione o le note della moderazione.

Per l'invio, al momento della decisione chiediamo ad Auth0 l'indirizzo e-mail dell'utente e la lingua registrata presso il suo account (sezione 7.1). L'indirizzo è utilizzato soltanto a tal fine e non viene memorizzato presso di noi; nella segnalazione annotiamo soltanto se la motivazione ha potuto essere inviata e quando — oppure perché no, ad esempio perché non è registrato alcun indirizzo. È inviata tramite il fornitore del servizio di posta indicato nella sezione 7.3, cosicché tali dati vengono trattati negli Stati Uniti sulla base ivi descritta; non contiene alcuna immagine invisibile né link reindirizzati. Se una collezione viene riportata a privata, l'impostazione modificata è inoltre visibile nella pagina delle collezioni. Base giuridica: articolo 6, paragrafo 1, lettera c), del GDPR in combinato disposto con l'articolo 17 del regolamento (UE) 2022/2065 (regolamento sui servizi digitali), nella misura in cui siamo tenuti a fornire una tale motivazione, e per il resto articolo 6, paragrafo 1, lettera f), del GDPR — il legittimo interesse consiste nel comunicare all'utente che cosa è accaduto al suo contenuto e perché, e nel dargli un modo per opporsi alla decisione.

Periodo di conservazione: una segnalazione decisa viene eliminata 24 mesi dopo la decisione. Il termine decorre dalla decisione, non dall'arrivo — una segnalazione sulla quale nessuno ha ancora deciso non viene eliminata, per quanto vecchia sia, perché è un'obiezione alla quale è ancora dovuta una risposta. L'eliminazione avviene nell'ambito di una pulizia periodica e quindi eventualmente alcuni giorni dopo la scadenza del termine, mai prima. Per le copie di backup vale la sezione 13.

Né l'esportazione dei dati ai sensi dell'articolo 15 del GDPR né l'eliminazione dell'account raggiungono una segnalazione, e ciò è un limite e non una decisione contro l'utente. Poiché nessuna segnalazione è attribuita a un account, non è affatto possibile chiedere quali segnalazioni provengano da una determinata persona — una segnalazione non è pertanto compresa né nell'esportazione dei dati ai sensi dell'articolo 15 del GDPR né nell'eliminazione dell'account nella pagina dell'account, indipendentemente dal fatto che l'utente avesse effettuato l'accesso al momento dell'invio, e l'eliminazione dell'account non la elimina. Lo stesso vale se qualcuno ha segnalato qualcosa che l'utente ha inserito: tale segnalazione indica il contenuto, mai l'account dell'utente, e quindi non è nemmeno nella sua esportazione — la decisione al riguardo sì, non appena l'amministrazione l'ha accolta o respinta, come voce del registro di audit ai sensi della sezione 8.9. L'elenco di ciò che l'esportazione non contiene indica entrambi i casi proprio per questo motivo. Ciò che l'utente può effettivamente fare: rivolgersi a noi tramite i dati di contatto indicati nella sezione 2 e indicare il riferimento. Con esso troviamo manualmente la segnalazione, possiamo dire all'utente che cosa contiene, rettificarla oppure rimuovere l'indirizzo e il testo che l'utente ha scritto.

La rimozione dei campi non anonimizza il testo libero. Se l'utente ha scritto nella descrizione il proprio nome, un indirizzo o altri dati su di sé, questi si trovano ancora nel testo. In tal caso basta comunicarcelo; oscureremo o elimineremo manualmente la segnalazione in questione.

Note interne: mentre una segnalazione è in lavorazione scriviamo inoltre delle note per noi stessi — che cosa abbiamo trovato, a quale stato di lavorazione abbiamo portato la segnalazione e chi lo ha fatto. Tali note sono nostre e non dell'utente: sono legate alla persona che le ha scritte, non vengono inviate né all'utente né alla persona il cui contenuto è stato segnalato, e pertanto non sono comprese nell'esportazione dei dati dell'utente ai sensi dell'articolo 15 del GDPR né sono raggiungibili mediante un'eliminazione dell'account. Vengono eliminate insieme alla segnalazione, allo stesso termine. Chi desidera sapere se una nota lo menziona per nome può scriverci tramite i dati di contatto indicati nella sezione 2.

Di nostra iniziativa non rispondiamo. Da una segnalazione non nasce alcuna corrispondenza: non vi è alcuna e-mail di conferma, alcuna pagina di stato e alcun messaggio quando è stata presa una decisione. L'indirizzo serve affinché qualcuno possa mettersi in contatto con l'utente qualora la segnalazione non possa essere trattata senza una domanda di chiarimento, e non viene utilizzato per nient'altro. Ciò che l'utente riceve è, subito, il riferimento nella pagina.

Stato della presente versione: il modulo di segnalazione su /events e nella pagina di ogni collezione pubblicata è in funzione, e così pure la coda che vi sta dietro. Se per qualsiasi motivo non accetta la segnalazione, è possibile raggiungerci altrettanto bene tramite i dati di contatto indicati nella sezione 2 e nell'Impressum — un messaggio inviato in tal modo è allora semplicemente un'e-mail nella nostra casella di posta e non genera alcuna segnalazione.

8.9 Amministrazione degli account utente

Gli amministratori di BrickDb possono gestire gli account utente in un'area all'indirizzo /admin/users che soltanto loro possono aprire: vedere l'elenco degli account, consultare un account, modificarne il nome, l'indirizzo e-mail, il profilo o i ruoli, inviare una reimpostazione della password, inviare di nuovo l'e-mail di conferma, contrassegnare un indirizzo e-mail come confermato, bloccarlo o sbloccarlo, oppure eliminarlo mediante la stessa eliminazione descritta nella sezione 14. I dati dell'account ivi mostrati vengono letti in tempo reale presso Auth0 (sezioni 7.1 e 7.2) e non vengono copiati nella banca dati di BrickDb. Lo stesso vale per la cronologia degli accessi di un account: viene letta presso Auth0 quando un amministratore la apre ed è conservata soltanto per il tempo in cui Auth0 stesso la conserva.

Che cosa vede l'amministrazione riguardo a un account. La pagina di un account mostra ciò che Auth0 memorizza al riguardo — il suo identificativo, l'indirizzo e-mail e se esso è confermato, i metodi di accesso ad esso collegati, quando è stato creato, modificato l'ultima volta e quando ha effettuato l'ultimo accesso, quante volte ha effettuato l'accesso, se è bloccato, quali tipi di autenticazione a più fattori sono configurati (soltanto il tipo, mai un segreto o un numero di telefono) e i suoi ruoli — nonché il profilo che l'utente ha compilato (nomi, paese, il testo su di sé, l'avatar scelto e la lingua delle sue e-mail, ma non il suo indirizzo postale). Dalla banca dati propria di BrickDb mostra soltanto conteggi: quante collezioni l'utente possiede e a quante ha aderito, quanti esemplari ha aggiunto, quanti codici delle bustine, codici a barre dei set ed eventi ha fornito, quante delle sue richieste di assistenza sono aperte e quante segnalazioni di contenuti sono state presentate con il suo indirizzo e-mail — mai il loro contenuto.

La cronologia degli accessi mostra, per ogni evento che Auth0 ha registrato per l'account, quando è avvenuto, che cosa era (un accesso o un accesso non riuscito, una registrazione, una disconnessione, una modifica della password o dell'indirizzo e-mail, una conferma dell'e-mail, un passaggio dell'autenticazione a più fattori, un tentativo bloccato da Auth0 oppure una password proveniente da una fuga di dati), tramite quale metodo di accesso e quale applicazione di BrickDb è passato, il paese e la città che Auth0 ha ricavato dall'indirizzo IP, nonché il browser e il sistema operativo con la loro versione principale. L'indirizzo IP stesso non viene mostrato, e nemmeno il testo libero che Auth0 allega a un evento. L'amministrazione la consulta per mantenere sicuri gli account — per riconoscere accessi che non provenivano dall'utente, o un attacco alla sua password — e per aiutare l'utente quando ci interpella riguardo al suo account.

Nessuno nell'amministrazione vede, sceglie o digita mai una password. Un account creato lì riceve una password casuale che nessuno vede, e l'utente riceve da BrickDb un'e-mail di invito (inviata come descritto nella sezione 7.3) con un link valido sette giorni e utilizzabile una sola volta per scegliere la propria password. Una reimpostazione della password è l'e-mail propria di Auth0 con lo stesso tipo di link. Né la password né il link vengono memorizzati o registrati nei log da BrickDb.

Ogni azione dell'amministrazione viene annotata in un registro di audit, e ciò prima che essa venga eseguita, affinché sia annotata anche un'azione non riuscita: quando ha avuto luogo, chi l'ha eseguita, che cosa era, quale account riguardava (il suo identificativo Auth0 nonché l'indirizzo e-mail e il nome che aveva in quel momento), quale motivo la persona ha indicato, quali campi sono cambiati con i loro valori prima e dopo, e se è riuscita. Una password, un link di reimpostazione o un token non vengono mai annotati. Soltanto l'amministrazione può leggere il registro, all'indirizzo /admin/audit, ed esso non ha alcuna funzione che modifichi o elimini una voce.

Base giuridica: articolo 6, paragrafo 1, lettera f), del GDPR. Il nostro legittimo interesse consiste nel mantenere sicuri gli account e il servizio, nell'aiutare l'utente quando il suo account ne ha bisogno e nel poter dimostrare a posteriori che cosa è accaduto a un account, a opera di chi e perché — la responsabilizzazione che l'articolo 5, paragrafo 2, del GDPR ci impone. Ciò vale per i dati dell'amministrazione nel registro tanto quanto per quelli dell'utente. L'utente può opporsi tramite i dati di contatto indicati nella sezione 2.

Periodo di conservazione: una voce del registro di audit viene eliminata 24 mesi dopo l'azione, nell'ambito della pulizia periodica, quindi eventualmente qualche giorno dopo e mai prima. Per le copie di backup vale la sezione 13.

Se l'utente elimina il proprio account, le voci che lo riguardano restano, ma non lo nominano più. L'identificativo dell'account è sostituito da uno pseudonimo casuale, e l'indirizzo e-mail, il nome e tutti i valori modificati vengono rimossi; chi ha agito, che cosa è stato fatto e quando resta, perché è proprio a questo che serve la voce. Conserviamo anche il motivo che l'amministrazione ha annotato; esso può menzionare l'utente nel testo — basta comunicarcelo e lo oscureremo. Se l'utente fa egli stesso parte dell'amministrazione ed elimina il proprio account, le voci relative alle sue azioni restano invariate.

L'amministrazione elimina un account soltanto mediante la stessa eliminazione (sezione 14), passaggio per passaggio, e soltanto dopo aver digitato l'indirizzo e-mail dell'account e indicato un motivo, che il registro di audit conserva. Lo facciamo, ad esempio, quando l'utente ci chiede di eliminare un account al quale non riesce più ad accedere. Se l'utente desidera prima una copia dei propri dati, deve scaricare la propria esportazione ai sensi dell'articolo 15 del GDPR nella pagina dell'account prima di scriverci — in seguito non resta più nulla da esportare. L'amministrazione non può eliminare in questo modo il proprio account; a tal fine esiste, come per tutti, la pagina dell'account.

L'amministrazione può anche scaricare per l'utente la sua esportazione ai sensi dell'articolo 15 del GDPR — ad esempio quando l'utente ci chiede di inviargliela perché non riesce ad accedere. Si tratta dello stesso archivio che fornisce la pagina dell'account, creato allo stesso modo, e l'amministrazione può scaricarlo soltanto dopo aver indicato un motivo. Ogni download viene annotato nel registro di audit come ogni altra azione dell'amministrazione: chi lo ha scaricato, quando e perché. L'archivio va direttamente al browser dell'amministrazione; BrickDb non ne conserva alcuna copia e non lo scrive in alcun log.

L'esportazione dell'utente ai sensi dell'articolo 15 del GDPR nella pagina dell'account contiene le voci relative al suo account (alla voce „adminAuditEntries“) — quando, che cosa, il motivo e che cosa è cambiato —, ma non chi dell'amministrazione sia stato, perché questi sono dati di tale persona e non dell'utente. Chi desidera saperlo può scriverci tramite i dati di contatto indicati nella sezione 2.

Stato della presente versione: l'elenco degli utenti con la sua ricerca, la pagina di un singolo account, la sua cronologia degli accessi, ogni azione sopra indicata e il registro di audit sono in funzione.

9. Fonti di dati esterne

BrickDb mostra dati di catalogo e di prezzo provenienti da fonti di terzi, in particolare Rebrickable e BrickLink. Tali dati vengono recuperati esclusivamente sul lato server e acquisiti nel nostro archivio. In nessun momento il browser stabilisce una connessione con tali fornitori.

A tali fornitori non vengono trasmessi dati personali — né l'indirizzo IP né un numero identificativo, né l'informazione su che cosa è stato cercato o su che cosa qualcuno possiede. Le interrogazioni avvengono secondo un nostro calendario e non come inoltro di una richiesta dell'utente.

10. Misurazione dell'audience con Google Analytics

BrickDb conta con Google Analytics 4 quante volte vengono aperte le pagine e quali aree vengono utilizzate. Ciò avviene esclusivamente con il consenso dell'utente. Finché l'utente non ha acconsentito, non viene caricato alcuno script di Google, non viene impostato alcun identificativo e nulla viene inviato a Google — nemmeno una segnalazione preliminare definita "senza cookie". La modalità di consenso avanzata di Google ("Consent Mode v2 advanced"), nella quale lo script viene caricato subito e trasmette dati già prima del consenso, deliberatamente non viene impiegata.

Base giuridica: articolo 6, paragrafo 1, lettera a), del GDPR — il consenso dell'utente — e § 25, comma 1, TDDDG per la memorizzazione e la lettura delle informazioni sul dispositivo dell'utente.

Destinatario e responsabile del trattamento: Google Ireland Limited, Gordon House, Barrow Street, Dublin 4, Irlanda. La base è costituita dalle condizioni sul trattamento dei dati di Google (Google Ads Data Processing Terms), accettate per l'ordinamento giuridico della Germania.

Che cosa viene trattato: la pagina aperta e il suo titolo, la fonte di provenienza, una posizione approssimativa a livello di paese e di regione, il tipo di dispositivo, il browser, il sistema operativo, le dimensioni dello schermo e la lingua, la data e l'ora, nonché un identificativo casuale nei cookie di cui alla sezione 6.1, con cui vengono riconosciute le visite ricorrenti dallo stesso browser. Sono inoltre attivi gli eventi automatici che Google chiama "misurazione avanzata": profondità di scorrimento, ricerca su questo sito, download di file, interazioni con i video e clic sui link verso altri siti web — quindi anche sui link di affiliazione di cui alla sezione 10.1. L'indirizzo IP dell'utente è utilizzato da Google per ricavare la posizione approssimativa e, secondo quanto indicato da Google, in tale contesto non viene né registrato nei log né memorizzato.

Che cosa non avviene: le funzioni "Google Signals" e "pubblicità personalizzata" sono espressamente disattivate nel codice sorgente della pagina (allow_google_signals e allow_ad_personalization_signals sono entrambi impostati su false), e la condivisione con "prodotti e servizi Google" è disattivata nella proprietà. Non vengono creati elenchi pubblicitari o di segmenti di pubblico, non vengono trasmessi dati a Google a fini pubblicitari e non vengono creati profili su più dispositivi. Non ha luogo alcun processo decisionale automatizzato, compresa la profilazione, ai sensi dell'articolo 22 del GDPR. Nella pagina non sono integrati altri servizi di analisi, reti pubblicitarie o plug-in di social network, e nemmeno uno script di un servizio di segnalazione degli errori: il browser non carica nulla da un tale servizio e non gli invia nulla. La diagnosi degli errori che BrickDb effettivamente impiega è eseguita sul server e — nell'app — sul dispositivo stesso; è descritta nella sezione 11.

Trasferimento verso paesi terzi: la controparte contrattuale è Google Ireland Limited; un trasferimento a Google LLC negli Stati Uniti non può essere escluso. Google LLC è certificata nell'ambito dell'EU-US Data Privacy Framework, per il quale la Commissione europea ha adottato una decisione di adeguatezza il 10 luglio 2023; si applicano inoltre le clausole contrattuali tipo contenute nelle condizioni sul trattamento dei dati di Google.

Periodo di conservazione: i dati relativi agli eventi e agli utenti vengono conservati nella proprietà Google Analytics per un massimo di 14 mesi dall'ultima interazione dell'utente e in seguito eliminati da Google. Il termine decorre dall'ultima visita e non dalla prima, perché nella proprietà è attiva l'opzione "Reimposta in caso di nuova attività": ogni ulteriore visita fa ripartire i 14 mesi. I dati di chi ritorna regolarmente non vengono quindi eliminati finché continua a ritornare. Sono interessati i dati attribuiti a singoli eventi e identificativi. I rapporti standard aggregati — ad esempio "quante visualizzazioni di pagina ha avuto settembre" — non sono contemplati da tale impostazione e restano disponibili presso Google oltre tale termine. Il cookie di consenso sul dispositivo dell'utente scade dopo 182 giorni; in seguito la domanda viene posta di nuovo.

Revoca: in fondo a ogni pagina si trova l'area "misurazione dell'uso" con un pulsante che inverte la decisione dell'utente — un clic, esattamente come lo era stato il consenso (articolo 7, paragrafo 3, del GDPR). La revoca ha effetto immediato: lo script non viene più caricato, e i cookie impostati da Google (_ga e _ga_…) vengono eliminati con la stessa richiesta. Resta impregiudicata la liceità del trattamento effettuato fino alla revoca. Per i dati già trasmessi a Google l'utente può inoltre far valere i diritti indicati nella sezione 14.

Che cosa ciò significa per i numeri: viene contato soltanto chi ha acconsentito. I numeri sono pertanto incompleti e inferiori all'utilizzo effettivo. È la conseguenza voluta della decisione di non caricare nulla senza consenso.

10.1 Link di affiliazione

BrickDb partecipa a programmi di affiliazione; i link corrispondenti sono contrassegnati direttamente con "Pubblicità". Ciò non cambia nulla di quanto affermato sopra: nella pagina non viene integrata alcuna rete pubblicitaria, non viene caricato alcuno script né alcun pixel di conteggio di una rete di affiliazione e non viene impostato alcun identificativo. Con la semplice apertura di una pagina non avviene nulla al riguardo.

Soltanto quando una persona fa clic su un tale link il suo browser apre l'indirizzo del venditore o della rete di affiliazione. Si tratta di un cambio di pagina avviato dalla persona stessa, per il quale il soggetto collegato è titolare del trattamento ai sensi della normativa sulla protezione dei dati. L'indirizzo contiene un identificativo dal quale il venditore riconosce che la visita proviene da BrickDb; esso è visibile nella barra degli indirizzi. BrickDb non viene a sapere chi ha fatto clic: la rete di affiliazione mette a disposizione esclusivamente dati di liquidazione aggregati, nessun dato personale relativo ai singoli clic.

Awin. I link verso i venditori i cui prezzi BrickDb riprende da un feed di dati di prodotto di Awin passano attraverso la rete di affiliazione Awin (AWIN AG, Berlino). BrickDb riproduce un tale link invariato, così come si trova nel feed: esso contiene l'identificativo publisher di BrickDb, l'identificativo del venditore e la destinazione presso il venditore, e nulla sull'utente - nessun identificativo dell'account e nessun identificativo di clic o di visitatore assegnato da BrickDb. Quando l'utente vi fa clic, il suo browser apre dapprima un indirizzo di Awin (awin1.com) e da lì viene reindirizzato al venditore. In tale contesto Awin può raccogliere informazioni direttamente presso l'utente e impostare o leggere cookie nel suo browser sul proprio dominio, per attribuire a tale clic un acquisto successivo, secondo l'informativa sulla privacy propria di Awin. BrickDb non imposta alcun cookie a tal fine, non registra il clic sul proprio server e non trasmette esso stesso ad Awin alcun dato sull'utente.

Rakuten Advertising. I link verso i negozi online gestiti da LEGO stessa, i cui prezzi BrickDb riprende da un feed di dati di prodotto di Rakuten Advertising, passano attraverso la rete di affiliazione Rakuten Advertising, e così pure il link alla carta regalo LEGO presso Giftcards.com che una pagina di set offre ai visitatori negli Stati Uniti. Il titolare del trattamento è Rakuten Marketing LLC dba Rakuten Advertising, 800 Concar Drive, Suite 175, San Mateo, CA 94402, USA, secondo quanto da essa stessa indicato anche per i visitatori dal Regno Unito e dallo Spazio economico europeo. Ai fini della propria informativa sulla privacy Rakuten Advertising indica come stabilimento nell'UE Rakuten Advertising France S.A.S, 92 rue Réaumur, 75002 Paris, Francia, e nel Regno Unito Rakuten Marketing Europe Limited, Vintners Place, 68 Upper Thames St., London EC4V 2AF, Regno Unito. Anche questo link BrickDb lo riproduce invariato, così come si trova nel feed di dati di prodotto: esso contiene l'identificativo publisher di BrickDb, un identificativo dell'offerta e l'indirizzo di destinazione nel negozio, e nulla sull'utente. Il link alla carta regalo LEGO non proviene dal feed di dati di prodotto: Rakuten Advertising lo ha generato una sola volta per BrickDb, ed esso contiene parimenti soltanto l'identificativo publisher di BrickDb, l'identificativo di Giftcards.com e l'indirizzo di destinazione presso Giftcards.com. Quando l'utente vi fa clic, il suo browser apre dapprima un indirizzo di Rakuten Advertising (click.linksynergy.com) e da lì viene reindirizzato al negozio. In tale contesto Rakuten Advertising può raccogliere informazioni direttamente presso l'utente e impostare o leggere cookie nel suo browser sul proprio dominio, per attribuire a tale clic un acquisto successivo, secondo l'informativa sulla privacy propria di Rakuten Advertising. L'utente fa valere i propri diritti nei confronti di Rakuten Advertising tramite il suo modulo per le richieste in materia di privacy; le possibilità di contatto si trovano qui. BrickDb non imposta alcun cookie a tal fine, non registra il clic sul proprio server e non trasmette esso stesso a Rakuten Advertising alcun dato sull'utente.

Tradedoubler. I link verso la libreria Hugendubel, i cui prezzi BrickDb riprende da un feed di dati di prodotto di Tradedoubler, passano attraverso la rete di affiliazione Tradedoubler. Secondo l'informativa sulla privacy propria di Tradedoubler il titolare del trattamento è Nyorda AB (Svezia), la società madre del gruppo Tradedoubler. Anche questo link BrickDb lo riproduce invariato, così come si trova nel feed di dati di prodotto: esso contiene l'identificativo publisher di BrickDb, l'identificativo del programma e del prodotto e l'indirizzo di destinazione presso Hugendubel, e nulla sull'utente. Quando l'utente vi fa clic, il suo browser apre dapprima un indirizzo di Tradedoubler (pdt.tradedoubler.com) e da lì viene reindirizzato a Hugendubel. In tale contesto Tradedoubler può raccogliere informazioni direttamente presso l'utente e impostare o leggere cookie nel suo browser sul proprio dominio, per attribuire a tale clic un acquisto successivo, secondo l'informativa sulla privacy propria di Tradedoubler. L'utente fa valere i propri diritti nei confronti di Tradedoubler all'indirizzo privacy@tradedoubler.com. BrickDb non imposta alcun cookie a tal fine, non registra il clic sul proprio server e non trasmette esso stesso a Tradedoubler alcun dato sull'utente.

Amazon. In qualità di Affiliato Amazon io ricevo un guadagno dagli acquisti idonei. BrickDb partecipa ai programmi di affiliazione Amazon per amazon.com (gestito da Amazon.com Services LLC) e amazon.de (gestito da Amazon Europe Core S.à r.l.). Una pagina di set rimanda a una ricerca nel rispettivo negozio Amazon; su BrickDb non viene caricato nulla di Amazon - nessuno script, nessuna immagine, nessun prezzo e nessun logo. Seguendo un tale link l'utente si trova sul sito proprio di Amazon; lì Amazon può raccogliere informazioni direttamente presso l'utente e impostare o leggere cookie nel suo browser, secondo l'informativa sulla privacy propria di Amazon. BrickDb riceve da Amazon soltanto rapporti aggregati, nessun dato relativo ai singoli visitatori.

Un'integrazione dopo l'introduzione della misurazione dell'audience: se l'utente vi ha acconsentito ai sensi della sezione 10, il clic su un tale link viene inoltre contato come evento in Google Analytics — con l'indirizzo di destinazione, senza alcuna indicazione su chi abbia fatto clic, tranne l'identificativo casuale ivi descritto. Senza il consenso dell'utente non avviene nemmeno questo.

11. Monitoraggio operativo e diagnosi degli errori

L'applicazione è strumentata con OpenTelemetry. Un'esportazione di tali dati avviene soltanto se una destinazione è espressamente configurata; in esercizio non è configurata alcuna destinazione di questo tipo, cosicché tali dati di telemetria non lasciano il processo. Le chiamate agli endpoint di stato sono escluse dalla registrazione.

Per le segnalazioni di errore viene inoltre impiegato il servizio Sentry. Se l'app si arresta in modo anomalo o se sul server una richiesta fallisce inaspettatamente, una segnalazione di errore viene trasmessa a Sentry, affinché l'errore possa essere trovato e corretto. Ciò riguarda quattro punti: il server API, il server web, il servizio di lettura di cui alla sezione 8.5 e — a differenza di tutto il resto in questa sezione — l'app sul dispositivo dell'utente. In tutti e quattro i casi la connessione a Sentry è stabilita dall'applicazione stessa; nel sito web non è integrato alcuno script di un servizio di segnalazione degli errori, il browser quindi non vi invia nulla di propria iniziativa (sezione 10).

Il fornitore è Functional Software, Inc. d/b/a Sentry, 45 Fremont Street, 8th Floor, San Francisco, CA 94105, USA. Esso è al riguardo responsabile del trattamento ai sensi dell'articolo 28 del GDPR. Secondo quanto da essa stessa indicato, Sentry non mantiene nell'Unione europea alcuno stabilimento con il quale possa essere concluso un contratto — la controparte contrattuale è quindi un'impresa con sede negli Stati Uniti.

Luogo del trattamento: da ciò va distinto dove si trovano i dati. Le segnalazioni vanno alla regione UE di Sentry, che Sentry stessa designa come European Union (EU) e che è impostata come regione di archiviazione della nostra organizzazione. L'indirizzo di ricezione in tutti e quattro i punti è su ingest.de.sentry.io e non sull'indirizzo mondiale del servizio. Si tratta di due cose diverse, e soltanto la seconda è un nome host: l'indirizzo al quale il software invia, rispetto all'impostazione dell'account che decide dove risiede ciò che è arrivato.

Trasferimento verso paesi terzi: poiché la controparte contrattuale ha sede negli Stati Uniti, un accesso da tale paese — ad esempio nell'ambito dell'assistenza e della manutenzione — non può essere escluso. Sentry fonda tali trasferimenti sulle clausole contrattuali tipo della Commissione europea, che sono alla base dell'accordo sul trattamento dei dati nella versione 5.1.0 del 29 maggio 2024.

Che cosa contiene una segnalazione di errore: il tipo di errore e il suo messaggio, la traccia tecnica delle chiamate (file, metodi, numeri di riga), la versione di BrickDb, l'indirizzo richiesto con i suoi parametri di query, salvo quelli rimossi come descritto più sotto, nel caso del server API e del server web inoltre le intestazioni della richiesta — ad esempio l'identificativo del browser dell'utente, la lingua preferita e la pagina da cui l'utente proviene — nonché i dati che l'SDK di Sentry raccoglie di propria iniziativa sull'ambiente — in particolare il modello del dispositivo, il sistema operativo e la sua versione, la lingua e il fuso orario. Sul server API si aggiunge l'identificativo pseudonimo dell'account dell'utente, se questi aveva effettuato l'accesso; il server web e l'app non trasmettono alcun identificativo.

Che cosa segnala il servizio di lettura: il servizio di lettura di cui alla sezione 8.5 invia una segnalazione di errore soltanto quando la lettura di una fotografia fallisce inaspettatamente; il fatto di essere sovraccarico o di respingere una fotografia non lo segnala. Una tale segnalazione contiene il tipo di errore e il suo messaggio, la traccia tecnica delle chiamate, la versione di BrickDb, l'indirizzo interno al quale il server API lo ha chiamato, le intestazioni di tale chiamata interna — non quelle del browser dell'utente — e i dati sull'ambiente del server. Il servizio di lettura non trasmette alcun identificativo dell'account dell'utente. La fotografia inviata non è mai contenuta in una segnalazione del servizio di lettura, nemmeno in parte: il contenuto di una richiesta non viene acquisito, e il servizio di lettura non registra nei log nulla sulla fotografia.

Che cosa annota inoltre l'app: affinché un errore sul dispositivo dell'utente possa essere ricostruito, l'app allega a una segnalazione di errore una traccia cronologica. Essa contiene i nomi delle pagine aperte più di recente (non i loro indirizzi); per ogni richiesta al nostro server che non è riuscita, il metodo, l'indirizzo come modello senza identificativi, il codice di stato, la durata e, per quanto noto, il tipo di errore; le impostazioni annotate all'avvio — l'indirizzo del server senza percorso, se l'accesso e le segnalazioni di errore sono attivati, e la lingua impostata —; e, poiché l'SDK di Sentry tiene una propria traccia cronologica delle richieste, per ogni richiesta dell'app — al nostro server e al servizio di accesso — inoltre l'indirizzo completo con il metodo e il codice di stato, compreso il percorso, che può contenere ad esempio un numero di set o l'identificativo di una collezione, e i parametri di query, ad esempio un termine di ricerca. Anche da questo indirizzo i parametri di query sopra indicati il cui nome fa pensare a un segreto, e gli indirizzi e-mail, vengono rimossi prima dell'invio. Lo stesso indirizzo può inoltre trovarsi in una traccia delle prestazioni, che Sentry crea per una quota, scelta a caso, del 2 % delle operazioni nell'app.

Dati sul dispositivo: ogni segnalazione che l'app invia dopo il suo avvio reca la piattaforma, la versione del sistema operativo, il tipo di dispositivo (ad esempio telefono o tablet) e la versione dell'app; non appena è stato eseguito il controllo di avvio della visualizzazione, inoltre il tipo e la versione principale della vista web in cui l'app è eseguita. Se l'app non riesce a caricare un'immagine, un foglio di stile, uno script o un carattere tipografico, oppure blocca un contenuto per motivi di sicurezza, viene annotato di che cosa si trattava — per i file propri il percorso senza identificativi, per gli indirizzi altrui soltanto il nome del server, per un carattere tipografico il suo nome —, e una volta all'avvio un controllo della visualizzazione: quali fogli di stile sono stati caricati, quante regole contengono e quale carattere tipografico viene effettivamente utilizzato. Un tale errore di caricamento, un errore del server o una richiesta che non riceve alcuna risposta possono dare luogo a una segnalazione propria anche senza arresto anomalo — lo stesso errore, per una richiesta, al massimo una volta in dieci minuti e, per un errore di caricamento, al massimo una volta per ogni avvio dell'app.

Il registro sul dispositivo dell'utente: l'app scrive in un registro nell'area di archiviazione propria dell'app: ogni richiesta al nostro server — anche ogni richiesta riuscita — con il metodo, l'indirizzo come modello senza identificativi, il codice di stato, la durata e un numero casuale di operazione; gli errori di caricamento sopra indicati; il risultato del controllo di avvio della visualizzazione, con il tipo e la versione della vista web; le impostazioni annotate all'avvio; e gli altri messaggi dell'app a partire dal livello "Information". I nomi delle pagine aperte, il tipo di un errore, i dati sul dispositivo e gli indirizzi completi provenienti dalla traccia cronologica propria di Sentry non si trovano in questo registro. Esso comprende al massimo tre file di un megabyte ciascuno, le voci più vecchie vengono sovrascritte, e ogni voce viene ripulita al momento della scrittura allo stesso modo di una segnalazione di errore. Questo registro non lascia il dispositivo da sé. Soltanto se l'utente tocca "Copia la diagnostica" alla voce "Chi siamo", l'app colloca la versione dell'app, la piattaforma, la versione del sistema operativo, il tipo di dispositivo, le impostazioni annotate all'avvio e fino a 200 delle voci più recenti — ripulite ancora una volta — negli appunti; dove incollarle lo decide l'utente.

Che cosa viene espressamente rimosso prima che una segnalazione lasci il dispositivo o il server: tutti i cookie, l'intero contenuto di una richiesta, ogni parametro di query il cui nome fa pensare a un segreto (tra cui code, state, token, password, email, key), ogni valore di intestazione il cui nome fa pensare a un segreto, ogni intestazione nella quale i nostri server anteposti inoltrano l'indirizzo IP dell'utente, nonché gli indirizzi e-mail e le stringhe che hanno l'aspetto di un token — anche nel mezzo di un messaggio di errore. Un nome utente, un indirizzo e-mail o un indirizzo IP nella sezione utente della segnalazione vengono sovrascritti prima che la segnalazione venga inviata, e così pure l'identificativo di installazione che l'SDK vi inserisce di propria iniziativa. Tale ripulitura è costruita in modo che, in caso di errore, scarti la segnalazione anziché inviarla non filtrata.

L'applicazione stessa non trasmette alcun indirizzo IP: SendDefaultPii è impostato su false in tutti e quattro i punti, la ripulitura appena descritta sovrascrive comunque tale campo, ed essa rimuove anche le intestazioni nelle quali i nostri server anteposti inoltrano l'indirizzo IP dell'utente al server web e al server API. Le schermate non vengono allegate, e i testi dell'interfaccia utente non vengono inclusi nelle tracce cronologiche; entrambe le cose sono espressamente disattivate. Le fotografie non possono raggiungere una segnalazione di errore, perché il contenuto di una richiesta viene comunque rimosso per intero.

Tracce delle prestazioni sul server: indipendentemente dal fatto che si verifichi un errore, il server web, il server API e il servizio di lettura creano, per una quota di richieste scelta a caso, una traccia delle prestazioni e la trasmettono a Sentry, affinché si possano trovare i punti lenti; le chiamate agli endpoint di stato e le richieste di verifica dei nostri server anteposti ne sono escluse. La quota è del 5 %. Se tuttavia una richiesta proviene dall'app, dal server web o dal server API e appartiene a un'operazione per la quale è già stato deciso lì se essa viene tracciata, il server adotta tale decisione, cosicché una tale operazione viene tracciata in tutte le tappe oppure in nessuna. Una tale traccia contiene gli stessi dati sulla richiesta di una segnalazione di errore del server — il metodo, l'indirizzo richiesto con i suoi parametri di query, ad esempio un termine di ricerca, e le intestazioni della richiesta —, inoltre il modello dell'indirizzo richiesto senza identificativi, il codice di stato della risposta, l'inizio e la durata dell'elaborazione e i messaggi che l'applicazione registra nei log nel frattempo. Si aggiungono le singole fasi di lavoro con la loro durata: le richieste che il server stesso effettua in tale contesto — ad esempio il server web al server API oppure il server API al servizio di accesso —, ciascuna con il metodo, l'indirizzo completo e il codice di stato, e le interrogazioni della banca dati con il loro testo, nel quale i valori inseriti compaiono soltanto come segnaposto e non come i valori stessi. Sul server API la traccia reca l'identificativo pseudonimo dell'account dell'utente, se questi aveva effettuato l'accesso; il server web e il servizio di lettura non trasmettono alcun identificativo. Per il servizio di lettura una traccia riguarda soltanto la chiamata interna da parte del server API; esso non effettua in tale contesto richieste proprie ad altri server né interrogazioni della banca dati, e la fotografia non è mai contenuta nemmeno in una traccia. A ogni traccia delle prestazioni si applica la stessa ripulitura prevista per una segnalazione di errore, sopra descritta; in particolare i cookie e le intestazioni con l'indirizzo IP dell'utente vengono rimossi prima dell'invio. La base giuridica è l'articolo 6, paragrafo 1, lettera f), del GDPR; il legittimo interesse consiste nel gestire l'applicazione in modo rapido e affidabile. Sentry conserva una traccia delle prestazioni completa per un massimo di 90 giorni nel nostro piano; un campione ridotto delle tracce può essere conservato da Sentry fino a 13 mesi.

Sentry non conserva l'indirizzo IP della connessione. All'invio di una segnalazione viene stabilita una connessione Internet; l'indirizzo dal quale è stato effettuato l'invio è pertanto necessariamente noto al soggetto ricevente durante la trasmissione. Sentry offre un'impostazione che scarta tale indirizzo anziché registrarlo, e tale impostazione è attivata per tutti e quattro i progetti — quelli del server API, del server web, del servizio di lettura e dell'app. Una segnalazione di errore non conserva pertanto l'indirizzo. Ciò vale anche per le segnalazioni dell'app, nel cui caso si tratterebbe dell'indirizzo della connessione Internet dell'utente stesso; per il server API, il server web e il servizio di lettura si tratterebbe dell'indirizzo dei nostri server.

Per la trasmissione vale invariato tutto il resto di questa sezione: il destinatario è Functional Software, Inc. d/b/a Sentry, le segnalazioni vanno alla regione di archiviazione sopra indicata e il trasferimento si fonda sulle clausole contrattuali tipo sopra descritte. La ripulitura propria di Sentry sul lato server è attivata nella sua forma di base per tutti e quattro i nostri progetti — quelli del server API, del server web, del servizio di lettura e dell'app; non vi abbiamo aggiunto alcuna regola nostra e non abbiamo rimosso nessuna delle sue regole.

Base giuridica: articolo 6, paragrafo 1, lettera f), del GDPR — per la segnalazione di errore e per l'indirizzo IP nella sua trasmissione allo stesso modo. Il legittimo interesse consiste nel riconoscere e correggere errori e arresti anomali. L'indirizzo non viene trattato per alcuna finalità propria e non viene utilizzato per riconoscere l'utente. È la stessa base sulla quale la sezione 3 tratta l'indirizzo IP che ogni connessione al sito web necessariamente genera. L'utente può opporsi ai sensi dell'articolo 21 del GDPR tramite i dati di contatto indicati nella sezione 2.

Periodo di conservazione: 90 giorni. Per quanto tempo una segnalazione di errore è conservata presso Sentry discende dal piano in cui si trova l'organizzazione. La nostra si trova nel piano Business di Sentry, per il quale Sentry pubblica una conservazione di 90 giorni; nel piano Developer sarebbero 30. Gli allegati seguono l'evento al quale appartengono. Per un singolo progetto può essere impostato un termine più breve, che in tal caso prevale; nessuno dei nostri quattro progetti ne reca uno, cosicché i 90 giorni valgono allo stesso modo per tutti e quattro.

12. Destinatari

I dati personali non vengono venduti e non vengono trasmessi a fini pubblicitari. I destinatari sono attualmente Microsoft Ireland Operations Limited, quale responsabile del trattamento per l'hosting, la banca dati e l'archiviazione dei file nonché — esclusivamente su richiesta espressa dell'utente ai sensi della sezione 8.6 — per la valutazione delle immagini mediante Azure OpenAI, e Twilio Inc. (“SendGrid”) quale responsabile del trattamento per l'invio di e-mail ai sensi della sezione 7.3, compreso il trattamento negli Stati Uniti ivi descritto. Se l'utente ha acconsentito alla misurazione dell'audience ai sensi della sezione 10, per la durata di tale misurazione si aggiunge Google Ireland Limited quale ulteriore responsabile del trattamento; senza il consenso dell'utente essa non riceve nulla. Per l'accesso di cui alla sezione 7.1 è responsabile del trattamento Auth0 / Okta, Inc., e per le segnalazioni di errore di cui alla sezione 11 Functional Software, Inc. d/b/a Sentry; entrambe hanno sede negli Stati Uniti e fondano il trasferimento sulle clausole contrattuali tipo della Commissione europea, come descritto nelle sezioni indicate. I dati degli eventi approvati sono pubblici ai sensi della sezione 8.4; il collegamento con l'account non lo è. Al di là di ciò, una trasmissione avviene soltanto se sussiste un obbligo di legge in tal senso.

13. Periodi di conservazione

• Dati della collezione e fotografie: fino all'eliminazione da parte dell'interessato o fino all'eliminazione dell'account.
• Impostazioni sul dispositivo: si veda la sezione 6.1.
• Dati dell'account presso il fornitore di identità (sezioni 7.1 e 7.2): fino all'eliminazione dell'account, che elimina con esso l'account presso Auth0.
• Misurazione dell'audience: fino a 14 mesi dall'ultima interazione per i dati relativi agli eventi e agli utenti presso Google, 182 giorni per il cookie di consenso sul dispositivo dell'utente — si veda la sezione 10.
• Proposte di eventi: i periodi di conservazione distinti per stato di cui alla sezione 8.4.
• Richieste di assistenza: 24 mesi dopo la chiusura della pratica — si veda la sezione 8.7, anche sul perché il termine decorra dalla chiusura e non dall'arrivo.
• Segnalazioni relative ai contenuti: 24 mesi dopo la decisione — si veda la sezione 8.8, anche sul perché il termine decorra dalla decisione e non dall'arrivo e sul perché una segnalazione non ancora decisa non venga eliminata.
• Azioni dell'amministrazione sugli account utente (registro di audit): 24 mesi dopo l'azione — si veda la sezione 8.9, anche su che cosa resta quando l'account viene eliminato. I dati dell'account e la cronologia degli accessi mostrati all'amministrazione vengono letti in tempo reale presso Auth0 e non vengono memorizzati da BrickDb.
• Fotografie per la lettura del numero del set (sezione 8.5) e per la valutazione della condizione (sezione 8.6): non vengono memorizzate presso BrickDb e vengono scartate al termine della richiesta.
• E-mail inviate: presso BrickDb non viene creata alcuna copia; per i dati di recapito presso il fornitore del servizio di invio si veda la sezione 7.3.
• Registri a livello di infrastruttura: si veda la sezione 3.
• Segnalazioni di errore presso Sentry: 90 giorni — si veda la sezione 11; Sentry non conserva l'indirizzo IP della connessione tramite la quale sono state recapitate.
• Tracce delle prestazioni presso Sentry: complete per un massimo di 90 giorni, come campione ridotto fino a 13 mesi — si veda la sezione 11.

Quando una voce viene eliminata, le fotografie ad essa relative vengono eliminate con essa — comprese le versioni ridimensionate di cui alla sezione 8. Dalle copie di backup i dati eliminati scompaiono alla loro scadenza ordinaria, al più tardi dopo 35 giorni.

14. Diritti degli interessati

Sussistono i seguenti diritti:

• Accesso ai dati trattati (articolo 15 del GDPR),
• Rettifica dei dati inesatti (articolo 16 del GDPR),
• Cancellazione (articolo 17 del GDPR),
• Limitazione di trattamento (articolo 18 del GDPR),
• Portabilità dei dati (articolo 20 del GDPR),
• Opposizione ai trattamenti fondati sull'articolo 6, paragrafo 1, lettera f), del GDPR (articolo 21 del GDPR),
• Revoca di un consenso prestato, con effetto per il futuro (articolo 7, paragrafo 3, del GDPR).

Per esercitarli è sufficiente un messaggio informale all'indirizzo e-mail indicato nella sezione 2.

Il diritto di accesso di cui all'articolo 15 del GDPR può inoltre essere esercitato direttamente e senza inviare alcun messaggio: la pagina dell'account genera una copia completa e leggibile da dispositivo automatico di tutti i dati memorizzati — account e profilo, le collezioni con i loro membri e gli inviti emessi dall'utente, gli esemplari in esse contenuti con le note, i tag, la condizione, i prezzi di acquisto e le note sul venditore, le singole minifigure e i pezzi sfusi, gli esemplari di numeri di riviste e di libri dell'utente, i suoi luoghi di conservazione e quale esemplare si trova in quale di essi, le firme registrate, la lista dei desideri, i contributi dell'utente relativi ai codici delle bustine e ai codici a barre delle scatole, le sue proposte di eventi in ogni stato di moderazione, le elaborazioni in blocco di foto di scatole avviate, le voci del registro di audit dell'amministrazione relative all'account dell'utente (sezione 8.9), ogni fotografia caricata, nonché l'immagine dell'avatar, se l'utente ne ha caricata una.

Che cosa tale copia non contiene, e perché: i dati di accesso presso il fornitore di identità (indirizzo e-mail, password, cronologia degli accessi, secondi fattori registrati) — sono detenuti da Auth0, che fornisce al riguardo un proprio riscontro; gli inviti che altri hanno indirizzato all'indirizzo dell'utente, perché sono dati loro e non dell'utente; la vista dei pezzi derivata dagli esemplari dell'utente, perché non contiene nulla che non si trovi già nella copia; le richieste di assistenza — e precisamente tutte, perché in questa versione nessuna pratica è collegata a un account e non siamo in grado di riconoscere quali siano dell'utente (la sezione 8.7 indica come raggiungerci al riguardo); le note interne relative a una pratica di assistenza, che appartengono a noi e non all'utente (ancora sezione 8.7); la breve annotazione di un'e-mail all'indirizzo di assistenza che non è diventata una pratica, perché non è collegata ad alcun account (sezione 8.7); le segnalazioni relative ai contenuti, che parimenti non sono collegate ad alcun account, e le note che abbiamo scritto nel decidere su una segnalazione relativa a un contenuto dell'utente (sezione 8.8); chi dell'amministrazione ha agito sull'account dell'utente, perché questi sono dati di tale persona e non dell'utente (sezione 8.9); e la notifica in coda relativa a una proposta di evento inviata dall'utente, che contiene soltanto la meccanica di invio e rimanda alla proposta già elencata sopra.

Anche il diritto alla cancellazione di cui all'articolo 17 del GDPR può essere esercitato lì direttamente. La pagina dell'account mostra in anticipo che cosa esattamente viene eliminato; una volta confermata, l'eliminazione viene eseguita immediatamente: la collezione, i luoghi di conservazione, le fotografie (i file stessi, non solo le voci) e l'account di accesso presso il fornitore di identità. Ciò non può essere annullato.

Le eccezioni sono regolate così deliberatamente; per gli eventi vale la sezione 8.4. I contributi dell'utente relativi ai codici delle bustine vengono anonimizzati anziché eliminati: quale figura si trovi in una bustina è un fatto relativo a un prodotto LEGO che altri utenti hanno accertato insieme e su cui fanno affidamento — il contributo resta e il collegamento con la persona è sostituito da un valore casuale appena estratto, per il quale non esistono più alcun account né alcuna corrispondenza (considerando 26 del GDPR). Un esemplare che è stato inserito in una collezione condivisa con altre persone viene parimenti anonimizzato anziché eliminato: eliminarlo toglierebbe agli altri partecipanti la loro voce relativa a un set tenuto in comune. Il numero del set, la quantità e la condizione restano pertanto alla collezione; tutto ciò che vi è di personale viene meno — il nome assegnato dall'utente, le note, i tag, il luogo di conservazione, il prezzo pagato, la stima personale del valore e le fotografie — insieme al collegamento con la persona, sostituito da un valore casuale parimenti appena estratto. Un esemplare in una collezione in cui non c'è nessun altro viene eliminato completamente — non c'è nessuno a cui verrebbe tolto. E le copie di backup continuano a seguire la sezione 13: i dati eliminati ne scompaiono alla loro scadenza ordinaria, al più tardi dopo 35 giorni.

I singoli passaggi, un elenco di ciò che viene eliminato e di ciò che resta in forma anonimizzata, e la via per le persone che non riescono più ad accedere sono riassunti nella pagina Eliminazione dell'account e dei dati. Essa è raggiungibile senza accesso e si limita a riprodurre ciò che è contenuto in questa sezione.

Diritto di proporre reclamo

Indipendentemente da ciò, ai sensi dell'articolo 77 del GDPR sussiste il diritto di proporre reclamo a un'autorità di controllo, segnatamente nello Stato membro in cui l'interessato risiede abitualmente, lavora oppure del luogo ove si è verificata la presunta violazione. L'autorità competente per il titolare del trattamento è:

Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen
Postfach 20 04 44
40102 Düsseldorf
Telefono: +49 211 38424-0
E-mail: poststelle@ldi.nrw.de
www.ldi.nrw.de

15. Obbligo di fornire i dati

Il conferimento dei dati non è prescritto né dalla legge né da un contratto. Senza dati, tuttavia, le funzioni relative alla collezione non possono essere utilizzate in modo sensato; le parti liberamente accessibili del servizio sono disponibili senza alcun dato.

16. Modifiche e versione linguistica facente fede

La presente informativa viene adeguata quando cambiano il trattamento o la situazione giuridica. Fa fede la versione di volta in volta pubblicata qui, con la data di aggiornamento sopra indicata.

Fa fede la versione tedesca. Le versioni in lingua inglese, francese, neerlandese, danese, italiana e spagnola sono traduzioni a titolo informativo e non hanno alcun effetto giuridico autonomo.