Conformità

Copia un prompt di configurazione con i passaggi di installazione e la guida markdown completa per questo plugin.

Capgo è progettato con un'attenzione particolare a privacy, sicurezza e compliance. Questo documento spiega quali dati vengono raccolti, come vengono utilizzati e quali misure sono in atto per proteggere la privacy dei tuoi utenti e garantire la conformità normativa quando usi il servizio live update di Capgo.

Panoramica sulla raccolta dati

Capgo raccoglie solo i dati minimi necessari per fornire efficacemente il servizio live update. La raccolta dati è incentrata sui requisiti operativi, non sul tracciamento degli utenti o su analytics.

Quali dati vengono raccolti

Capgo raccoglie solo i dati necessari per fornire la funzionalità di live updates. Quando la tua app controlla la presenza di aggiornamenti o scarica nuovi bundle, vengono raccolte le seguenti informazioni:

ID dell'app: Un identificatore univoco della tua app, utilizzato per associarla all'account corretto
Versione App Code: La versione code dell'app utilizzata per determinare quali update sono compatibili con l'app
Nome versione app: Il nome della versione dell'app usato per la visualizzazione
Piattaforma: La piattaforma (iOS, Android, Electron) dell'app usata per determinare quali update sono compatibili con l'app
ID dispositivo: Un identificativo dispositivo generato casualmente e specifico per l'app, utilizzato per le operazioni di live update, l'idoneità agli update, la de-duplicazione dei dispositivi attivi mensili, il supporto, la prevenzione degli abusi e l'affidabilità operativa. Non è un ID pubblicitario, non deriva da identificativi hardware e non viene utilizzato per tracciare gli utenti tra app, siti web o clienti Capgo. Su iOS, v7.25.0+ mantiene l'ID tramite reinstallazioni normali usando Keychain. Su Android, usa v7.50.1+ (o v5.50.1+ e v6.50.1+ su quelle linee di release); l'ID viene ripristinato solo se Android Backup/Restore conserva le preferenze dell'app. Disabilitare il backup, escludere quelle preferenze o cancellare i dati dell'app genera un nuovo device ID.
Bundle IDL'identificativo univoco del bundle attualmente installato sul dispositivo
Nome del canale: Il nome del canale selezionato per ricevere gli update
Versione OS: La versione del sistema operativo usata per determinare quali update sono compatibili con il dispositivo
Versione Plugin: La versione del plugin @capgo/capacitor-updater usata per inviare gli update al dispositivo
Paese della richiesta: Quando disponibile, l'ultimo codice valido di due lettere ISO 3166-1 code ricevuto da una richiesta gestita da Cloudflare per il dispositivo. Non è un valore GPS né una posizione fornita dalla tua app.

Dati tecnici aggiuntivi:

Timestamp dei controlli di aggiornamento
Stato di successo/fallimento del download
Stato di installazione del bundle
Eventi e motivi di rollback
Indirizzo IP (per geolocalizzazione e ottimizzazione CDN)

Dettaglio storage endpoint

L'updater può utilizzare fino a tre endpoint configurati per i controlli di aggiornamento, l'auto-assegnazione del canale e le statistiche:

updateUrl (/updates) verifica quale bundle il dispositivo dovrebbe ricevere. Questo endpoint è obbligatorio per gli aggiornamenti live Capgo Cloud.
channelUrl (/channel_self) legge e aggiorna l'assegnazione del canale del dispositivo.
statsUrl (/stats) invia eventi espliciti di ciclo di vita dell'aggiornamento, stato di salute e fallimenti. Imposta statsUrl su una stringa vuota per disabilitare questi report statistici aggiuntivi, oppure puntalo a un endpoint self-hosted o a un proxy che controlli. Un proxy mantiene le statistiche fuori da Capgo solo se termina il payload invece di inoltrarlo. Vedi il contratto dell'endpoint statistico self-hosted.

Disabilitando statsUrl modifica solo il percorso esplicito delle statistiche. /updates e /channel_self serve ancora un ambito stabile, specifico dell'app device_id in modo che Capgo possa decidere quale update e canale applicare e conteggiare i dispositivi attivi mensili per la fatturazione.

Quando statsUrl è abilitato, Capgo può memorizzare:

Registra	Campi memorizzati
Fatturazione MAU	`device_id`, `app_id`, `org_id`, `timestamp`
Inventario dispositivi	`device_id`, `app_id`, `updated_at`, `platform`, `plugin_version`, `os_version`, `version_build`, `version_name`, `is_prod`, `is_emulator`, `default_channel`, `key_id`, opzionale `custom_id`, paese della richiesta opzionale code
Evento stats	`device_id`, `app_id`, `action`, `version_name`, `created_at`

Quando statsUrl è disabilitato ma updateUrl rimane abilitato, Capgo può ancora memorizzare:

Registra	Campi memorizzati
Fatturazione MAU	`device_id`, `app_id`, `org_id`, `timestamp`
Inventario dispositivi	`device_id`, `app_id`, `updated_at`, `platform`, `plugin_version`, `os_version`, `version_build`, `version_name`, `is_prod`, `is_emulator`, `default_channel`, `key_id`, opzionale `custom_id`, paese della richiesta opzionale code
Evento di decisione dell'aggiornamento	`device_id`, `app_id`, `action`, `version_name`, `created_at`; le azioni possono includere `get`, `noNew`, `missingBundle`, `cannotGetBundle`, azioni di blocco per piattaforma/versione ed errori di piano o canale

Per la fatturazione e i grafici della versione nativa, la telemetria runtime può includere anche platform e version_build con l'uso MAU quando lo store di fatturazione distribuito supporta tali campi. Le nuove telemetrie statistiche possono anche includere statistiche opzionali metadata quando l'app lo invia.

Il minimo indispensabile per fatturare i MAU è un identificativo anonimo stabile device_id, app_id, org_id, e un timestamp.

Quali dati NON vengono raccolti

Capgo non raccoglie esplicitamente:

Informazioni personali o credenziali degli utenti
App usage analytics or user behavior data
Contenuti della tua app o dati generati dagli utenti
Dati di localizzazione oltre alla regione geografica generale
ID pubblicitari, identificativi derivati dall'hardware o identificativi utilizzati per tracciare gli utenti tra app, siti web o clienti Capgo
Dati biometrici o dati personali sensibili

Utilizzo e finalità dei dati

I dati raccolti da Capgo vengono utilizzati esclusivamente per:

Funzionamento del servizio

Determinare quali aggiornamenti sono disponibili per specifiche versioni dell'app
Ottimizzazione della distribuzione dei contenuti tramite selezione geografica del CDN
Garantire la compatibilità tra aggiornamenti e capacità del dispositivo
Gestire i rollout degli aggiornamenti e l'assegnazione dei canali

Miglioramento del servizio

Monitorare i tassi di successo degli aggiornamenti e identificare i problemi
Ottimizzare le prestazioni e l'affidabilità del download
Migliorare il sistema di distribuzione degli aggiornamenti
Debug e risoluzione dei problemi di aggiornamento

Sicurezza e integrità

Prevenire gli abusi e garantire la disponibilità del servizio
Convalidare autenticità e integrità degli aggiornamenti
Proteggere da aggiornamenti malevoli o corrotti
Mantenere sicurezza e stabilità del servizio

Archiviazione e conservazione dei dati

Luogo di archiviazione

I bundle di aggiornamento e i metadati sono archiviati su un'infrastruttura cloud sicura
I dati sono distribuiti in più regioni geografiche per le prestazioni
Apps that need EU data residency can set updateUrl a https://plugin.eu.capgo.app/updates, statsUrl a https://plugin.eu.capgo.app/stats, e channelUrl a https://plugin.eu.capgo.app/channel_self. Consulta Ubicazione dati per la configurazione esatta.
Tutte le trasmissioni dei dati sono criptate tramite protocolli standard del settore (HTTPS/TLS)

Conservazione dei dati

I record operativi vengono conservati per l'esercizio del servizio, la sicurezza, la fatturazione e il supporto.
La retention dei bundle è configurabile per ogni app nelle App Settings. I bundle collegati a un canale o a un rollout attivo restano protetti; i bundle inutilizzati diventano rimovibili in base alla regola di retention selezionata per l'app.
I bundle storici e gli asset Delta conservati incidono sull'uso dello storage. La replicazione regionale non moltiplica il consumo di spazio.
I dati personali, se presenti, vengono eliminati in conformità alle leggi applicabili sulla protezione dei dati.

Sicurezza dei dati

Tutti i dati sono crittografati in transito e a riposo
L'accesso ai dati è riservato esclusivamente al personale autorizzato
Vengono eseguiti audit di sicurezza e monitoraggio regolari
Vengono seguite pratiche di sicurezza standard del settore
Certificazione SOC 2: Capgo è attualmente certificato SOC 2 Type II, garantendo i più alti standard di sicurezza, disponibilità e riservatezza. Consulta il nostro stato di conformità su Fidati dell'app capgo.
ISO 27001: Capgo è certificato ISO 27001. Consulta il nostro stato di conformità su Fidati dell'app capgo.
Audit continuo di Code: ogni commit viene auditato automaticamente da SonarCloud per il plugin e backend, garantendo qualità di code, rilevamento delle vulnerabilità di sicurezza e manutenibilità
Scansione vulnerabilità: La scansione di sicurezza aggiuntiva viene eseguita da Snyk per rilevare e risolvere vulnerabilità di sicurezza nelle dipendenze
Sicurezza dell'infrastruttura: La nostra infrastruttura di hosting è monitorata e verificata costantemente tramite controlli di sicurezza dell'hosting
Revisione Code con AIOgni pull request viene revisionata da CodeRabbit AI per individuare potenziali problemi, criticità di sicurezza e mantenere gli standard di qualità di code

Controlli sulla privacy

Per gli sviluppatori di app

Come utente Capgo, hai il controllo su:

Gestione dei canali: Controlla quali update vengono distribuiti a quali utenti
Minimizzazione dei dati: Configura quali informazioni sul dispositivo condividere
Controlli geografici: Gestisci dove vengono distribuiti i tuoi update
Impostazioni di conservazione: Control how long update data is retained

Per gli utenti finali

Gli utenti della tua app beneficiano di:

Raccolta dati minima: Vengono raccolti solo i dati essenziali per la consegna degli update
Nessun tracciamento: Nessun tracciamento cross-app o persistente dell'utente
Trasparenza: Questa privacy policy spiega esattamente quali dati vengono raccolti
Sicurezza: Tutte le trasmissioni dati sono criptate e sicure

Conformità e aspetti legali

Normative sulla protezione dei dati

Capgo è progettato per supportare la conformità alle principali normative sulla protezione dei dati, tra cui:

GDPR (Regolamento generale sulla protezione dei dati)
CCPA (California Consumer Privacy Act)
COPPA (Children’s Online Privacy Protection Act)
Altre leggi regionali sulla privacy applicabili

Documenti di compliance attuali

Il elenco dei sub-processor è l'attuale fonte pubblica di riferimento di Capgo. Viene mantenuta aggiornata ed elenca lo scopo di ogni provider, il luogo del trattamento, il meccanismo di trasferimento e la cronologia delle modifiche.
Il Accordo sul trattamento dei dati è disponibile per la revisione.

Considerazioni per App Store e Play Store

Capgo aggiorna solo il layer web di Capacitor: JavaScript, HTML, CSS e asset statici. Non modifica il binario nativo, i plugin nativi, le autorizzazioni, le entitlement o i metadati dello store. Ogni app viene valutata in base ai propri meriti, quindi Capgo non può garantire l'approvazione individuale su App Store o Play Store.

Usa le live update solo per modifiche al layer web che rispettino le regole dello store e l'ambito dell'app inviata. Pubblica una release nativa standard per funzionalità native o modifiche sostanziali. Revisiona le App Store Review Guidelines di Apple (inclusa la linea guida 2.5.2) e Policy di Google Play su abuso di dispositivi e rete per la tua app prima del rilascio.

Esecuzione remota di code su Apple e Capgo

Capgo non può causare un rifiuto di Apple per esecuzione remota di code. Non è possibile. Capgo non installa né esegue code nativi, librerie dinamiche, framework o plugin, e non può chiamare dlopen, dlsym, performSelector:, o method_exchangeImplementations(). Sostituisce solo JavaScript, HTML, CSS e asset statici all'interno della WebView o del motore JavaScriptCore già compilati nel binario revisionato. Quando l'App Review cita la Guideline 2.5.2 o l'esecuzione remota di code, non attribuire quel rilievo a Capgo. Leggi la notifica di revisione, poi controlla il progetto nativo e gli altri SDK per verificare caricamento di eseguibili o uso di API private. Una vecchia nota di revisione sul dynamic linking nel percorso di auto-hide della splash-screen in Capgo era un bug di quel plugin nativo, non dei live updates, e quel link è stato rimosso.

I team di revisione spesso citano Linee guida 2.5.2 e Apple Developer Program License Agreement sezione 3.3.1(B) insieme, quando ritengono che un'app possa cambiare comportamento dopo l'App Review. Capire entrambi ti aiuta a distinguere un workflow Capacitor live update conforme da un rischio di code remoto. Questa sezione riassume come Capgo si adatti a tali regole pubblicate; non è consulenza legale. Per una trattazione più ampia con schema FAQ, vedi Regole Apple sull'esecuzione remota di code e live updates Capgo.

Cosa proibisce Apple (Guideline 2.5.2)

Linea guida 2.5.2 dell'App Review richiede che le app siano autonome nei propri bundle e stabilisce che le app non possono “scaricare, installare o eseguire code che introduca o modifichi funzionalità o funzioni dell'app, incluse altre app.”

Apple applica questa regola a meccanismi in grado di alterare il comportamento nativo dopo l'approvazione, come:

il download di code nativi compilati, framework o plugin,
la risoluzione dei simboli a runtime (dlopen, dlsym, e API simili),
la chiamata dinamica di metodi Objective-C per raggiungere API private (performSelector:, method_exchangeImplementations(), e pattern correlati), e
l'esecuzione di script remoti il cui scopo è modificare il comportamento dell'app oltre l'esperienza revisionata.

Questi pattern sono ciò che i recenti messaggi di revisione sull'“esecuzione remota di code” prendono di mira. Non descrivono la sostituzione di HTML, CSS e JavaScript all'interno di un WebView incorporato.

Cosa Apple consente ancora (sezione 3.3.1(B) del contratto di licenza)

Il Contratto di licenza Apple Developer Program sezione 3.3.1(B) (“Code eseguibile”) è l’eccezione per il code interpretato. Nel testo attuale del contratto, un’applicazione in genere non può scaricare o installare code eseguibili, tranne quando il code interpretato può essere scaricato se:

non modifica lo scopo principale dell’applicazione fornendo funzionalità incoerenti con lo scopo previsto e pubblicizzato,
non aggira la firma, il sandbox o altre funzionalità di sicurezza del sistema operativo, e
per le app dell’App Store, non crea un negozio o un punto vendita per altre applicazioni.

La shell nativa che invii all'App Store incorpora WebKit o JavaScriptCore. Aggiornare quel web bundle over the air può essere considerato code interpretato ai sensi della sezione 3.3.1(B) solo se il tuo rilascio soddisfa le tre condizioni sopra indicate e il tuo team ha valutato l'altra licenza e le regole di App Review applicabili alla tua app, inclusa la sezione 3.3.1(C) riportata di seguito. Mantenere lo stesso scopo del prodotto è necessario, ma non sufficiente di per sé.

Sezione 3.3.1(C) del License Agreement (funzionalità aggiuntive)

Sezione 3.3.1(C) del Contratto di licenza Apple Developer Program stabilisce che, senza la previa approvazione scritta di Apple o come consentito ai sensi della sezione 3.3.9(A) (In-App Purchase API), un'applicazione non può offrire, sbloccare o abilitare funzionalità aggiuntive tramite meccanismi di distribuzione diversi dall'App Store, dalla Custom App Distribution o da TestFlight.

Il testo pubblicato da Apple non chiarisce come tale clausola interagisca con ogni bundle OTA interpretato-code. Stabilire se uno specifico rilascio Capgo faccia scattare la 3.3.1(C) è una valutazione legale per il tuo team e i tuoi consulenti, non qualcosa che Capgo possa decidere per te.

Quando può applicarsi la Guideline 4.7

Nel novembre 2025, Apple ha chiarito Linea guida 4.7 per le app che offrono mini app, mini giochi, chatbot, plug-in e software simili in HTML5 e JavaScript non incorporati nel binario. La proprietà del software non determina se la 4.7 si applica. Ciò che conta è l'esperienza pubblicizzata: se gli utenti possono scoprire, avviare o passare tra più esperienze software distinte all'interno della tua app, potresti dover rispettare le regole aggiuntive della 4.7 (indicizzazione del catalogo, restrizione per età per contenuti superiori alla tua classificazione e requisiti correlati).

Capgo è un meccanismo di aggiornamento. Di per sé non trasforma la tua app in un host 4.7, ma può distribuire bundle a canali diversi. Se il tuo prodotto si comporta come una piattaforma di mini app o un host white-label, consulta un legale per confermare la tua posizione e le disclosure su App Store prima di fare affidamento sulla distribuzione OTA.

Come Capgo si mappa alle regole

Aspetto	comportamento di Capgo
Nativo eseguibile code	Impossibile. Capgo non installa né esegue nativo code. Le modifiche al nativo code richiedono un nuovo binario per lo store.
Asset web interpretati	JavaScript, HTML, CSS, font, immagini e altri asset statici sostituiscono solo il web bundle in-app.
Scopo principale	Il tuo team controlla lo scope. Rilascia nuove funzionalità significative tramite review, non OTA.
Sicurezza	I bundle sono firmati e possono essere cifrati end-to-end. L'updater non aggira il sandboxing di iOS né la firma di code.
Storefront	I canali Capgo distribuiscono aggiornamenti alla tua app; non pubblicano app di terze parti non correlate all'interno del tuo binario.

Checklist pratica prima di rilasciare un bundle OTA

Verifica che la modifica sia limitata al layer web e corrisponda all'app approvata da Apple.
Verifica che l'aggiornamento non fornisca, sblocchi o abiliti funzionalità o funzioni aggiuntive al di fuori di App Store, Custom App Distribution o TestFlight senza la previa approvazione scritta di Apple o un uso consentito ai sensi della sezione 3.3.9(A) (sezione 3.3.1(C) del contratto di licenza). Stabilire se tale restrizione si applichi al tuo bundle OTA interpretato code spetta alla tua valutazione legale.
Mantieni prezzi, acquisti e flussi regolamentati all'interno di flussi nativi revisionati o conformi allo store.
Carica un nuovo binario quando aggiungi plugin, permessi, entitlement o dipendenze native.
Documenta le live update nelle note di App Review quando i revisori chiedono come l'app si aggiorna.

Capgo aiuta i team a pubblicare fix del layer web in pochi minuti mantenendo i rilasci nativi sul percorso di revisione dello store. Nessun tool di aggiornamento può garantire l'approvazione di Apple. Rivedi le linee guida e i termini di licenza Apple per la tua app e consulta un legale in caso di dubbi.

Le tue responsabilità

In qualità di sviluppatore di app che utilizza Capgo, dovresti:

Includere le informative sulla privacy appropriate nella privacy policy della tua app
Informare gli utenti sull'uso dei servizi live update quando richiesto
Verifica che ogni aggiornamento pianificato rispetti le leggi applicabili e le regole degli store
Implementa i meccanismi di consenso appropriati, se necessario

Privacy by Design

Capgo segue i principi di privacy-by-design:

Minimizzazione dei dati

Raccogli solo i dati strettamente necessari al servizio
Evita di raccogliere informazioni personali o sensibili
Usa dati aggregati e anonimizzati quando possibile

Limitazione della finalità

Usa i dati raccolti solo per le finalità dichiarate
Non riutilizzare i dati per attività non correlate
Mantieni limiti chiari sull’uso dei dati

Trasparenza

Fornisci informazioni chiare sulla raccolta e sull’uso dei dati
Rendi le pratiche di privacy facilmente accessibili e comprensibili
Aggiorna regolarmente la documentazione sulla privacy

Contatti e domande

Se hai domande sulle pratiche di privacy di Capgo o devi segnalare una preoccupazione relativa alla privacy:

Consulta la nostra Privacy Policy completa su capgo.app/privacy
Consulta lo stato di sicurezza e conformità su capgo.app/trust
Contatta il nostro team privacy tramite i canali di supporto
Segnala eventuali problemi relativi alla privacy tramite il nostro contatto sicurezza

Best practice per la privacy

Quando implementi Capgo nella tua app:

Sii trasparente: Informa gli utenti sulla funzionalità live update
Minimizza i dati: Abilita solo le funzionalità di raccolta dati di cui hai davvero bisogno
Implementazione sicura: Segui le best practice di sicurezza nella tua integrazione
Revisioni periodiche: Rivedi periodicamente le tue pratiche di privacy e aggiorna le policy
Controllo utente: valuta di offrire agli utenti opzioni per controllare il comportamento degli aggiornamenti

Seguendo queste pratiche e comprendendo l'approccio alla privacy di Capgo, puoi offrire ai tuoi utenti un'esperienza live update sicura e rispettosa della privacy.

Continua dalla sezione Compliance

Se stai usando Conformità per pianificare sicurezza e compliance, collegalo a Conformità HIPAA per il controllo della telemetria regolamentata, Crittografia per i dettagli di implementazione della crittografia, Security Scanner di Capgo per il workflow del prodotto in Capgo Security Scanner, Sicurezza Capgo per il workflow di prodotto in Capgo Security, Trust Center di Capgo per il workflow di prodotto in Capgo Trust Center, e Sicurezza dell'organizzazione per i dettagli di implementazione in Organization Security.