Usare motori di rendering alternativi in Giappone

    A partire da iOS 26.2, in Giappone è possibile utilizzare motori di rendering diversi da WebKit in due tipi di app per utenti: app browser dedicate che offrono un’esperienza di navigazione web completa e app di gestori di motori di rendering che forniscono funzionalità di navigazione in-app tramite un motore di rendering incorporato.

    Apple fornirà alle sviluppatrici e agli sviluppatori autorizzati l’accesso a tecnologie all’interno del sistema che abilitano funzionalità fondamentali e aiutano a offrire motori di rendering moderni ad alte prestazioni. Queste tecnologie includono la compilazione JIT (Just in Time), il supporto per sistemi multiprocesso e altro ancora.

    Tuttavia, i motori di rendering sono costantemente esposti a contenuti non attendibili e potenzialmente dannosi e hanno visibilità sui dati sensibili dell’utente, pertanto sono uno dei vettori più comuni per gli attacchi di cybercriminali. Per proteggere l’utente online, Apple darà l’autorizzazione a implementare motori di rendering alternativi solo a sviluppatori e sviluppatrici che soddisfano criteri specifici e si impegnano a garantire il rispetto dei requisiti vigenti in materia di privacy e sicurezza (inclusi aggiornamenti di sicurezza tempestivi per rispondere alle vulnerabilità e alle minacce emergenti).

    Autorizzazione per motori di rendering web

    Per app browser

    L’autorizzazione per motori di rendering web permette di usare un motore di rendering alternativo nella propria app browser. Se desideri ottenere l’autorizzazione per motori di rendering web, consulta i requisiti riportati qui sotto, poi richiedi l’autorizzazione. Per indicazioni tecniche, consulta:

    Requisiti

    Per essere idonea a usufruire dell’autorizzazione, la tua app deve:

    • Essere distribuita esclusivamente su iOS in Giappone, ad eccezione di qualsiasi altra giurisdizione o piattaforma Apple espressamente consentita da Apple ai sensi del contratto per sviluppatori (inclusi eventuali allegati) per cui hai ottenuto un profilo di autorizzazione corrispondente.
    • Avere l’autorizzazione per essere usata come browser di default.
    • Soddisfare i seguenti requisiti a garanzia dell’utilizzo di un motore di rendering web in grado di fornire funzionalità web di base:
      • Superare una percentuale minima di test disponibili dalle suite di test standard del settore:
        • il 90% dei test di piattaforme web
          • come percentuale del più alto numero di subtest eseguiti da qualsiasi browser sulla prima pagina wpt.fyi; e
          • su un sistema operativo compatibile con la suite di test
        • l’80% di Test262 su un dispositivo iOS, un dispositivo iPadOS o un Mac con chip Apple; e
      • Soddisfare i requisiti della suite di test indicati sopra se la compilazione JIT non è disponibile (ad esempio, se l’utente ha abilitato la modalità di isolamento).
    • Tu e la tua app dovete soddisfare i seguenti requisiti di sicurezza:
      • Garantire processi di sviluppo sicuri, tra cui il monitoraggio della catena di fornitura del software dell’app per individuare eventuali vulnerabilità e l’implementazione di best practice per lo sviluppo di software sicuri (come la creazione di modelli di minaccia per le nuove funzioni in fase di sviluppo).
      • Fornire un URL di una policy di divulgazione delle vulnerabilità pubblicata comprendente: informazioni di contatto che terze parti (che possono includere Apple) possono usare per segnalarti vulnerabilità e problemi di sicurezza, oltre a dettagli su quali informazioni fornire nella segnalazione e quando aspettarsi aggiornamenti allo stato.
      • Garantire di mitigare tempestivamente le vulnerabilità sfruttate all’interno dell’app o del motore di rendering web alternativo utilizzato (ad esempio, 30 giorni per le classi più semplici di vulnerabilità che vengono sfruttate attivamente).
      • Fornire un URL di una pagina web (o più pagine) messa a disposizione del pubblico con informazioni sulle vulnerabilità segnalate che sono state risolte in versioni specifiche del motore di rendering e della versione dell’app associata, se differente.
      • Se il motore di rendering web alternativo utilizza un archivio di certificati root non accessibile tramite l’SDK di iOS, devi rendere pubblicamente accessibile la policy del certificato root e la persona proprietaria di tale policy deve partecipare come browser al Certification Authority/Browser Forum.
      • Dimostrare di supportare i moderni protocolli TLS (Transport Layer Security) per proteggere le comunicazioni con dati in transito quando il motore di rendering è in uso.
    Requisiti di sicurezza del programma

    Devi:

    • Usare linguaggi di programmazione memory-safe, o funzioni che migliorino la sicurezza della memoria in altri linguaggi, all’interno del motore di rendering web alternativo, almeno per tutto il codice che elabora contenuti web.
    • Adottare le più recenti misure di mitigazione dei rischi alla sicurezza (ad esempio, i codici di autenticazione dei puntatori) che rimuovono le classi di vulnerabilità o rendono molto più difficile sviluppare un’exploit chain. È inclusa l’adozione delle seguenti funzionalità:
      • Codici di autenticazione dei puntatori (PAC)
      • Memory Integrity Enforcement (MIE) per tutti gli (i) allocatori forniti dal sistema in qualsiasi estensione di contenuto e (ii) allocatori personalizzati o forniti dal sistema in qualsiasi processo ed estensione della tua app, incluse le estensioni di rete e di rendering grafico
    • Seguire best practice di progettazione e programmazione sicure.
    • Separare i processi per limitare gli effetti dello sfruttamento delle vulnerabilità e convalidare la comunicazione interprocesso (IPC) all’interno del motore di rendering web alternativo.
    • Monitorare tutte le dipendenze di software di terze parti e l’intera catena di fornitura del software della tua app per verificare la presenza di vulnerabilità, eseguendo la migrazione a versioni più recenti qualora una vulnerabilità influisca sulla tua app.
    • Non utilizzare framework o librerie di software che non ricevono più aggiornamenti di sicurezza in risposta a vulnerabilità.
    • Dare priorità alla risoluzione rapida delle vulnerabilità segnalate rispetto allo sviluppo di nuove funzioni. Ad esempio, se il motore di rendering web alternativo fa da tramite tra le funzionalità dell’SDK della piattaforma e i contenuti web per consentire l’utilizzo di API web, su richiesta devi rimuovere il supporto dell’API web se si ritiene presenti vulnerabilità. La maggior parte delle vulnerabilità dovrebbe essere risolta in 30 giorni, ma alcune potrebbero essere più complesse e richiedere più tempo.
    Requisiti di privacy del programma

    Devi:

    • Bloccare i cookie cross-site (ad esempio, cookie di terze parti) di default, a meno che l’utente non decida espressamente di acconsentire, tramite consenso informato, a tali cookie o perché necessario per motivi di compatibilità nel caso di finestre a comparsa che interagiscono con i frame nella finestra di apertura.
    • Partizionare spazi di archiviazione o stati osservabili dai siti web per sito web di primo livello o bloccare l’utilizzo cross-site e l’osservabilità di tali spazi di archiviazione o stati.
    • Evitare di sincronizzare gli stati (inclusi i cookie) tra la tua app e qualsiasi altra app, anche se creata dallo stesso sviluppatore o dalla stessa sviluppatrice, a meno che l’utente non abbia esplicitamente autorizzato la sincronizzazione dello stato, effettuando l’accesso alla tua app e all’altra app oppure utilizzando un altro sistema che preveda un’autorizzazione esplicita.
    • Evitare di condividere gli identificatori di dispositivi con i siti web senza il consenso informato e l’attivazione informata da parte dell’utente.
    • Etichettare le connessioni di rete con le API fornite per generare un Resoconto sulla privacy delle app in iOS (ovunque sia distribuita la tua app).
    • Rispettare gli standard web comunemente adottati che indicano quando richiedere il consenso informato e/o l’attivazione informata da parte dell’utente, come appropriato per le API web (ad esempio, accesso ad appunti o schermo intero), incluse quelle che forniscono accesso a informazioni di identificazione personale.

    Autorizzazione per motori di rendering integrati

    Per la navigazione in-app

    L’autorizzazione per motori di rendering integrati permette di integrare nella propria app un motore di rendering alternativo per fornire esperienze di navigazione in-app. La navigazione in-app è la visualizzazione dinamica di contenuti dal web che sarebbero accessibili e funzionerebbero all’interno di un’app browser web. Non sono inclusi i contenuti integrati nell’app o ottenibili solo tramite la stessa.

    L’obiettivo principale della tua app durante la navigazione in-app deve essere fornire la funzionalità di navigazione web. Durante la navigazione in-app, l’interfaccia utente deve:

    • Coprire gran parte del display, a eccezione dei controlli pertinenti che consentono all’utente finale di controllare la sessione di navigazione.
    • Presentare un pulsante o un link che indirizza al browser di default del sistema per consentire all’utente di aprire un’app browser dedicata per visualizzare i contenuti mostrati al momento.
    • Mostrare il dominio o l’URL dei contenuti di cui viene eseguito il rendering tramite la navigazione in-app.

    Se desideri utilizzare un motore di rendering alternativo nella tua app per offrire esperienze di navigazione in-app, consulta i requisiti riportati di seguito, poi invia la richiesta per ottenere l’autorizzazione per motori di rendering integrati. Dovrai fornire informazioni sul motore di rendering che intendi integrare, incluso il modo in cui soddisfa i requisiti e come può essere integrato in un’app per offrire l’esperienza di navigazione in-app. Per indicazioni tecniche, consulta la sezione Esempi e risorse.

    Requisiti

    Per essere idonea a usufruire dell’autorizzazione, la tua organizzazione deve essere un gestore di motori di rendering. Un gestore di motori di rendering è un’entità che ha la responsabilità primaria di gestire un motore di rendering web distinto.

    • Per responsabilità primaria si intende avere il controllo operativo e la responsabilità ultima sul coordinamento della risposta in caso di individuazione di una vulnerabilità di sicurezza o privacy nel motore di rendering web, nonché sulla relativa risoluzione.
    • Un motore di rendering web distinto è gestito da un’organizzazione o un’entità diversa rispetto a qualsiasi altro motore di rendering web e dispone sia di un’architettura sia di un supporto per le API web che sono sostanzialmente diversi da quelli di qualsiasi altro motore. Generalmente il motore non viene aggiornato per riflettere le modifiche apportate alle sue fork, ma invece trasmette le proprie modifiche alle fork.
    Requisiti dell’app

    La tua app deve:

    • Essere distribuita esclusivamente su iOS in Giappone, ad eccezione di qualsiasi altra giurisdizione o piattaforma Apple espressamente consentita da Apple ai sensi del contratto per sviluppatori (inclusi eventuali allegati) per cui hai ottenuto un profilo di autorizzazione corrispondente.
    • Utilizzare l’autorizzazione esclusivamente per la navigazione in-app.
    • Non avere l’autorizzazione per essere usata come browser di default.
    • Soddisfare i seguenti requisiti a garanzia dell’utilizzo di un motore di rendering web in grado di fornire funzionalità web di base:
      • Superare una percentuale minima di test disponibili dalle suite di test standard del settore:
        • il 90% dei test di piattaforme web
          • come percentuale del più alto numero di subtest eseguiti da qualsiasi browser sulla prima pagina wpt.fyi; e
          • su un sistema operativo compatibile con la suite di test
        • l’80% di Test262 su un dispositivo iOS, un dispositivo iPadOS o un Mac con chip Apple; e
      • Soddisfare i requisiti della suite di test indicati sopra se la compilazione JIT non è disponibile (ad esempio, se l’utente ha abilitato la modalità di isolamento).
    • Soddisfare i seguenti requisiti:
      • Garantire processi di sviluppo sicuri, tra cui il monitoraggio della catena di fornitura del software dell’app per individuare eventuali vulnerabilità e l’implementazione di best practice per lo sviluppo di software sicuri (come la creazione di modelli di minaccia per le nuove funzioni in fase di sviluppo).
      • Fornire un URL di una policy di divulgazione delle vulnerabilità pubblicata comprendente: informazioni di contatto che terze parti (che possono includere Apple) possono usare per segnalarti vulnerabilità e problemi di sicurezza, oltre a dettagli su quali informazioni fornire nella segnalazione e quando aspettarsi aggiornamenti allo stato.
      • Garantire di mitigare tempestivamente le vulnerabilità sfruttate all’interno dell’app o del motore di rendering web alternativo (ad esempio, 30 giorni per le classi più semplici di vulnerabilità che vengono sfruttate attivamente).
      • Fornire un URL di una pagina web (o più pagine) messa a disposizione del pubblico con informazioni sulle vulnerabilità segnalate che sono state risolte in versioni specifiche del motore di rendering e della versione dell’app associata, se differente.
      • Se il motore di rendering web alternativo scelto utilizza un archivio di certificati root non accessibile tramite l’SDK di iOS, devi rendere pubblicamente accessibile la policy del certificato root e la persona proprietaria di tale policy deve partecipare come Certificate Consumer al Certification Authority/Browser Forum.
      • Dimostrare di supportare i moderni protocolli TLS (Transport Layer Security) per proteggere le comunicazioni con dati in transito quando il motore di rendering è in uso.
    Requisiti di sicurezza del programma

    Devi:

    • Usare linguaggi di programmazione memory-safe, o funzioni che migliorino la sicurezza della memoria in altri linguaggi, all’interno del motore di rendering web alternativo, almeno per tutto il codice che elabora contenuti web.
    • Adottare le più recenti misure di mitigazione dei rischi alla sicurezza che rimuovono le classi di vulnerabilità o rendono molto più difficile sviluppare un’exploit chain.
    • Seguire best practice di progettazione, e programmazione, sicure.
    • Monitorare tutte le dipendenze di software di terze parti e l’intera catena di fornitura del software della tua app per verificare la presenza di vulnerabilità, eseguendo la migrazione a versioni più recenti qualora una vulnerabilità influisca sulla tua app.
    • Non utilizzare framework o librerie di software che non ricevono più aggiornamenti di sicurezza in risposta a vulnerabilità.
    • Dare priorità alla risoluzione rapida delle vulnerabilità segnalate rispetto allo sviluppo di nuove funzioni. Ad esempio, se il motore di rendering alternativo fa da tramite tra le funzionalità dell’SDK della piattaforma e i contenuti web per consentire l’utilizzo di API web, su richiesta devi rimuovere il supporto dell’API web se si ritiene presenti vulnerabilità. La maggior parte delle vulnerabilità dovrebbe essere risolta in 30 giorni, ma alcune potrebbero essere più complesse e richiedere più tempo.
    Requisiti di privacy del programma

    Devi:

    • Bloccare i cookie cross-site (ad esempio, cookie di terze parti) di default, a meno che l’utente non decida espressamente di acconsentire, tramite consenso informato, a tali cookie o perché necessario per motivi di compatibilità nel caso di finestre a comparsa che interagiscono con i frame nella finestra di apertura.
    • Partizionare spazi di archiviazione o stati osservabili dai siti web per sito web di primo livello o bloccare l’utilizzo cross-site e l’osservabilità di tali spazi di archiviazione o stati.
    • Evitare di condividere gli identificatori di dispositivi con i siti web senza il consenso informato e l’attivazione informata da parte dell’utente.
    • Etichettare le connessioni di rete con le API fornite per generare un Resoconto sulla privacy delle app in iOS (ovunque sia distribuita la tua app).
    • Rispettare gli standard web comunemente adottati che indicano quando richiedere il consenso informato e/o l’attivazione informata da parte dell’utente, come appropriato per le API web (ad esempio, accesso ad appunti o schermo intero), incluse quelle che forniscono accesso a informazioni di identificazione personale.
    Requisiti aggiuntivi
    • Con ogni invio di file binario, devi inviare il nome e la versione del motore di rendering web alternativo integrato nella tua app.
    • Quando viene resa disponibile una nuova versione del motore di rendering web alternativo integrato nella tua app, devi inviare un aggiornamento all’app con la nuova versione entro quindici (15) giorni di calendario.

    Esempi e risorse

    Questa sezione contiene ulteriori risorse ed esempi per aiutarti a soddisfare i requisiti che consentono di usare un motore di rendering alternativo.

    SDLC (ciclo di vita di sviluppo del software) sicuro

    Molti dei requisiti che devi soddisfare si basano sullo sviluppo di un approccio che mette sicurezza e privacy in primo piano quando introduci nuove funzioni nella tua app. Quando inizi a sviluppare una nuova funzione, devi prima sviluppare un modello di minaccia e un piano per assicurarti che la tua architettura e la versione rilasciata della tua app mitighino i rischi che hai identificato. Esistono molte tecniche utili in questo senso, come l’audit del codice, il fuzzing e i test di scrittura per verificare le proprietà di sicurezza che intendi applicare. Dovresti considerare non attendibili e potenzialmente dannosi tutti i contenuti web.

    Risorse

    Mitigazione dei rischi di sicurezza e sicurezza della memoria

    Devi anche tenere in considerazione quali misure di mitigazione dei rischi alla sicurezza fornisce al momento iOS o iPadOS (come i codici di autenticazione dei puntatori e la funzione Memory Integrity Enforcement) e quali linguaggi di programmazione (o funzioni di linguaggi e compilatori, oltre ad altri strumenti) sono disponibili per mitigare ciascuna minaccia identificata. Ad esempio, Swift è un linguaggio memory-safe di default e può aiutarti a evitare una serie di fonti comuni di vulnerabilità e altri bug software che hanno a che fare con la memoria. Tuttavia, i linguaggi non memory-safe come C++ offrono funzioni con vantaggi in termini di sicurezza della memoria, come std::span. Inoltre, è possibile usare strumenti e opzioni di compilatori, ad esempio -fbounds-safety con C, che consente l’annotazione del codice esistente per mitigare l’accesso alla memoria fuori dai limiti senza richiedere sempre la riscrittura della funzionalità in un linguaggio sicuro per la memoria di default.

    Risorse

    Gestione delle vulnerabilità

    Devi presumere che in un motore di rendering siano sempre presenti vulnerabilità non scoperte o che qualsiasi nuova funzione possa introdurre rischi non voluti. Pertanto, è fondamentale che tu disponga dei processi necessari per rispondere in caso di vulnerabilità, sia che venga scoperta internamente tramite test e attività per garantire sicurezza e privacy o all’interno della catena di fornitura del software, sia che ti venga segnalata da una terza parte.

    Quando fornisci a una terza parte (ad esempio, a chi fa ricerche sulla sicurezza) un percorso per segnalare una vulnerabilità, dovresti considerare quali informazioni dovrebbe fornirti per consentirti di determinare rapidamente la validità e la causa del problema. Dovresti anche prevedere processi per dare priorità alla risoluzione della vulnerabilità e poi rilasciare un aggiornamento, anche se le azioni non rientrano in quello che avevi pianificato.

    È inoltre importante che l’utente possa stabilire rapidamente quali vulnerabilità pubbliche associate a un ID CVE sono state risolte in una determinata versione della tua app (o del motore di rendering alternativo).

    Risorse

    Sicurezza della rete

    L’utilizzo dell’SDK di iOS, in particolare del framework di Network e/o delle API SecTrust, ti alleggerisce il compito di valutare l’attendibilità dei certificati web e di mantenere o utilizzare un archivio di certificati radice attendibili e un programma corrispondenti per il motore di rendering alternativo utilizzato. Se usi un programma, questo dovrebbe fornire informazioni su come un’autorità di certificazione (CA) radice può richiedere di entrare a far parte del programma e anche su come segnalare gli incidenti (come l’esposizione di materiale chiave privato di un’autorità di certificazione radice) in modo che tu possa occupartene.

    Per rispondere alle minacce emergenti e proteggere meglio la privacy e la sicurezza dell’utente, i protocolli utilizzati sul web sono in continua evoluzione. Attualmente, le versioni TLS moderne che dovrebbero essere compatibili con il tuo motore di rendering alternativo e non sono diventate obsolete sono TLS 1.2 e 1.3. Tuttavia, potrebbero cambiare nel tempo. Puoi supportare i protocolli obsoleti nel tuo motore di rendering alternativo, ma dovresti informare l’utente quando visita un sito che supporta solo tali protocolli.

    Risorse

    Contratti