|
La '''NPAPI''' (o ''Netscape Plugin Application Programming Interface''') è un 'architettura [[multipiattaforma]] per i [[plugin (informatica)|plugin]] utilizzata da molti [[browser web]]. Sviluppata inizialmente per la famiglia di browser [[Netscape Communications Corporation|Netscape]], a partire da [[Netscape Navigator]] 2.0, è stata implementata in seguito in altri browser, tra cui [[Mozilla Application Suite]], [[Mozilla Firefox]], [[Google Chrome|Chrome]], [[Safari (browser)|Safari]], [[Opera (browser)|Opera]], [[Konqueror]] ede alcune versioni di [[Microsoft]] [[Internet Explorer]]. L'architettura è in via di [[obsolescenza]] e i browser più comuni hanno smesso di supportarla.
Il suo successo può essere in parte attribuito alla sua semplicità. Un plugin dichiara di gestire alcuni tipi [[MIME]] (ad esempio "audio/mp3") mediante le informazioni sui file presentati. Quando il browser incontra tale tipo di contenuti carica il plugin associato, delimita lo spazio all'interno dell'area di visualizzazione da assegnare al plugin, e infine vi trasferisce dati. Al plugin viene, quindi, assegnato il compito di gestire i dati nel modo più opportuno, sia esso visivo, audio o qualunque altra cosa. In questo modo, un plugin viene eseguito nella propria parte di pagina, a differenza dei browser precedenti, che dovevano lanciare un'applicazione esterna per gestire i tipi di contenuto a loro ignoti. ▼
L'[[application programming interface|API]] richiede che ogni plugin implementi e pubblichi un numero abbastanza piccolo di funzioni. Si tratta approsimativamente 15 funzioni in totale per l'inizializzazione, la creazione, la distruzione e il posizionamento dei plugin. La NPAPI supporta anche lo scripting, la stampa, la visualizzazione a schermo intero, i plugin ''windowless'' e lo [[streaming]] dei contenuti. ▼
== Storia ==
L'origine della funzionalità dei plugin Netscape va ricercata non in [[Netscape Communications Corporation|Netscape]], ma in [[Adobe Systems(azienda)|Adobe]]. [[John Warnock]], [[amministratore delegato]] di Adobe, ede [[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 quellaquel 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. ▼▲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, ed [[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.
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 a 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 di programmazione)|Java]], abbiano inciso molto di più sul panorama del web.
▲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 [[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 ad 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 ad 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.
== Caratteristiche ==
<!--
▲IlLa suosua successodiffusione può essere in parte attribuitoattribuita alla sua semplicità. Un plugin dichiara di gestire alcuni tipi [[MIME]] (ad esempio "audio/mp3") mediante le informazioni sui file presentati. Quando il browser incontra tale tipo di contenuti carica il plugin associato, delimita lo spazio all'interno dell'area di visualizzazione da assegnare al plugin, e infine vi trasferisce dati. Al plugin viene, quindi, assegnato il compito di gestire i dati nel modo più opportuno, sia esso visivo, audio o qualunque altra cosa. In questo modo, un plugin viene eseguito nella propria parte di pagina, a differenza dei browser precedenti, che dovevano lanciare un'applicazione esterna per gestire i tipi di contenuto a loro ignoti.
▲L'[[application programming interface|API]] richiede che ogni plugin implementi e pubblichi un numero abbastanza piccolo di funzioni. Si tratta approsimativamenteapprossimativamente di 15 funzioni in totale per l'inizializzazione, la creazione, la distruzione e il posizionamento dei plugin. La NPAPI supporta anche lo scripting, la stampa, la visualizzazione a schermo intero, i plugin ''windowless'' e lo [[streaming]] dei contenuti.
The companies set out the next week to bring what was known as "Allan's Hack" to market. While Netscape was ready to incorporate PDF directly into the browser, and certainly Adobe would have gained from that, Padgett proposed a different approach, a plugin architecture. Adobe engineers Gordon Dow and Nabeel Al-Shamma had recently added a plugin architecture to the Acrobat Reader to leverage the development efforts of engineers outside of the Reader team. Padgett had been a part of that effort, and he expected that if given a chance, other companies (and hopefully teams within Adobe) would choose to extend the Web as well. Clark and team in the end were convinced and set off designing the API that would support the new model. And while PDF was the pioneer, one could argue that later plugins like [[Macromedia Flash]], [[ActiveX control]]s, and [[Java applet]]s have changed the Web landscape far more.
La possibilità di aggiungere degli script ai plugin è una caratteristica che permette al codice JavaScript presente in una pagina di interagire con un plugin. Diverse versioni di Netscape, e in seguito di Mozilla, hanno supportato questa caratteristica utilizzando tecnologie fra loro differenti: LiveConnect, XPConnect e npruntime.
== Scripting support ==
Plugin scriptability is a feature allowing JavaScript code in a web page to interact with the plugin. Various versions of Netscape and then Mozilla supported this feature using different technologies: LiveConnect, XPConnect, and npruntime.
=== LiveConnect ===
WithCon Netscape 4, thela NPAPI wasvenne extendedestesa toper allowpermettere pluginsdi tosfruttare bei scripted.plugin Thistramite degli script. abilityQuesta wasfunzionalità knownvenne aschiamata [[LiveConnect]]. AUn plugin couldpoteva implementimplementare ande returnrestituire anun'istanza instancedi touna aclasse [[Java (programminglinguaggio languagedi programmazione)|Java]] class. TheI publicmetodi methodspubblici exposedesposti byda thisquesta classclasse wasrappresentavano thel'interfaccia scriptablecui interfacepotevano foressere theapplicati plugindegli script. TheLa classclasse couldpoteva beessere calledchiamata fromtramite codice [[JavaScript]], andcome evenanche fromda otheraltre applet Java appletsin runningesecuzione withinall'interno thedella pagepagina, withmentre theil browser marshallingvigilava sulle thechiamate callstra betweeni thediversi variouscontesti contextsd'esecuzione.
Lo svantaggio di LiveConnect risiedeva nell'essere legato a doppio filo con la versione di Java integrata all'interno del browser Netscape. Ciò impediva al browser di utilizzare altri runtime, e appesantiva significativamente il download del browser, dal momento che Java era un componente fondamentale per lo scripting dei plugin.
The disadvantage of LiveConnect was that it was tied heavily to the built-in version of Java within the Netscape browser. This prevented the browser from using other Java runtimes, and added a massive amount of bloat to the browser download size since it required Java to script plugins.
AdditionallyInoltre, la programmazione di LiveConnect wasnon trickyera toaffatto programimmediata. TheLo developersviluppatore haddoveva todefinire defineuna aclasse Java classper for theil plugin, runeseguirla ittramite throughun acompilatore specialiseddi intestazioni Java headerspecializzato compilere andimplementare implementi themetodi native methodsnativi. HandlingLa stringsgestione delle stringhe, exceptionsdelle andeccezioni othere Javadegli objectsaltri fromoggetti Java dal [[C++]] wasera fraughtfrustrante ande certamente non-obvious lapalissiana. ToA compoundpeggiorare mattersle LiveConnectcose usedera anil earlierfatto andche nowLiveConnect obsoleteutilizzava un'API foradesso obsoleta per invokinginvocare nativemetodi C++ callsnativi fromda Java, calledchiamato JRI. TheLa tecnologia JRI technologyè hasstata longda beentempo supplantedsostituita bydalla [[Java Native Interface|JNI]].
=== XPConnect ===
LiveConnect provedsi extremelyrivelò problematicestremamente forproblematico per Mozilla. TheLa dependencydipendenza onda anun obsoleteruntime andJava proprietaryobsoleto Javae runtimeproprietario ande thedall'API JRI APIimplicava meantl'impossibilità thatper LiveConnect never reallydi workedfunzionare.
Mozilla wasstava alreadygià usingutilizzando [[XPCOM]] toper definedefinire thele interfacesinterfacce toa manymolti objectsoggetti implementedimplementati in C++. EachOgni interfaceinterfaccia wasveniva defineddefinita bytramite anun file [[Interface Description Language|IDL]] (Interface Definition Language) file, ande runpassata througha anun compilatore IDL compilerche thatproduceva producedfile headerd'intestazione filese anduna alibreria languageindipendente neutraldal type[[linguaggio librarydi thatprogrammazione]] wasche acostituiva binaryla representationrappresentazione ofbinaria thedell'interfaccia: interface. Thisquest'ultima binarydescriveva describedl'interfaccia, thei interfacemetodi, thei methodsparametri, the parameters,le thestrutture datadati structurese andle enumerationsenumerazioni.
[[XPConnectXPCOM]] usesusa thele typeinformazioni librarysul informationtipo todi marshallibreria callsper betweenregolamentare differentle threadchiamate contextstra anddiversi betweencontesti JavaScriptdi andthread e tra JavaScript nativelycodice compilednativo C++ compilato. AsDal momento che XPConnect isviene usedutilizzato extensivelypesantemente throughoutda Mozilla, itè ismolto extremely robustrobusto, supportedsupportato ande welldocumentato. understood.A Startingpartire withda Netscape 6.1 ande Mozilla 0.9.2, thela NPAPI wasè extendedstata soestesa thatin amodo tale che un plugin couldpotesse returnrestituire un'interfaccia a scriptablese interfacestesso togestibile itselftramite script, andmentre XPConnect wouldsi marshaloccupa callsdi togestire itle fromchiamate a detto plugin da JavaScript ande thedal codice C++ implementation.
ThisCiò removedrese thenon Javapiù dependency,necessaria howeverla theredipendenza areda issuesJava, withma XPConnectprovocò alcuni problemi. In particularparticolare, thepoiché technologyl'implementazione isviene heavilyeffettuata basedutilizzando oncomponenti XPCOM, whichuna istecnologia similarsimile toa [[Component Object Model|Microsoft COM]]., Thuslo thesviluppatore del plugin developerdeve mustsaper begestire familiar withil reference counting, interfacesle interfacce, l'IDL ande socosì forthvia toper implementpoter implementare lo scripting. AdditionallyInoltre, thela dependencydipendenza onda XPCOM ledcomportava toalcuni certainproblemi dynamicnel linkingcollegamento issuesdinamico delle librerie (e.g.ad theesempio il problema della [[fragileclasse base class|fragile base class problem]]) whichche haddovevano toessere berisolti solvedper beforepermettere theal plugin woulddi workfunzionare correctlycorrettamente withcon differentbrowser browsersdifferenti. XPCOM hasè sincestato beenin changedseguito somodificato thatin itmodo suppliestale ada staticallyfornire linkeduna versionversione tocollegata addressstaticamente suchper issues.risolvere Thistali approachproblemi. alsoQuest'approccio requiresrichiede toanche havel'installazione andi un file. xpt filenella installedstessa nextlocazione toscelta theper la DLL, otherwisealtrimenti theil plugin willsembrerà appearfunzionare, tomentre work,la butfunzionalità di scripting won't,non causingsarà confusiondisponibile.
=== npruntimeNPRuntime ===
End of 2004, all major browser companies (except Microsoft) agreed on [http://www.mozilla.org/projects/plugins/npruntime.html npruntime] as an extension to the original NPAPI to supply scripting, via an API that is similar in style to the old C-style NPAPI and is independent of other browser technologies like Java or XPCOM.
Alla fine del 2004, tutti i maggiori sviluppatori di browser (eccetto [[Microsoft]]) scelsero congiuntamente [https://www.mozilla.org/projects/plugins/npruntime.html npruntime] come estensione alla NPAPI originaria per fornire funzionalità di scripting, tramite un'API simile alla vecchia API stile C, e indipendente da altre tecnologie quali Java o XPCOM.
It is supported by the latest generation of Mozilla (1.7.5+) / Firefox, Safari, and Opera. All new plugins should use this API.
npruntime è supportato dalla generazione più recente di browser Mozilla (1.7.5+) / Firefox, Safari ed Opera. Tutti i nuovi plugin dovrebbero usare questa API.
== NPAPI vs ActiveX controls ==
Microsoft developed OLE2 ([[Object linking and embedding|Object Linking and Embedding]]) as a way to create compound documents in applications such as Microsoft Word. For example a word processor document might contain an embedded spreadsheet that could be launched within the confines of the word processor window. OLE2 was based on [[Component Object Model|COM]] and defined interfaces for the various tasks that the container and the object needed to perform. An OLE2 control (sometimes known as an OCX) was a light OLE2 object that could be embedded into a container but did not save large amounts of data or require menus or toolbars to function.
== Confronto tra NPAPI e i controlli ActiveX ==
A control was implemented as a DLL and loaded into the address space of the host container such as [[Visual Basic]]. Earlier versions of Visual Basic used a similar technology called [[Visual Basic Extension]]s but OCX controls were seen as superior. Each OCX implemented a well defined subset of the OLE2 interfaces that the container could use to manipulate the control, such as repositioning it, or to provide information about the container. The OCX also implemented an ''automation interface'' which allowed it to expose methods and properties that could be manipulated, and used mechanism in the other direction to fire events to the container.
Microsoft sviluppò OLE2 ([[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 was extremely complicated and support for COM in [[Microsoft Foundation Classes|MFC]] was poor. So Microsoft rationalised the specification to make it simpler, and rebranded the technology as [[ActiveX]]. Even after simplification controls were still required about 6 core interfaces that must be implemented. In response to this complexity, Microsoft produced wizards, ATL base classes, macros and C++ language extensions to make it simpler to write controls.
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é richiedeva menu o barre degli strumenti per funzionare.
Starting with Internet Explorer 3.0, support was added to host ActiveX controls within HTML content. If the browser encountered a page specifying an ActiveX control via an OBJECT tag (using non-W3C syntax), it would automatically download and install the control with little or no user intervention. This made the web experience "richer" but was perceived as divisive (since controls only ran on Windows) and a security risk due to the lack of user intervention. Microsoft have been forced to introduce security measures to address its shortcomings. For example:
* Control installation packages (Cabinet files and executables) must be digitally signed.
* Controls must explicitly declare themselves safe for scripting.
* The default security settings have become increasingly more stringent.
* Internet Explorer maintains a blacklist of bad controls.
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 automazione'' che permetteva la pubblicazione di metodi e proprietà che potevano essere modificati, e utilizzava un metodo complementare per restituire degli eventi al contenitore.
Internet Explorer did for a time support NPAPI plugins. Plugins that functioned in the Netscape browser also functioned in Internet Explorer. This was due to a small ActiveX control implemented within a "plugin.ocx" file that acted as a shim between the ActiveX based browser and the NPAPI plugin. The IE browser would load the control and use it to host plugins specified within the page. However, Microsoft made the claim that NPAPI plugins (or the IE implementation of the API) was a security issue and dropped support for it in version 5.5 SP2.<ref>Giannandrea, J. ([[September 4]], [[2001]]) [http://www.meer.net/jg/broken-plugins.html Microsoft breaks Web Plugins in Windows XP].</ref>
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 alleviare questa complessità, produsse dei wizard, delle classi base ATL, delle macro e delle estensioni al linguaggio [[C++]] per semplificare la scrittura di controlli.
Future versions of Internet Explorer are more likely to promote a [[.NET Framework|.NET]] based model using a sandbox and finegrained security to control what the control can and cannot do.
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 a introdurre delle misure di sicurezza per porre rimedio alle proprie mancanze. Ad esempio:
A popular misconception concerning the NPAPI technology is that a plugin is somehow inherently safer than an ActiveX control. Both run native machine instructions with the same privileges as the host process. Thus a malicious plugin can do as much damage as a malicious ActiveX control.
* I pacchetti d'installazione dei controlli (file cabinet ed eseguibili) devono recare una [[firma digitale]].
One important difference between NPAPI and ActiveX is that NPAPI is solely for Internet plugins, while ActiveX is used for a wide variety of purposes, including application composition in Visual Basic. A typical Windows user has a vast array of ActiveX controls installed, a number of which are probably marked "safe for scripting", but are not actually secure. Any of these can be used as angles to subvert the user's computer.
* I controlli devono dichiararsi esplicitamente sicuri per attività di scripting.
* Le impostazioni di sicurezza predefinite sono divenute sempre più restrittive.
* Internet Explorer mantiene una "lista nera" dei controlli insicuri.
Internet Explorer, fino a un certo momento, supportò i plugin NPAPI. I plugin che funzionavano nel browser Netscape funzionavano anche su Internet Explorer, grazie a 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ò, a 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]]) [https://archive.is/20071016233843/http://www.meer.net/jg/broken-plugins.html Microsoft non supporta più i plugin su Windows XP].</ref>
Another difference for the NPAPI is that implementations (prior to [[Mozilla Firefox]], see below) did not automatically download or install missing plugins. A missing plugin caused the browser to display a jigsaw piece representing the plugin. If the user clicked on that they were directed to Netscape's plugin finder service where they could manually download and install the plugin for themselves. While this is inconvenient to the user, it is also an important security measure since it prevented the content using the browser as a vector for [[malware]].
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.
In Internet Explorer, the HTML content specifies the ___location where the ActiveX control resides. If the control is not already installed, IE will automatically download and install the control from the specified source, pausing only to show the digital signature to the user and obtain their consent for installation to start. For legitimate controls, this offers a more streamlined installation mechanism with minimal user interaction. However malicious content could convince the user with clever [[Social engineering (computer security)|social engineering]] to ignore warnings (or their better judgement) and install something that might harm their privacy or the machine. A number of [[spyware]], [[adware]] and [[malware]] sites use this mechanism to deploy executable content to machines. Microsoft has had to increase the default security settings for ActiveX and maintain blacklists of malicious controls in an attempt to mitigate this risk.
== Sicurezza ==
[[Mozilla Firefox]] attempts to present a middle ground. If a plugin is missing, it will notify the user that the plugin is missing and initiate a secure connection to a plugin finder service hosted on mozilla.org. The user can permit Firefox to download and install the plugin. This model prevents content specifying where a plugin should be downloaded from – the plugin finder service does. This enables Firefox to present a fairly seamless installation mechanism but limit the service to trusted and compatible plugins from reliable sources. Of course this model implicitly trusts the plugin finder service to return "good" plugins, increasing the security required on the host site.
È molto diffusa la convinzione, a proposito della tecnologia NPAPI, secondo la quale un plugin sia in 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.
== Popular plugins ==
Una differenza significativa tra la NPAPI e 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é 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 astute tecniche di [[ingegneria sociale]], a 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 a 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.
Nell'agosto del 2009 [[Google]] ha pubblicato un nuovo progetto '''Pepper''' chiamato '''Pepper Plugin API (PPAPI)'''<ref>[https://www.chromium.org/nativeclient/getting-started/getting-started-background-and-basics#TOC-Pepper-Plugin-API-PPAPI- Getting Started: Background and Basics - The Chromium Projects<!-- Titolo generato automaticamente -->]</ref>, "una serie di modifiche alla struttura NPAPI per rendere il plugin più sicuro"<ref>[https://code.google.com/p/ppapi/wiki/Concepts Pepper.wiki]</ref>. Questa estensione è stata progettata per facilitare l'attuazione di diversi [[Processo (informatica)|processi]] durante l'esecuzione del [[plugin (informatica)|plugin]]. Inoltre, gli obiettivi del progetto consistono nel fornire un utile quadro di plugins completamente [[cross-platform]]. Gli argomenti presi in considerazione comprendono:
* Uniformità semantica NPAPI per tutti i browser.
* Esecuzione in un processo separato dal renderer / browser stesso.
* Standardizzare il rendering utilizzando un processo di composizione del browser.
* Definizione di eventi standardizzati, e le funzioni 2D di rasterizzazione.
* Primo tentativo di fornire l'accesso grafica 3D.
* Registro di sistema Plugin.
A partire da maggio 2010 il [[browser]] [[open source]] di [[Google]], [[Chromium]], è l'unico browser che supporta il nuovo modello di plugin '''PPAPI'''<ref>[https://www.theregister.co.uk/2010/05/13/google_native_client_sdk/ Google heats up native code for Chrome OS]</ref>, [[Mozilla]] ha annunciato di "non essere interessata a implementare la tecnologia PPAPI al momento"<ref>[https://wiki.mozilla.org/NPAPI:Pepper NPAPI:Pepper - MozillaWiki]</ref>.
Nel febbraio del 2012, [[Adobe (azienda)|Adobe]] ha annunciato che le future versioni di [[Flash Player]] sulla piattaforma [[Linux]] verranno fornite solo tramite questa API, anche se la versione Flash Player 11.2, con il supporto NPAPI, riceverà aggiornamenti di sicurezza per cinque anni<ref>{{Cita web |url=https://blogs.adobe.com/flashplayer/2012/02/adobe-and-google-partnering-for-flash-player-on-linux.html |titolo=Adobe and Google Partnering for Flash Player on Linux « Adobe AIR and Adobe Flash Player Team Blog<!-- Titolo generato automaticamente --> |accesso=3 maggio 2019 |urlarchivio=https://web.archive.org/web/20190519130745/http://blogs.adobe.com/flashplayer/2012/02/adobe-and-google-partnering-for-flash-player-on-linux.html |dataarchivio=19 maggio 2019 |urlmorto=sì }}</ref>. Successivamente, gli sviluppatori di Google hanno rivelato che a partire dalla versione 42 di Chrome i plugin NPAPI non verranno attivati per default (sebbene sarà comunque possibile forzarne l'utilizzo dalla pagina di impostazioni ''chrome://flags''), mentre dalla versione 45 non saranno più supportati<ref>[https://www.chromium.org/developers/npapi-deprecation NPAPI Depreation on chromium.org]</ref><ref>[https://support.google.com/chrome/answer/6213033# Informazioni sulla rimozione dei plugin NPAPI su support.google.com]</ref>.
== Plugin più utilizzati ==
▲* [[ Adobe Acrobat Connect|Adobe Acrobat]]
* [[Adobe Shockwave]]
* [[Adobe Flash Player]]
* [[Windows Media Player]]
== ReferencesNote ==
<references/>
== ExternalCollegamenti linksesterni ==
* {{en}} [httphttps://developer.mozilla.org/en/docs/Plugins PluginDocumentazione per lo sviluppo developmentdi documentationplugin] onsu Mozilla Developer Center
* [http{{cita web|https://www.mozilla.org/projects/plugins/|Homepage Olderper plugindella developmentdocumentazione homepage]più vecchia sullo sviluppo di plugin|lingua=en}}
* [http{{cita web|https://www.mozilla.org/projects/plugins/npruntime.html|Scrittura Writingdi scripting pluginsplugin withusando Mozilla]|lingua=en}}
* {{en}} [httphttps://www.mozilla.org/projects/plugins/plugin-host-control.html AnUn controllo ActiveX controlche thatoffre hostssupporto pluginsper i plugin] – AComponente replacementsostituivo forper plugin.ocx, che thatè wasstato removedrimosso fromda Internet Explorer.
* [{{cita web|url=http://news.com.com/IE+competitors+mull+ActiveX+alternative/2100-1032_3-5253504.html?tag=nl|titolo=I rivali di IE competitorssostengono mullun'alternativa ad ActiveX alternative – CNET]|lingua=en|urlmorto=sì|urlarchivio=https://web.archive.org/web/20130308014956/http://news.com.com/IE+competitors+mull+ActiveX+alternative/2100-1032_3-5253504.html?tag=nl|dataarchivio=8 marzo 2013}}
{{Interfacce web}}
-->
{{Portale|internet|telematica}}
[[Categoria:Web browser]] ▼[[Categoria:Mozilla]]
[[enCategoria:NPAPIBrowser]]
▲[[Categoria: Web browserMozilla]]
[[cs:Netscape Plugin Application Programming Interface]]
| 