Riccardo Mori

Tutto parte da questo articolo apparso su Ars Technica qualche giorno fa. In esso si racconta di come un professore di liceo abbia cercato di riprodurre il film Hellboy 2 sul proiettore della scuola, collegando il suo nuovo MacBook, e che, invece di mostrare il film sullo schermo, il MacBook gli abbia risposto con un messaggio di errore (lo vedete nella figura all’inizio dell’articolo) che tradotto suona così: Non è possibile riprodurre questo film perché è stata rilevata la presenza di un monitor non autorizzato a riprodurre filmati protetti. Provare a scollegare i monitor che non possiedono autorizzazione HDCP.

Il professore ha acquistato quel film su iTunes, e il proiettore Sanyo era collegato al MacBook attraverso un adattatore DisplayPort-VGA. L’uscita era quindi analogica, e la protezione del contenuto digitale. La conseguenza — ovvia, se ci si riflette un istante — non poteva essere differente.

Questa notizia si è diffusa rapidamente, con il classico, frenetico tam-tam del Web, e altrettanto rapidamente si è cominciato a dire di tutto. E spesso, come accade in questi casi, dicendo sciocchezze o quantomeno diffondendo informazioni imprecise.

La prima grossa sciocchezza è affermare che Apple abbia abbracciato finalmente il Trusted Computing, mossa annunciata nel 2006 con l’introduzione dei primi Macintosh basati su processore Intel che contenevano un chip TPM. Ci casca anche Paolo Attivissimo, che nel suo articolo sull’argomento esordisce così:

No, non siamo tornati nel 2006. Apple, però, crede di sì, a quanto pare: perché così come allora aveva infilato nei suoi computer i controversi chip TPM/Palladium con le loro funzioni anticopia, suscitando insurrezioni e boicottaggi, oggi riprova a menomare i diritti dei suoi utenti introducendo sistemi anticopia direttamente a livello hardware nei suoi nuovi portatili. Bella mossa, complimenti.

Credevo che in due anni le cose si fossero chiarite, invece pare che il mito del Trusted Computing nei computer Apple e in Mac OS X sia duro a morire. Voglio citare una fonte che mi pare abbastanza autorevole: Amit Singh, autore di un librone di 1680 pagine sull’architettura di Mac OS X: Mac OS X Internals: A System Approach. È un volume fenomenale per chi sia interessato a esplorare Mac OS X davvero ‘sotto il cofano’; io lo sto leggendo e mi sa che dovrò rinnovare il prestito alla biblioteca del Politecnico di Valencia, data la vastità e la densità degli argomenti (Singh scrive in maniera chiara e leggibile, e questo è sicuramente un bonus). Il libro è aggiornato a Mac OS X Tiger, ma Singh gli ha dedicato un sito Web, Mac OS X Internals: The Book ricco di aggiornamenti e contenuti aggiuntivi. Chi non conosce questo autore o ne dubita l’autorevolezza, dia un’occhiata al suo curriculum. Mi sembra di poter dire che Singh conosca bene sia il Trusted Computing che Mac OS X.

E infatti ha scritto due pezzi che riguardano proprio il Trusted Computing e Mac OS X. Il primo, Trusted Computing for Mac OS X (Trusted Computing per Mac OS X) è dell’ottobre 2006; il secondo, “TPM DRM” In Mac OS X: A Myth That Won’t Die (Il “DRM TPM” in Mac OS X: un mito duro a morire) del gennaio 2008.

Nel primo, Singh scrive (traduzione mia):

I TPM sono malvagi?

Spesso si associa il TCG (prima chiamato TCPA) con il famigerato Progetto Palladium di Microsoft. E altrettanto spesso si utilizza il TCG (Trusted Computing Group) come sinonimo di DRM. Certo, è possibile impiegare un TPM (Trusted Platform Module) per svolgere un compito all’interno di uno schema di DRM, ma da un punto di vista di “craccabilità” non cambia nulla a meno che non vengano messe in atto molte altre contromisure (e il potenziale utilizzo di tali contromisure, questo sì, è motivo di preoccupazione). Si crede anche che un TPM possa in qualche modo prevenire o controllare l’esecuzione di programmi: non può. Un TPM non può partecipare in decisioni riguardanti l’esecuzione — è sempre il software che deve prendere tali decisioni. Il TPM inoltre non conosce e non può conoscere eventuali liste bianche o nere di numeri seriali di computer. Con questo non intendo dire che non vi siano giustificabili preoccupazioni o problematiche per la privacy legate all’utilizzo del Trusted Computing. Uno scenario estremo ed esagerato avverrebbe se un produttore abusasse del TPM: per esempio un produttore che impedisse al cliente di disabilitare il TPM o cambiarne i permessi: questa è una cosa negativa. Tuttavia, così facendo, il produttore dovrebbe andare contro le specifiche [del TPM] […]

Le parti in grassetto non fanno parte dell’enfasi data da Singh nel suo scritto (quella è in corsivo), ma sono aspetti che ho voluto sottolineare io e che riguardano l’argomento del mio post.

Che cos’è una Trusted Platform? Singh:

Una Trusted Platform è una piattaforma di calcolo dotata di un componente “fidato” (trusted): per esempio un componente hardware anti-manomissione incorporato. Solitamente la resistenza in questione riguarda attacchi esterni, e non un attacco da parte del proprietario. Nel caso della piattaforma del Trusted Computing, il TPM è quella parte fidata, che consiste in un componente hardware piuttosto complesso. Si può considerare il TPM come il nucleo di un sottosistema fidato. I suoi costituenti logici comprendono unità funzionali e memoria. Esempi di unità funzionali comprendono un acceleratore hardware SHA‑1 e un generatore di veri numeri casuali. Fra gli esempi di tipi di memoria citiamo la memoria funzionante, attiva, la memoria di archiviazione non volatile, e la EEPROM. La specifica del TPM richiede certe caratteristiche, e in alcuni casi un minimo di risorse specifiche. Nella prossima sezione vedremo l’insieme delle caratteristiche dello specifico TPM utilizzato da Apple.

Più oltre, nella sezione dedicata al chip Infineon TPM1.2 che Apple impiegava (ricordo che questo pezzo risale al 2006), è interessante citare questa parte:

Forse la cosa più importante da notare nella specifica implementazione del TPM di Apple è che il firmware Apple non è TCG-aware, nel senso che non vi sono provvedimenti incorporati da Apple per stabilire una ‘presenza fisica’. Alcune operazioni sensibili del TPM (come lo ‘svuotamento’ del TPM, che lega il TPM a un nuovo proprietario e fa perdere ogni informazione o legame con proprietari precedenti) necessitano di presenza umana per venire stabilite. […] Un altro modo di considerare la ‘non-consapevolezza’ del TCG da parte del firmware, è quello di notare l’assenza di un driver TPM a livello di firmware [nel caso delle macchine Apple].

E ancora:

Le “chiavi del TPM di Apple”

È da molto tempo ormai che i media stanno discutendo sull’ ”Utilizzo del TPM da parte di Apple”. Si sono letti numerosi resoconti di aggressori che hanno aggirato “la protezione TPM di Apple” e che hanno trovato “le chiavi del TPM di Apple”. In ogni caso è importante tener presente che Apple non si serve del TPM. Se siete in possesso di un computer Macintosh dotato di TPM, voi potete sfruttare il TPM per le funzioni per cui è stato progettato, senza alcun effetto collaterale sul normale funzionamento di Mac OS X. Ovviamente per usare il TPM sotto Mac OS X è prima necessario un driver per comandare il dispositivo.

E ancora:

Al momento in cui scriviamo (ottobre 2006), nei modelli di computer Apple più recenti […] non è presente un chip TPM Infineon sulla scheda madre. […]

Nel secondo pezzo, “Il ‘DRM TPM’ in Mac OS X: un mito duro a morire”, Singh riassume:

Apple ha introdotto i primi Macintosh basati su architettura x86 agli inizi del 2006. Anche prima, in molti avevano notato la presenza di un TPM (Trusted Platform Module) nelle macchine del Developer Transition Kit. Dopodiché si sono susseguite molte discussioni e grande scalpore nei confronti del “DRM” che il TPM avrebbe dovuto imporre a livello dell’intero sistema. Tuttavia, il TPM contenuto nei Macintosh basati su architettura x86 commercializzati all’epoca non veniva utilizzato per niente né per fare alcunché.

Nell’ottobre 2006 scrissi in merito al TPM e al suo “utilizzo” in Mac OS X. Dato che Apple non fornì alcun software o driver firmware per il TPM, mi occupai di scrivere e rilasciare un driver TPM open source per Mac OS X. 

A questo punto Singh cita la parte del suo articolo dell’ottobre 2006 che io ho riportato poco sopra, il frammento intitolato “Le ‘chiavi del TPM di Apple’ ”, e continua:

Molti hanno faticato a credere quanto scrissi. Dopotutto Apple stava legando Mac OS X al proprio hardware in qualche maniera; e i primi Mac con architettura x86 incorporavano dei chip TPM. Alcuni hanno — scorrettamente — concluso che il TPM doveva per forza essere coinvolto in tutto questo. Come spesso accade in Internet, tali conclusioni si sono trasformate in miti infallibili. Io a mia volta faticavo a credere a tutte quelle idiozie: avevo creduto che il mio driver TPM open source avesse dissipato i vari miti. Il driver e il software associato permettevano all’utente di fare “qualsiasi cosa” con il TPM: attivarlo, utilizzarlo per i propri obiettivi, perfino disattivarlo — il tutto senza compromettere il funzionamento di Mac OS X. Inoltre il TPM era una componente hardware piuttosto diffusa nei computer moderni e molto spesso giaceva inutilizzato nei computer di molti produttori. Nell’estate del 2006, con l’introduzione del Mac Pro, il chip TPM scomparve del tutto dai Mac con architettura x86. Eppure anche in quel caso i teorici del complotto si inventarono qualche spiegazione, e arrivarono ad affermare che in qualche modo il TPM era stato incorporato nella CPU.

Più o meno nello stesso periodo del 2006, scrissi in merito alla protezione binaria in Mac OS X a livello di Kernel. Come viene spiegato in quell’articolo è in realtà la protezione binaria che lega Mac OS X a una specifica tipologia di hardware. [enfasi mia]

Lo so, il discorso è lungo e intricato, ma il succo è presto riassunto: Apple, pur inserendo nei suoi computer un chip TPM per un breve periodo, non ha mai implementato attivamente alcuna misura restrittiva legata al Trusted Computing né tantomeno ha esercitato alcuna forma di DRM con quel chip. Attivissimo (ma non è il solo) sbaglia quindi 1) nell’associare Palladium al chip TPM, 2) nel parlare di ‘funzioni anticopia’ (mai implementate da Apple nel chip TPM) e 3) nel dire che Apple “menoma i diritti dei suoi utenti introducendo sistemi anticopia direttamente a livello hardware nei suoi nuovi portatili”.

Il perché la 1) e la 2) sono affermazioni imprecise mi pare di averlo spiegato attraverso le informazioni attinte da Singh. Cerco di affrontare adesso l’imprecisione della 3).

Prima che apparisse questa storia su Ars Technica, avevo sentito nominare la famigerata HDCP un paio di volte en passant. Visto il polverone sollevato dall’articolo, sono andato sul sito Digital Content Protection a informarmi un po’. C’è moltissimo materiale lì, e così tanta carne al fuoco da far venire un bel mal di testa. Segnalo però almeno due risorse (in inglese) scritte con uno stile meno protocollare e più divulgativo:

1. White Paper: “HDCP Deciphered” [Lo HCDP decifrato] — DCP, 8/7/2008 (File PDF)
2. “HDCP: What It Is and How To Use It” [HCDP: Che cos’è e come utilizzarlo] — EDN, 18/4/2002. Scritto da Jim Lyle di Silicon Image (File PDF)

Entrambi gli scritti mettono in chiaro una cosa, che lo HDCP non è DRM. Nel primo si legge:

È importante sottolineare una differenza basilare fra HDCP e altre tecnologie di protezione dei contenuti o della gestione dei diritti digitali. I fornitori di contenuti si servono tipicamente di un sistema DRM (Digital Rights Management) per proteggere i loro contenuti. Tali sistemi DRM sono progettati per impedire usi non autorizzati dei contenuti e consentire altri impieghi o imporre altre restrizioni su tali contenuti. Per esempio, un consumatore può scaricare un file audio o video e passarlo a un riproduttore digitale. Quel file è protetto da un DRM che controlla ciò che l’utente può fare con i contenuti del file. Per esempio il DRM potrebbe stabilire se l’utente può effettuare copie del file o riprodurre il contenuto su altri tipi di dispositivi. HDCP non è un DRM. HDCP svolge un ruolo molto specifico: criptare e proteggere i contenuti mentre vengono trasmessi come flusso di informazioni digitali per essere visualizzati.

Nel secondo, Jim Lyle scrive:

HDCP è protezione dei contenuti, non è un sistema di protezione anti-copia (o più esattamente di restrizione della copia). La differenza è sottile, ma estremamente importante. HDCP non è progettato per impedire la copia o la registrazione, né abolisce la registrazione differita (registrazione di programmi TV per poter successivamente mettere in pausa l’immagine o per poterli visionare in un secondo momento). 

In soldoni HDCP è un sistema che garantisce la trasmissione sicura di dati video digitali dal dispositivo A al dispositivo B, e lo fa attraverso un sistema crittografico con scambio di chiavi fra la parte trasmittente e la parte ricevente. (Un po’ come quando ci si collega con un altro Mac via SSH). Se il flusso segue un percorso più complesso, con presenza di un ripetitore, il ripetitore riceve i dati criptati dal trasmittente, li decodifica, li ricodifica e li invia al ricevente. In genere il trasmettitore può essere un computer o un lettore Blu-Ray e il ricevente un monitor, un televisore o un proiettore. Le due parti devono ovviamente poter dialogare attraverso un’interfaccia abilitata alla cifratura attuata da HDCP. Le interfacce sono: HDMI, DVI, DisplayPort, GVIF, UDI, e sono tutte, appunto, digitali.

Tornando allo sfortunato professore, lui si è trovato con un film comprato su iTunes Store e protetto dalla tecnologia HDCP. Inviando i contenuti del film attraverso un percorso impossibile da proteggere da parte di HDCP — che, rilevando la connessione VGA del proiettore, ha impedito la trasmissione perché il proiettore non avrebbe potuto decodificare i contenuti criptati — il professore si è ritrovato quel messaggio di errore.

Una situazione sgradevole, che non piace neanche a me. È irritante aver acquistato un film e non poterlo vedere indiscriminatamente su qualsiasi schermo uno voglia. Ma che Apple abbia implementato la protezione HDCP non è una novità e, seppure non sia certo strombazzato ai quattro venti, la pagina delle specifiche di AppleTV menziona HDCP (Nota 7 a “Porte e Interfacce”: Richiede HDMI con video HDCP o component). HDCP è espressamente nominato nei Termini del Servizio di iTunes Store. Nella sezione 10-xvi, Purchase or Rental of Apple Content si legge:

(xvi) HDMI. An HDCP connection is required in order to view movies (purchased or rented) and TV shows transmitted over HDMI.

Ossia: È richiesta una connessione HDCP per poter guardare film (acquistati o noleggiati) e spettacoli TV trasmessi via HDMI.

Questa parte è assente dai Termini del Servizio di iTunes Store italiano (e spagnolo e di tutti i paesi non-USA) perché fuori dagli Stati Uniti non è possibile acquistare o noleggiare film mediante iTunes Store.

La fruizione di contenuti digitali ad alta definizione sta andando incontro a uno scenario con un numero sempre maggiore di compromessi e lascia l’amaro in bocca il fatto che la decisione su come fruire di tali contenuti sia sempre meno nelle mani dell’utente, specie dell’utente onesto che ha pagato regolarmente il film e che di fatto non può disporne in totale libertà. Però in questo contesto è cruciale, a mio avviso, diffondere informazioni il più possibile corrette e ‘neutrali’, per evitare di prendere fischi per fiaschi e, come si dice in inglese, abbaiare sotto l’albero sbagliato.

Presumo che i disagi come quello vissuto dal professore dell’articolo di Ars Tecnica siano transitori e legati al fatto che ci troviamo in una fase di passaggio fra dispositivi contenenti nuove tecnologie digitali e dispositivi analogici o privi delle componenti necessarie a garantire la visione normale di contenuti protetti. È auspicabile che con il progressivo svecchiamento dei dispositivi, episodi del genere siano sempre meno frequenti.

Prima un aggiornamento al firmware degli iPod nano e classic, poi un aggiornamento di Safari (3.2), poi un aggiornamento di QuickTime che migliora la compatibilità con iChat, poi l’aggiornamento 2.3 per AppleTV, poi l’aggiornamento a Final Cut contenuto nell’update delle applicazioni Pro, per finire in bellezza con iTunes 8.0.2 e, soprattutto l’aggiornamento di iPhone OS 2.2.

Per quanto riguarda quest’ultimo, un articolo su Macworld USA spiega in dettaglio i cambiamenti principali e anche qualche piccola novità non documentata. Riassumendo:

• In Mappe è stata abilitata la vista a livello stradale (Street View), in cui è possibile vedere fotografie del luogo prescelto, se disponibili (un icona arancio lo segnala sul fumetto sopra la puntina). Inoltre ora con Mappe è possibile cercare indicazioni di percorso specificando se si è a piedi, in auto o con i mezzi pubblici (e qui la disponibilità del servizio è limitata, come fa notare l’articolo di Macworld, il che vuol dire che se Google non sa nulla dei servizi pubblici di Firenze, per dire, immagino che questa funzione non servirà a molto). Altre novità in mappe comprendono la visualizzazione degli indirizzi sopra le puntine sulla mappa e la possibilità di inviare per email un link alla mappa del luogo.
• Per quanto riguarda le funzioni del telefono, Apple promette una stabilità ancora maggiore, un minor numero di chiamate interrotte, e una migliorata qualità sonora per la Segreteria (Visual Messaging).
• Per Safari, Apple segnala miglioramenti nella stabilità e nelle prestazioni. In più l’interfaccia grafica è stata leggermente semplificata: ora la barra dell’indirizzo e quella per le ricerche si trovano sulla stessa riga e la parte http:// dell’indirizzo viene nascosta per risparmiare spazio. A prima vista non è che questo cambiamento mi faccia impazzire, ma saprò dire quando installerò l’aggiornamento sul mio iPhone.
• Supporto dei Podcast: ora scaricabili dall’applicazione iTunes e fruibili dall’applicazione iPod. Ora è evidente perché a Podcaster fu negato il permesso di entrare nell’App Store qualche tempo fa.
• Scorciatoie: se avete accumulato pagine e pagine di applicazioni scaricate dall’App Store, siete alla quinta o sesta pagina (o se preferite, schermata) e volete ritornare alla prima, ora non è più necessario ‘sfogliare’ freneticamente verso sinistra — basta premere il pulsante Home e si torna all’inizio.
• Ora è possibile disabilitare la funzione di auto-correzione. Urrà.

Fra le novità non menzionate ufficialmente: adesso in iPhoto le anteprime delle schermate catturate su iPhone appaiono correttamente (prima venivano mostrate come immagini in bianco fino a quando non venivano importate). Quando si elimina un’applicazione dall’iPhone adesso appare una finestra di dialogo che chiede di valutare l’applicazione con un giudizio da una a cinque stellette (come i brani su iTunes). Infine, quando si sta leggendo la scheda informativa di un’applicazione nell’App Store utilizzando iPhone, adesso è possibile visualizzare più di una schermata d’esempio (prima erano visibili solo navigando l’App Store da iTunes sul Mac).

Aspettavo con curiosità questo aggiornamento al software di iPhone, ma devo dire che lascerò passare qualche giorno prima di applicarlo. Voglio leggere prima qualche altro commento e osservazione in rete, non si sa mai.

Adobe strikes deal to bring Flash, AIR to ARM devices | iPhone Central | Macworld: Questo breve articolo di Macworld USA riferisce del recente annuncio di Adobe di aver stretto un accordo con ARM per ottimizzare e portare le tecnologie Flash e AIR su dispositivi controllati da processori ARM. Com’è noto, iPhone ha un cuore ARM.

Insomma, anche se non viene detto esplicitamente, sembra che Adobe stia facendo di tutto per far entrare Flash su iPhone. Ho già riportato un mesetto fa le osservazioni di John Gruber, che condivido al 100%. L’altro giorno alla FNAC ho sentito parte di una conversazione fra due ragazzi che stavano giochicchiando con un iPhone in esposizione. Sembrava quasi uno spot “Mac vs PC” amatoriale, con un ragazzo che, entusiasta, mostrava le meraviglie del dispositivo all’amico, e questi che non faceva altro che ripetere la stessa manfrina: “Sì, certo, bello. Ma…”. Naturalmente, fra le cose che “iPhone non ha”, Flash era in cima alla lista. Non è certamente la prima volta che sento qualcuno lagnarsi della mancanza di Flash su iPhone. Il ‘ragazzo PC’ alla FNAC mi ha stupito per la sua insistenza, come se iPhone fosse un prodotto col potenziale ridotto al 50% per il fatto che non supporta Flash.

Ero tentatissimo di intromettermi nella conversazione chiedendogli che cosa caspita ci trova di tanto bello e completo nell’avere Flash su iPhone. Io assolutamente niente. Apple non sembra granché interessata ad incorporare Flash nell’iPhone e preferisce incoraggiare lo sviluppo di JavaScript. Come fa notare il solito Gruber, nella ultima WWDC si sono tenute parecchie sessioni su HTML, CSS e JavaScript, sottolineando come queste tecnologie siano la via da seguire per sviluppare per iPhone come piattaforma Web mobile, e questo anche prima dell’introduzione di iPhone sul mercato.

Flash su piattaforma Mac ha sempre fatto pena in termini prestazionali, e non c’è paragone con Windows, dove funziona egregiamente. Non possiedo Mac di ultimissima generazione, ma non è possibile né accettabile che Camino o Safari arrivino a prendersi fino all’85% delle risorse della CPU (sui miei Mac con processore G4) ogni volta che caricano un sito con contenuti Flash. A volte mi capita di usufruire di siti per la condivisione di file di grosse dimensioni. Con le dovute eccezioni, molti di questi siti visualizzano parecchia pubblicità dinamica, sia nella stessa pagina in cui si può scaricare il file, sia aprendo nuove finestre con pubblicità Flash a tutto schermo. Questo spesso si traduce in rotellina colorata in Camino o Safari, rallentamento generale del sistema (al punto che devo fare clic almeno 10 volte sul pulsante di chiusura della finestra con contenuti pubblicitari prima che il browser registri la mia richiesta), e in qualche caso nel dover ricorrere a un’uscita forzata del browser se voglio continuare a lavorare o a navigare il Web.

Mi immagino Flash sull’iPhone. Sono sicuro che è negli intenti di Adobe ‘ottimizzarlo’ per dispositivi come iPhone, dove ottimizzare in questo contesto dovrebbe significare minore impatto sui cicli processore (ricordiamoci che un ARM non è un PowerPC G4 o un Intel Core 2 Duo) e minore impatto sulla vita della batteria. Anche ammettendo che riescano a ‘ottimizzare’ in tal senso (e visto come Flash è ‘ottimizzato’ per Mac, lasciatemi nutrire qualche dubbio), il discorso è un altro: Flash sarà mai ‘ottimizzato’ per la navigazione Web su un dispositivo mobile e per la relativa esperienza utente / usabilità?

Se ritorniamo sui problemi di usabilità Web trattati negli ultimi due post, possiamo notare un punto secondo me cruciale nell’analisi di Nielsen-Loranger, ovvero che l’utente quando naviga il Web è impaziente e interessato a ottenere una sola cosa: le informazioni che cerca, nel più breve tempo possibile, e senza troppe deviazioni sulla sua strada. Se portiamo il discorso sulla navigazione Web con un dispositivo mobile, è evidente come questa esigenza dell’utente diventi ancora più pressante, visto che si trova in movimento, fuori sede, lontano da una postazione comoda e magari ha proprio fretta di trovare quel che cerca. Ecco, io vedo Flash in un simile scenario come totale ostacolo all’usabilità del Web su piccolo schermo, nonché alla piacevolezza e scorrevolezza di tale esperienza (per non parlare dell’utilità).

Da quando uso iPhone e navigo il Web da MobileSafari, non posso fare a meno di notare come l’assenza di contenuti Flash sia un beneficio, non una mancanza, all’esperienza di navigazione Web su uno schermo da tre pollici. Non devo aspettare che una presentazione in Flash si carichi (e no, non tutti i siti in Flash hanno un link per saltarla) (e immaginiamoci di dover aspettare il caricamento di un sito in Flash quando ci troviamo in una zona non coperta dal 3G). Non vengo distratto da animazioni a video né si aprono finestre secondarie. Uno potrebbe obiettare dicendo che vanno perse tutte le informazioni presentate come contenuti Flash in molti siti. Sarà, ma per me è un limite del sito Web, non dell’iPhone. È il sito che deve prevedere — per ragioni di usabilità — la possibilità di fruire dei suoi contenuti anche per quelle piattaforme che non supportano Flash o che non lo hanno installato. Se l’unica opzione che mi offre un sito è sorbirmi il suo Flash, io lo salto immediatamente e non ci ritorno. È il sito a perderci, non io che uso iPhone.