Torna alla Home

Informativa Privacy

Versione 2026-09-25 - Aggiornata al 25 settembre 2026

Questa informativa descrive, in base alle funzionalità attualmente implementate in Mangiario, come vengono trattati i dati personali ai sensi del Regolamento (UE) 2016/679 (GDPR). Il testo è stato aggiornato per riflettere anche diario e racconti condivisi, lista delle cose da provare, tag personali, quota personale indicativa, foto multiple e immagini menu riutilizzabili, notifiche web e Android, analytics di prodotto e accesso con Google sul web o tramite l'app Android.

1. Titolare del trattamento e contatti

Il titolare del trattamento dei dati personali relativi al servizio Mangiario è Ressa Servizi di Ressa Gaspare e Francesco Snc, con sede in Via Calamandrei 9 - 74121 Taranto Italy, Partita IVA 02689130736. Per richieste privacy, esercizio dei diritti o chiarimenti sul trattamento puoi usare i riferimenti presenti nella pagina Contatti.

2. Dati trattati nel servizio

Il servizio tratta email, identificativo account, dati profilo e avatar (`profiles`). Per documentare le conferme richieste alla registrazione conserva anche tipo di conferma, versione e percorso del documento, data e ora, origine del flusso, indirizzo IP, user agent e requisito anagrafico dichiarato (`legal_acceptance_events`).

I contenuti dell'archivio (`visits` e `menu_items`) possono comprendere locale, indirizzo, data e ora, link Maps e coordinate, quota personale indicativa, valutazioni, prezzi, note, categorie, piatti e bevande consumati o salvati come cose da provare, racconto personale, foto del diario e fino a tre foto per ogni elemento del menu. Sono inoltre trattati tag personali positivi o negativi (`user_custom_tags`), persone preferite (`favorite_friends`), commenti, metadati di completamento o modifica dei racconti condivisi, relazioni e partecipazioni (`table_friends`, `shared_event_participants`, `shared_experience_events`) e preferenze di classifica (`user_rankings_preferences`, `user_rankings_archived_items`).

Il servizio tratta inoltre letture delle notifiche (`user_dashboard_alert_reads`), iscrizioni Web Push (`push_subscriptions`), token delle notifiche Android (`native_push_tokens`), log tecnici di consegna (`push_delivery_log`), richieste privacy (`dsar_requests`), dati dell'Hub ristoratore (`restaurant_hub_profiles`, inclusi dati business, contatti, orari, menu e immagini) e immagini caricate nello storage (`visit-photos`). Nei flussi protetti, come registrazione e recupero password, viene trattato anche il token tecnico generato da Cloudflare Turnstile.

Se l'utente sceglie l'accesso o la registrazione con Google, Mangiario tratta gli identificativi e i dati profilo resi disponibili da Google e propagati nel sistema di autenticazione Supabase, come email, nome visualizzato, immagine profilo e identificatore univoco dell'account, nella misura resa disponibile dalla configurazione del provider.

3. Finalità del trattamento

Le principali finalità operative sono: autenticazione e sicurezza dell'account; gestione dell'archivio, del diario e dei racconti; lista personale di piatti e bevande da provare; personalizzazione tramite tag, preferiti, statistiche e classifiche; esperienze condivise, commenti e inviti; notifiche in-app e push; visualizzazione delle visite su mappa e normalizzazione dei locali; strumenti amministrativi, Hub ristoratore e gestione delle richieste privacy. I form sensibili possono essere protetti da Cloudflare Turnstile. Alcuni dati aggregati o non immediatamente riconducibili all'utente possono essere usati per fornire insight ai gestori dei locali e migliorare il servizio.

Nel caso di autenticazione con Google, i dati ricevuti dal provider sono usati per creare o riconoscere l'account Mangiario, consentire l'accesso sicuro, popolare il profilo iniziale e registrare le conferme legali richieste al momento della registrazione. Nell'app Android il flusso può avvenire tramite i servizi nativi Google; il token di identità viene poi verificato da Supabase.

Se l'utente attiva le notifiche dispositivo, Mangiario tratta gli identificativi tecnici necessari alla consegna: endpoint e chiavi Web Push per browser compatibili oppure token Firebase Cloud Messaging per l'app Android. Vengono inoltre registrati stato del permesso, piattaforma, user agent, data di ultimo uso e log essenziali con tipo di notifica, chiave di deduplicazione, esito e payload tecnico. Le notifiche possono riguardare inviti, commenti e completamenti o aggiornamenti di esperienze condivise; i dati servono a consegnarle, evitare duplicati, limitarne il numero e disattivare token non più validi.

Quando viene caricata una foto di un piatto o di una bevanda, la prima immagine disponibile può essere associata anche alla voce canonica dello stesso elemento nello stesso locale. In questo modo può essere riutilizzata nell'app come immagine menu condivisa, senza attribuzione pubblica all'autore e senza rendere visibili il racconto personale o gli altri dettagli della visita.

4. Basi giuridiche (impostazione operativa)

Esecuzione del servizio richiesto dall'utente (account e funzionalità principali), adempimento degli obblighi di legge (gestione richieste privacy) e legittimo interesse alla sicurezza tecnica, prevenzione abusi e protezione anti-bot dei form tramite Turnstile. Per le analytics di prodotto non necessarie rese tramite PostHog la base giuridica adottata è il consenso dell'utente, raccolto prima dell'attivazione del tracciamento opzionale. Le notifiche push vengono attivate solo su richiesta dell'utente e possono essere disattivate dal profilo, dal browser o dalle impostazioni del dispositivo.

5. Visibilità dei contenuti

Le visite, la quota personale indicativa, i tag personalizzati, le persone preferite e la lista delle cose da provare restano nel perimetro dell'account. Nei racconti di un'esperienza condivisa sono mostrati solo i contenuti scritti dagli effettivi partecipanti e solo agli utenti che hanno accettato la partecipazione a quella esperienza. Lo stesso perimetro si applica ai relativi commenti e alle foto del diario.

La foto canonica di un elemento del menu costituisce l'eccezione descritta sopra: può essere mostrata ad altri utenti autenticati quando consultano o registrano lo stesso piatto o bevanda nello stesso locale, ma non viene accompagnata dall'identità dell'autore né dai dati della visita di origine. Le pagine di dettaglio delle visite non sono pubbliche per utenti anonimi; dati amministrativi e dell'Hub ristoratore sono accessibili solo ai profili autorizzati.

6. Servizi terzi, analytics e dati di localizzazione

Il progetto integra servizi terzi presenti nel codice: Supabase (autenticazione, database e storage), Google Identity Services sul web e i servizi Google per l'accesso nativo nell'app Android, Cloudflare Turnstile per la verifica anti-bot in sostituzione di hCaptcha, Firebase Cloud Messaging e Firebase Admin per la consegna delle notifiche Android, Brevo per email transazionali e notifiche operative, OpenStreetMap tramite proxy server-side per le tile della mappa interattiva (`/api/map-tiles/...`), Google Maps per link, preview mappe e risoluzione coordinate quando disponibile, Open-Meteo per funzioni meteo/geocoding di fallback e PostHog per analytics di prodotto. Se l'utente accetta le analytics opzionali, PostHog può raccogliere pageview, click, eventi di navigazione, indirizzo IP, identificatori tecnici del browser e dati memorizzati in cookie o storage del browser necessari a riconoscere sessione e stato del consenso. Nella configurazione attuale di deploy il frontend punta a `https://eu.i.posthog.com`, quindi gli eventi analytics vengono inviati a PostHog EU Cloud. In presenza delle funzioni mappa vengono inoltre trattati riferimenti geografici dei locali visitati (indirizzi, coordinate o link Maps). Per protezione tecnica e rate limiting delle tile, il backend può usare temporaneamente l'indirizzo IP della richiesta. Quando l'utente usa Google per autenticarsi, il browser può inoltre comunicare direttamente con endpoint e componenti tecnici di Google necessari al completamento del login; nell'app Android la comunicazione può avvenire tramite i servizi nativi Google installati sul dispositivo. Quando un form è protetto da Turnstile, il browser comunica con Cloudflare per generare e verificare il token anti-bot necessario a completare l'azione. Se attiva le notifiche native nell'app Android, il dispositivo comunica con i servizi Firebase/Google necessari alla registrazione e consegna del token push. Per l'invio tramite Brevo vengono trasmessi l'indirizzo email e i dati strettamente necessari a compilare il messaggio o il modello transazionale, oltre ai metadati tecnici di consegna gestiti dal fornitore. Restano da verificare e mantenere aggiornati DPA, subprocessor list e ulteriori trasferimenti eventualmente previsti dai fornitori terzi.

7. Conservazione e cancellazione

È presente la cancellazione account con rimozione dell'utente auth e pulizia dei file utente nello storage (`/api/privacy/delete-account`), inclusi avatar, foto visite, diario e asset Hub ristoratore. Le righe personali collegate all'account, comprese visite, tag personalizzati e persone preferite, sono eliminate tramite le relazioni del database. È disponibile anche export dati (`/api/privacy/export`) con inclusione delle principali tabelle applicative e dei profili Hub. Le iscrizioni Web Push, i token Android e i log collegati all'utente sono associati all'account e vengono rimossi o disattivati secondo le regole di cancellazione e permesso applicabili. I dati analytics raccolti previo consenso restano soggetti alle impostazioni di conservazione del progetto PostHog e alle policy del fornitore; il consenso può essere revocato in qualsiasi momento dalle preferenze cookie dell'app. Una politica di conservazione centralizzata per ogni categoria di dato è in fase di consolidamento.

8. Diritti dell'interessato

Dal profilo utente è possibile inviare richieste DSAR (accesso, cancellazione, rettifica, portabilità, limitazione, opposizione) e monitorarne stato/deadline. Le richieste sono registrate in `dsar_requests`.

9. Sicurezza

Sono presenti controlli applicativi su autenticazione, policy RLS su tabelle dedicate, verifica origin per mutazioni API sensibili, separazione dei privilegi admin su endpoint riservati, validazioni sugli URL esterni e rate limiting su endpoint come il proxy tile della mappa.