NPAPI: differenze tra le versioni

Versione delle 23:33, 10 ago 2007

Versione delle 12:48, 13 ago 2007

Riga 33:

[[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++.

Ciò rese non più necessaria la dipendenza da Java, ma provocò alcuni problemi. In particolare, poichèpoiché l'implementazione viene effettuata utilizzando componenti XPCOM, una tecnologia simile a [[Component Object Model|Microsoft COM]], lo sviluppatore del plugin deve saper gestire il reference counting, le interfacce, l'IDL e così via per poter implementare lo scripting. Inoltre, la dipendenza da XPCOM comportava alcuni problemi nel collegamento dinamico delle librerie (ad esempio il problema della [[classe base fragile]]) che dovevano essere risolti per permettere al plugin di funzionare correttamente con browser differenti. XPCOM è stato in seguito modificato in modo tale da fornire una versione collegata staticamente per risolvere tali problemi. Quest'approccio richiede anche l'installazione di un file .xpt nella stessa locazione scelta per la DLL, altrimenti il plugin sembrerà funzionare, mentre la funzionalità di scripting non sara disponibile.

=== npruntime ===

Riga 45:

Microsoft sviluppò OLE2 ([[Object linking and embedding|Object Linking and Embedding]]) per rendere possibile la creazione di documenti composti in applicazioni quali [[Microsoft Word]]. Per esempio, un documento scritto in un word processor potrebbe contenere un foglio di calcolo incorporato che potrebbe essere lanciato all'interno della finestra del word processor.

OLE2 fu progettato sulla base di [[Component Object Model|COM]], e definiva delle interfacce per i diversi compiti che il contenitore e l'oggetto dovevano portare a termine. Un controllo OLE2 (noto anche come OCX) era un oggetto OLE2 leggero che poteva essere integrato in un contenitore ma che non salvava grandi quantità di dati, nèné richiedeva menu o barre degli strumenti per funzionare.

Un controllo veniva implementato da una DLL, e caricato nello spazio degli indirizzi del contenitore ospite, come ad esempio [[Visual Basic]]. Le prime versioni di Visual Basic utilizzavano una tecnologia simile chiamata [[Visual Basic Extension]], ma i controlli OCX vennero considerati migliori. Ogni OCX implementava un sottoinsieme ben definito delle interfacce OLE2 che il contenitore poteva usare per manipolare il controllo, ad esempio per spostarlo, o per fornire informazioni sul contenitore. L'OCX implementava anche un ''meccanismo di automatione'' che permetteva la pubblicazioni di metodi e proprietà che potevano essere modificati, ed utilizzava un metodo complementare per restituire degli eventi al contenitore.

Riga 64:

== Sicurezza ==

È molto diffusa la convinzione, a proposito della tecnologia NPAPI, secondo la quale un plugin sia in sèsé più sicuro di un controllo ActiveX. Entrambi eseguono istruzioni native per la macchina con gli stessi privilegi del processo ospitante. Perciò un plugin malevolo può danneggiare un sistema tanto quanto un controllo ActiveX insicuro.

Una differenza significativa tra la NPAPAI ed ActiveX è che NPAPI serve soltanto per i plugin Internet, mentre ActiveX viene usato per una grande quantità di scopi, tra cui la creazione delle applicazioni in Visual Basic. L'utente medio di Windows ha un gran numero di controlli ActiveX installati, una parte dei quali è probabilmente dichiarato "sicuro per attività di scripting", pur non essendolo in realtà. Uno qualsiasi di essi può essere usato come testa di ponte per prendere il controllo del computer dell'utente.

Un'altra differenza per la NPAPI è che il software che la implementa (prima di [[Mozilla Firefox]], vedi più in basso) non scarica, nè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 ed 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à ed installerà automaticamente il controllo dalla sorgente specificata, fermandosi solo per mostrare la firma digitale all'utente, ed 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]], ad ignorare gli avvertimenti (od il loro buon senso) ed ad installare qualcosa che potrebbe arrecare danno alla propria [[privacy]] od 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.