NPAPI: differenze tra le versioni

Versione delle 15:05, 1 ago 2015

Versione delle 15:06, 1 ago 2015

Riga 4:

L'origine della funzionalità dei plugin Netscape va ricercata non in [[Netscape Communications Corporation|Netscape]], ma in [[Adobe Systems]]. [[John Warnock]], [[amministratore delegato]] di Adobe, e [[Allan Padget]], uno dei principali autori di [[Acrobat Reader]], speravano che il formato di file di punta di Adobe, [[Portable Document Format|PDF]], potesse espandere la propria sfera d'uso ben oltre l'ambito desktop.

Perciò, poco tempo dopo il rilascio della prima versione di Navigator da parte di Netscape, Padgett, insieme all'ingegner Eshwar Priyadrshan, tentò di trovare un modo per rendere PDF parte integrante dell'esperienza del Web. Il risultato fu un'applicazione dimostrativa mostrata a Warnock e a [[James H. Clark|Jim Clark]], amministratore delegato di Netscape. Prima di quella demo, gli unici formati nativi sul Web erano le pagine [[HTML]] e le immagini mostrate al loro interno. I collegamenti ada ogni altro tipo di file comportavano la richiesta all'utente di scaricare il file: fatto ciò, l'utente poteva aprire il file con l'applicazione più appropriata. In quella dimostrazione, tuttavia, quando un utente faceva click su un collegamento ada un file PDF, il file veniva aperto immediatamente all'interno della finestra del browser, mescolando indifferentemente la fruizione di pagine HTML e documenti PDF. Clark chiese con eccitazione chi di Netscape avesse fornito supporto tecnico per rendere possibile l'integrazione, ma scoprì che essa era stata raggiunta senza il coinvolgimento di Netscape, ma con un po' di [[reverse engineering]] del browser.

Le aziende stabilirono di incontrarsi la settimana successiva per trovare il modo di rendere appetibile quello che era conosciuto come "l'hack di Allan" per il mercato. Sebbene Netscape fosse pronta ada incorporare i PDF direttamente all'interno del browser, e certamente Adobe ne avrebbe guadagnato, Padgett propose un approccio diverso: un'architettura basata sui plugin. Gli ingegneri Adobe Gordon Dow e Nabeel Al-Shamma avevano da poco aggiunto un'architettura a plugin ad Acrobat Reader, per ridurre gli sforzi degli sviluppatori di terze parti. Padgett aveva partecipato allo sviluppo, e riteneva che se si fosse fornita l'occasione, altre aziende (e magari altri team all'interno di Adobe) avrebbero scelto di estendere le capacità del Web. Clark e il team alla fine si convinsero, e cominciarono a disegnare l'API che avrebbe dovuto supportare il nuovo modello di sviluppo. Sebbene PDF sia stato il pioniere, si potrebbe affermare che plugin successivi, quali [[Macromedia Flash]] e [[Java (linguaggio)|Java]], abbiano inciso molto di più sul panorama del web.

== Caratteristiche ==

Riga 25:

LiveConnect si rivelò estremamente problematico per Mozilla. La dipendenza da un runtime Java obsoleto e proprietario e dall'API JRI implicava l'impossibilità per LiveConnect di funzionare.

Mozilla stava già utilizzando [[XPCOM]] per definire le interfacce a molti oggetti implementati in C++. Ogni interfaccia veniva definita tramite un file [[Interface Description Language|IDL]] (Interface Definition Language), e passata ada un compilatore IDL che produceva file d'intestazione e una libreria indipendente dal linguaggio di programmazione che costituiva la rappresentazione binaria dell'interfaccia: quest'ultima descriveva l'interfaccia, i metodi, i parametri, le strutture dati e le enumerazioni.

[[XPCOM]] usa le informazioni sul tipo di libreria per regolamentare le chiamate tra diversi contesti di thread e tra JavaScript codice nativo C++ compilato. Dal momento che XPConnect viene utilizzato pesantemente da Mozilla, è molto robusto, supportato e documentato. A partire da Netscape 6.1 e Mozilla 0.9.2, la NPAPI è stata estesa in modo tale che un plugin potesse restituire un'interfaccia a se stesso gestibile tramite script, mentre XPConnect si occupa di gestire le chiamate a detto plugin da JavaScript e dal codice C++.

Riga 47:

OLE2 era molto complicato, e il suo supporto nelle [[Microsoft Foundation Classes|MFC]] era minimo, perciò Microsoft razionalizzò la specifica in modo da semplificarla, e ridenominò la tecnologia in [[ActiveX]]. Anche dopo la semplificazione i controlli richiedevano necessariamente che all'incirca 6 interfacce fondamentali venissero implementate. Microsoft, per allievare questa complessità, produsse dei wizard, delle classi base ATL, delle macro e delle estensioni al linguaggio [[C++]] per semplificare la scrittura di controlli.

A partire da Internet Explorer 3.0 venne aggiunta la possibilità di ospitare controlli ActiveX all'interno di contenuto HTML. Se il browser elaborava una pagina che specificava un controllo ActiveX attraverso un tag OBJECT (e una sintassi non accettata dal [[W3C]]), avrebbe scaricato automaticamente e installato il controllo, con intervento minimo, se non nullo, dell'utente. Ciò rese la fruizione del web "più ricca", ma venne percepita come limitante (dal momento che i controlli funzionavano solo su Windows) e come un rischio per la sicurezza, a causa del mancato intervento dell'utente. Microsoft è stata costretta ada introdurre delle misure di sicurezza per porre rimedio alle proprie mancanze. Ad esempio:

* I pacchetti d'installazione dei controlli (file cabinet ed eseguibili) devono recare una [[firma digitale]].

Riga 54:

* Internet Explorer mantiene una "lista nera" dei controlli insicuri.

Internet Explorer, fino ada un certo momento, supportò i plugin NPAPI. I plugin che funzionavano nel browser Netscape funzionavano anche su Internet Explorer, grazie ada un piccolo controllo ActiveX implementato in un file "plugin.ocx" che svolgeva il compito di intermediario tra il browser e il plugin. Il browser caricava il controllo, e lo utilizzava per ospitare i plugin richiamati in quella pagina. Tuttavia, Microsoft affermò, ada un certo punto, che i plugin NPAPI (o l'implementazione di Internet Explorer dell'API) causavano problemi di sicurezza, e rimosse il supporto nella versione 5.5 SP2 di Internet Explorer.<ref>{{en}} Giannandrea, J. (4 settembre [[2001]]) [http://archive.is/v976f Microsoft non supporta più i plugin su Windows XP].</ref>

Le versioni successive di Internet Explorer, molto probabilmente, introdurranno un modello basato su [[.NET Framework|.NET]] attraverso una sandbox e dei profili di sicurezza appositamente studiati per controllare i diritti assegnati a ciascun controllo.

Riga 66:

Un'altra differenza per la NPAPI è che il software che la implementa (prima di [[Mozilla Firefox]], vedi più in basso) non scarica, né installa automaticamente i plugin mancanti. Un plugin mancante provocava la visualizzazione, all'interno del browser, di un'immagine composta da righe seghettate al posto del plugin. Se l'utente vi faceva click veniva indirizzato alla pagina del servizio di ricerca dei plugin, da dove poteva scaricare e installare manualmente il plugin in piena autonomia. Sebbene si tratti di un inconveniente per l'utente, si tratta di un'importante misura di sicurezza, dal momento che impediva che il contenuto visualizzato utilizzasse il browser come vettore per il [[malware]].

In Internet Explorer, il contenuto HTML specifica il luogo in cui deve risiedere il controllo ActiveX. Se il controllo non è già installato, IE scaricherà e installerà automaticamente il controllo dalla sorgente specificata, fermandosi solo per mostrare la firma digitale all'utente, e ottenerne il consenso all'inizio dell'installazione. Per controlli sicuri, questo approccio offre un meccanismo d'installazione più diretto, e minimizza la necessità di intervento dell'utente. Tuttavia, del contenuto malevolo potrebbe convincere l'utente, attraverso intelligenti tecniche di [[ingegneria sociale]], ada ignorare gli avvertimenti (o il loro buon senso) e a installare qualcosa che potrebbe arrecare danno alla propria [[privacy]] o al proprio sistema. Un gran numero di siti [[spyware]], [[adware]] e [[malware]] usano questi meccanismi per distribuire contenuto eseguibile ai sistemi. Microsoft ha dovuto incrementare il livello di sicurezza predefinito per ActiveX, e deve mantenere delle liste nere di controlli dannosi, nel tentativo di mitigare i rischi.

[[Mozilla Firefox]] tenta di scegliere una via di mezzo. Se un plugin non è presente, notificherà all'utente la situazione e stabilirà una connessione sicura ada un servizio di ricerca dei plugin ospitato su mozilla.org. L'utente può permettere a Firefox di scaricare e installare il plugin. Questo modello impedisce al contenuto visualizzato di specificare da dove debba essere scaricato il plugin - ci penserà il servizio di ricerca. Ciò permette a Firefox di presentare un meccanismo di installazione quasi del tutto immediato, ma limita la possibilità a plugin certificati e compatibili forniti da fonti affidabili. Ovviamente, questo modello considera implicitamente sicuro il risultato restituito dal servizio di ricerca dei plugin, cosa che rende necessario un livello di sicurezza più elevato sul sito che ospita il servizio stesso.

== PPAPI ==