La interfaz de programación de aplicaciones de complementos de Netscape ( NPAPI ) es una arquitectura de desarrollo de complementos multiplataforma compatible con muchos navegadores .
La interfaz fue diseñada para la familia de navegadores Netscape Navigator a partir de Netscape Navigator 2.0 y ha sido implementada por muchos otros navegadores desde entonces. Sin embargo, Internet Explorer no soporta esta interfaz desde la versión 5.5 [1] [2] [3] .
El predominio de la interfaz puede estar relacionado con su simplicidad. El complemento declara que funciona con ciertos tipos de datos (por ejemplo, "audio/mp3") utilizando la información del archivo. Cuando el navegador encuentra este tipo de datos, carga el complemento asociado, asigna espacio en la página renderizada y le envía un flujo de datos . El complemento es completamente responsable de los datos mostrados, incluidos video, audio y otros. Por lo tanto, el complemento funciona dentro de la página, a diferencia de los navegadores más antiguos que tenían que iniciar una aplicación externa para mostrar un tipo de datos desconocido.
La interfaz API requiere que cada navegador implemente una pequeña cantidad de funciones. Se necesitan alrededor de 15 funciones para inicializar, crear, destruir y ubicar el complemento. NPAPI admite secuencias de comandos, impresión, complementos de pantalla completa, complementos sin ventanas y flujos de datos.
La idea de los complementos no se originó con la propia Netscape Communications , sino con Adobe Systems . John Warnock , CEO , y Alan Paget , uno de los principales desarrolladores de Acrobat Reader , esperaban que el joven formato PDF pudiera usarse más allá del escritorio . Así, Netscape pronto lanzó la primera versión de Navigator. Paget y su colega desarrollador Eshwar Priyadarshan estaban tratando de encontrar una forma de convertir PDF en una parte integral de la World Wide Web . El resultado fue una demostración en vivo mostrada a Warnock y James Clark , los directores ejecutivos de Netscape. Antes de esta demostración, el formato nativo de la World Wide Web era solo HTML e imágenes incrustadas en las páginas web que lo usaban. Los enlaces a cualquier otro tipo de archivo harían que ese archivo se descargara y se abriera en la aplicación correspondiente . Esta demostración mostró cómo al hacer clic en un enlace a un archivo PDF se abría una ventana del navegador que combinaba perfectamente la visualización de PDF y HTML. Clarke preguntó quién había implementado el soporte dentro de Netscape y se sorprendió al saber que la integración se realizó sin la participación de Netscape, con solo un poco de ingeniería inversa del navegador de Netscape.
La semana siguiente, las empresas lanzaron la tecnología al mercado como Allan's Hack. Mientras Netscape se preparaba para la estrecha integración con PDF que Adobe esperaba con ansias, Paget ideó un enfoque diferente, la arquitectura de plug-in. Los desarrolladores de Adobe, Gordon Dow y Nabeel Al-Shamma, agregaron recientemente una arquitectura de complemento a Acrobat Reader utilizando la experiencia de desarrollo fuera del equipo de Acrobat Reader. Paget era uno de los desarrolladores externos y esperaba que, si se les daba la opción a otras empresas, optarían por expandir la web, como había hecho el equipo de Adobe. Clarke y el equipo estaban convencidos de esto, por lo que se propusieron diseñar una API que fuera compatible con la nueva arquitectura.
La función de soporte de lenguaje de secuencias de comandos le permite usar código JavaScript en una página web para interactuar con el complemento. Varias versiones de Netscape y Mozilla admitieron esta funcionalidad utilizando diferentes tecnologías: LiveConnect , XPConnect y npruntime .
Los siguientes navegadores admiten complementos NPAPI:
Durante un tiempo, Internet Explorer proporcionó complementos creados para Netscape. Esto se debió a la pequeña cantidad de funciones ActiveX implementadas mediante el archivo "plugin.ocx", que actuó como una capa entre los complementos ActiveX y NPAPI. IE cargará ActiveX y usará los complementos definidos para la página. Microsoft ha declarado que el uso de NPAPI no es seguro (o la API implementada en IE no es segura) y ha suspendido el soporte a partir de la versión 5.5SP2 [1] [2] [3] .
Una idea errónea popular sobre la tecnología NPAPI es que es más segura que ActiveX. Sin embargo, ambas tecnologías ejecutan código nativo y tienen los privilegios del proceso principal. Si los procesos principales tienen los mismos privilegios, entonces un complemento NPAPI malicioso y ActiveX pueden causar un daño similar. Vale la pena señalar que los complementos NPAPI se pueden hacer más seguros simplemente cambiando la cuenta de usuario . En general, es posible instalar y ejecutar complementos con derechos de usuario, mientras que el uso de ActiveX requiere privilegios administrativos. Con derechos limitados, el complemento no podrá hacer mucho daño .
Otra diferencia importante entre NPAPI y ActiveX es que los NPAPI solo se usan como complementos de Internet, mientras que ActiveX se usa para una amplia gama de tareas, incluido el uso en aplicaciones de Windows . El usuario promedio de Windows tiene una gran variedad de controles ActiveX instalados, algunos de los cuales están etiquetados como "seguros para secuencias de comandos", pero de hecho no son seguros. Cualquiera de ellos puede usarse para atacar la computadora del usuario [5] .
Otra diferencia para NPAPI es que sus implementaciones (anteriores a Mozilla Firefox, ver más abajo) no descargaban ni instalaban automáticamente los complementos faltantes. Se mostró un código auxiliar en lugar de dicho complemento. Si el usuario hacía clic en él, era redirigido al sitio web de Netscape, donde podía encontrar, descargar e instalar el complemento adecuado. Por supuesto, tal esquema es inconveniente para el usuario, pero elimina uno de los vectores de ataque utilizados por el malware .
Internet Explorer lee información HTML sobre la ubicación del ActiveX instalado. Si el control ActiveX no está instalado, IE descargará automáticamente el elemento faltante de la fuente especificada, luego le pedirá que acepte la firma digital y haga clic en el botón de instalación. Este esquema funciona en una infraestructura confiable, pero el uso de métodos de ingeniería social puede convencer al usuario de ignorar las advertencias y tener consecuencias negativas. Una gran cantidad de spyware, adware y sitios maliciosos utilizan este vector de ataque . Para mitigar los riesgos, Microsoft tuvo que elevar el nivel de seguridad predeterminado para los controles ActiveX y mantener una lista de controles ActiveX maliciosos.
Mozilla Firefox está tratando de ofrecer un término medio. Si el complemento es desconocido, el usuario será notificado y dirigido a mozilla.org con una conexión segura . El usuario puede permitir que Firefox descargue e instale el complemento apropiado. Este modelo no le dice al navegador dónde se debe cargar el complemento: los complementos se cargan desde una ubicación central. Esto permite que Firefox proporcione un mecanismo de instalación perfecto para complementos confiables y de confianza. Este modelo confía implícitamente en el servicio de búsqueda de complementos "buenos", lo que requiere una mayor seguridad de este sitio.