Netscape Plugin Application Programming Interface ( NPAPI ) är en plattformsoberoende plug- in utvecklingsarkitektur som stöds av många webbläsare .
Gränssnittet designades för Netscape Navigator-familjen av webbläsare som börjar med Netscape Navigator 2.0 och har implementerats av många andra webbläsare sedan dess. Internet Explorer stöder dock inte detta gränssnitt sedan version 5.5 [1] [2] [3] .
Förekomsten av gränssnittet kan vara relaterat till dess enkelhet. Insticksprogrammet deklarerar att det fungerar med vissa datatyper (till exempel "ljud/mp3") med hjälp av informationen i filen. När webbläsaren stöter på den här typen av data, laddar den plugin-programmet som är kopplat till det, allokerar utrymme på den renderade sidan och skickar en dataström till den . Plugin-programmet är fullt ansvarigt för de visade data, inklusive video, ljud och annat. Därför fungerar insticksprogrammet på sidan, till skillnad från äldre webbläsare som var tvungna att starta en extern applikation för att visa en okänd datatyp.
Gränssnittets API kräver att varje webbläsare implementerar ett litet antal funktioner. Cirka 15 funktioner behövs för att initiera, skapa, förstöra och lokalisera insticksprogrammet. NPAPI stöder skript, utskrift, helskärmsplugin, fönsterlösa plugins och dataströmmar.
Idén med plug-ins har inte sitt ursprung i själva Netscape Communications , utan från Adobe Systems . John Warnock , VD , och Alan Paget , en av huvudutvecklarna av Acrobat Reader , hoppades att det unga PDF -formatet skulle kunna användas utanför skrivbordet . Således släppte Netscape snart den första versionen av Navigator. Paget och andra utvecklare Eshwar Priyadarshan försökte hitta ett sätt att göra PDF till en integrerad del av World Wide Web . Resultatet blev en livedemo som visades för Warnock och James Clark , Netscapes chefer. Före denna demonstration var det ursprungliga formatet för World Wide Web endast HTML och bilder inbäddade på webbsidor som använde det. Länkar till någon annan filtyp skulle göra att filen laddas ner och öppnas i lämpligt program . Denna demo visade hur ett klick på en länk till en PDF-fil öppnade ett webbläsarfönster som sömlöst blandade visningen av PDF och HTML. Clarke frågade vem som hade implementerat stödet inom Netscape själv, och blev förvånad över att få veta att integrationen gjordes utan Netscapes inblandning, med bara lite omvänd konstruktion av Netscape-webbläsaren.
Veckan därpå tog företag ut tekniken på marknaden som Allans Hack. Medan Netscape förberedde sig för den snäva integrationen med PDF som Adobe skulle ha sett fram emot, kom Paget på ett annat tillvägagångssätt, plugin-arkitekturen. Adobe-utvecklarna Gordon Dow och Nabeel Al-Shamma lade nyligen till en plugin-arkitektur till Acrobat Reader med hjälp av utvecklingserfarenhet utanför Acrobat Reader-teamet. Paget var en av de externa utvecklarna, och han hoppades att om de fick ett val till andra företag skulle de välja att expandera webben, som Adobe-teamet hade gjort. Clarke och teamet var övertygade om detta, så de gav sig i kast med att designa ett API som skulle stödja den nya arkitekturen.
Funktionen för stöd för skriptspråk låter dig använda JavaScript -kod på en webbsida för att interagera med plugin-programmet. Olika versioner av Netscape och Mozilla stödde denna funktion med olika tekniker: LiveConnect , XPConnect och npruntime .
Följande webbläsare stöder NPAPI-plugins:
Ett tag tillhandahöll Internet Explorer plugins byggda för Netscape. Detta berodde på det lilla antalet ActiveX- funktioner som implementerades med "plugin.ocx"-filen, som fungerade som ett lager mellan ActiveX- och NPAPI-plugins. IE kommer att ladda ActiveX och använda plugins som definierats för sidan. Microsoft har gjort ett uttalande om att det är osäkert att använda NPAPI (eller att API:et som implementerats i IE är osäkert) och har avbrutit stödet från och med version 5.5SP2 [1] [2] [3] .
En populär missuppfattning om NPAPI-teknik är att den är säkrare än ActiveX. Båda teknikerna kör dock inbyggd kod och har privilegierna för den överordnade processen. Om de överordnade processerna har samma privilegier kan en skadlig NPAPI-plugin och ActiveX orsaka liknande skada. Det är värt att notera att NPAPI-plugins kan göras säkrare genom att helt enkelt ändra användarkontot . I allmänhet är det möjligt att installera och köra plugins med användarrättigheter, medan användning av ActiveX kräver administrativa rättigheter. Med begränsade rättigheter kommer plugin inte att kunna göra mycket skada .
En annan viktig skillnad mellan NPAPI och ActiveX är att NPAPI:er endast används som Internetplugin, medan ActiveX används för ett brett spektrum av uppgifter, inklusive användning i Windows -applikationer. Den genomsnittliga Windows-användaren har ett stort antal installerade ActiveX-kontroller, av vilka några är märkta "säkra för skript" men är i själva verket inte säkra. Vilken som helst av dem kan användas för att attackera användarens dator [5] .
En annan skillnad för NPAPI är att dess implementeringar (före Mozilla Firefox, se nedan) inte automatiskt laddade ner eller installerade saknade plugins. En stubb visades i stället för en sådan plugin. Om användaren klickade på den omdirigerades han till Netscapes webbplats, där han kunde hitta, ladda ner och installera lämplig plugin. Naturligtvis är ett sådant schema obekvämt för användaren, men det eliminerar en av attackvektorerna som används av skadlig programvara .
Internet Explorer läser information från HTML om platsen för den installerade ActiveX. Om ActiveX-kontrollen inte är installerad kommer IE automatiskt att ladda ner det saknade elementet från den angivna källan, sedan ber dig acceptera den digitala signaturen och klicka på installationsknappen. Detta schema fungerar i en pålitlig infrastruktur, men användningen av sociala ingenjörsmetoder kan övertyga användaren att ignorera varningar och leda till negativa konsekvenser. Ett stort antal spionprogram, adware och skadliga webbplatser använder denna attackvektor . För att minska riskerna var Microsoft tvungen att höja standardsäkerhetsnivån för ActiveX-kontroller och upprätthålla en lista över skadliga ActiveX-kontroller.
Mozilla Firefox försöker erbjuda en medelväg. Om plugin-programmet är okänd kommer användaren att meddelas och dirigeras till mozilla.org med en säker anslutning . Användaren kan tillåta Firefox att ladda ner och installera lämplig plugin. Den här modellen berättar inte för webbläsaren var plugin-programmet ska laddas: plugins laddas från en central plats. Detta tillåter Firefox att tillhandahålla en sömlös installationsmekanism för betrodda och betrodda plugins. Denna modell litar implicit på söktjänsten för "bra" plugins, vilket kräver ökad säkerhet för denna webbplats.