Netscape Communications
- 1 year ago
- 0
- 0
Программный интерфейс подключаемых модулей Netscape ( англ. Netscape Plugin Application Programming Interface, NPAPI ) — кросс-платформенная архитектура разработки плагинов , поддерживаемая многими браузерами .
Интерфейс был разработан для семейства браузеров Netscape Navigator , начиная с Netscape Navigator 2.0, и в дальнейшем был реализован многими другими браузерами. Однако Internet Explorer не поддерживает этот интерфейс, начиная с версии 5.5 .
Распространённость интерфейса может быть связана с его простотой. Плагин объявляет работу с определёнными типами данных (например, «audio/mp3») с помощью информации в файле. Когда браузер встречает такой тип данных, он загружает связанный с ним плагин, выделяет пространство на отображаемой странице и посылает ему поток данных . Плагин полностью отвечает за отображаемые данные, включая видео, аудио и другие. Поэтому плагин работает в пределах страницы, в отличие от старых браузеров, которые должны были запустить внешнее приложение для отображения неизвестного типа данных.
API интерфейса требует от каждого браузера реализации незначительного количества функций. Необходимо около 15 функций для инициализации, создания, уничтожения и расположения плагина. NPAPI поддерживает сценарии, печать, полноэкранные плагины, безоконные плагины и потоки данных.
|
В разделе
не хватает
ссылок на источники
(см.
рекомендации по поиску
).
|
Идея плагинов зародилась не в самой Netscape Communications , а в Adobe Systems . Джон Уорнок , исполнительный директор , и , один из основных разработчиков Acrobat Reader , надеялись на возможность использования молодого формата PDF за пределами рабочего стола . Таким образом, вскоре Netscape выпустила первую версию Navigator. Паджет и его коллега-разработчик Eshwar Priyadarshan пытались найти возможность сделать PDF неотъемлемой частью всемирной паутины . Результатом стала живая демонстрация, показанная Уорноку и Джеймсу Кларку , исполнительным директорам Netscape. До этой демонстрации родным форматом для всемирной паутины был только HTML и встроенные на веб-страницы с его помощью изображения. Ссылки на любой другой тип файлов приводили к загрузке этого файла и дальнейшему открытию в соответствующем приложении . В этой демонстрации было показано, как по нажатию на ссылке PDF файла открывалось окно браузера, бесшовно смешивающее отображение PDF и HTML. Кларк поинтересовался, кто же реализовал поддержку в самом Netscape, и с удивлением узнал, что интеграция была реализована без участия Netscape, лишь с небольшим обратным проектированием браузера Netscape.
На следующей неделе компании привнесли эту технологию на рынок, как «Allan’s Hack». Пока Netscape готовился к тесной интеграции с PDF, чего Adobe безусловно дождалась бы, Паджет предложил другой подход, архитектуру плагинов. Разработчики Adobe Гордон Дау (Gordon Dow) и Набель Аль-Шамма (Nabeel Al-Shamma) недавно добавили архитектуру плагинов в Acrobat Reader , используя опыт разработки вне команды Acrobat Reader. Паджет был одним из внешних разработчиков, и он надеялся, что если дать шанс выбора другим компаниям, они выберут возможность расширения интернет-паутины, как это сделала команда Adobe. Кларк и команда были убеждены в этом, поэтому отправились проектировать API, которое будет поддерживать новую архитектуру.
Функция поддержки скриптовых языков позволяет использовать JavaScript код на веб-странице для взаимодействия с плагином. Различные версии Netscape и Mozilla поддерживали эту функциональность с использованием различных технологий: , , и .
Следующие браузеры поддерживают NPAPI-плагины:
Некоторое время Internet Explorer обеспечивал функционирование плагинов, созданных для Netscape. Это было связано с малым количеством реализованных ActiveX функций с помощью файла «plugin.ocx», который выступал в качестве прослойки между ActiveX и NPAPI-плагинами. IE будет загружать ActiveX и использовать определённые для страницы плагины. Microsoft сделала заявление, что использование NPAPI небезопасно (либо небезопасен API, реализованный в IE) и прекратила поддержку, начиная с версии 5.5SP2 .
Популярным заблуждением о технологии NPAPI является его более высокая безопасность, чем у ActiveX. Однако обе технологии запускают машинный код и имеют привилегии родительского процесса. Если родительские процессы обладают одинаковыми привилегиями, то вредоносный NPAPI-плагин и ActiveX могут нанести сходный ущерб. Стоит отметить, что NPAPI-плагины можно сделать более безопасными простой сменой учётной записи пользователя. В общем случае имеется возможность устанавливать и запускать плагины с пользовательскими правами, в то время как использование ActiveX требует административных привилегий. С ограниченными правами плагин не сможет нанести большого вреда [ источник не указан 3320 дней ] .
Другим важным отличием между NPAPI и ActiveX является то, что NPAPI используются только в качестве интернет-плагинов, в то время, как ActiveX используется для широкого круга задач, включая применение в Windows приложениях. Обычный пользователь Windows имеет огромный массив установленных элементов ActiveX, некоторые из которых помечены как «безопасно для скриптов», на самом деле не являющиеся безопасными. Любой из них может быть использован для атаки на компьютер пользователя .
Другим отличием для NPAPI является то, что его реализации (до Mozilla Firefox, см. ниже) не загружали и не устанавливали автоматически недостающие плагины. На месте такого плагина отображалась заглушка. Если пользователь нажимал по ней, то он перенаправлялся на сайт Netscape, где мог подобрать, загрузить и установить подходящий плагин. Безусловно, такая схема неудобна для пользователя, однако она исключает один из векторов атаки , используемый вредоносным ПО .
Internet Explorer считывает из HTML информацию о месте установленного ActiveX. Если элемент ActiveX не установлен, IE самостоятельно загрузит недостающий элемент из указанного источника, затем задаст вопрос о принятии цифровой подписи и нажатии кнопки установки. Подобная схема является рабочей в доверенной инфраструктуре, однако использование методов социальной инженерии может убедить пользователя проигнорировать предупреждения, и повлечь негативные последствия. Большое количество программ-шпионов, рекламного ПО и вредоносных сайтов используют этот вектор атаки . Для уменьшения рисков Microsoft пришлось повысить уровень безопасности по умолчанию для элементов ActiveX и вести списки вредоносных элементов ActiveX.
Mozilla Firefox пытается предложить золотую середину. Если плагин неизвестен, то пользователь будет оповещён и направлен на сайт с безопасным соединением . Пользователь может разрешить Firefox загрузить и установить соответствующий плагин. Эта модель не указывает браузеру места загрузки плагина: плагины загружаются из централизованного места. Это позволяет Firefox предоставлять механизм бесшовной установки надёжных и проверенных плагинов. Данная модель неявно доверяет сервису поиска «хороших» плагинов, что требует повышенной безопасности данного сайта.