Ответ 1
Извините, но эта проблема, которую вы поставили, по существу неразрешима из-за одной простой проблемы: Вы не можете доверять клиенту. И поскольку клиент может видеть код, тогда вы не можете решить проблему.
Любая информация, поступающая с клиентской стороны, может быть реплицирована другими способами. Это, по сути, та же проблема, что и попытка доказать, что когда пользователь входит в свою учетную запись, на самом деле пользователь не кто-то другой, кто узнал или получил свое имя пользователя и пароль.
Модели интернет-безопасности построены на двух сторонах, которые пытаются общаться без участия третьей стороны, чтобы имитировать, изменять или слушать разговор. Не скрывая исходный код расширения, клиент становится неотличимым от третьего лица (файл среди копий - никак не может определить, какой из них).
Если исходный код скрыт, он становится совершенно другой историей. Теперь пользователь или злонамеренная сторона не имеют доступа к секретам, которые знает настоящий клиент, и применяются все обычные модели безопасности. Тем не менее сомнительно, что Chrome позволит скрывать исходный код в расширениях, поскольку он приведет к другим проблемам безопасности.
Некоторые исходные тексты могут быть скрыты с помощью плагинов NPAPI, как вы заявляли, но он поставляется с ценой, как вы уже знаете.
Возвращаясь к текущему состоянию вещей:
Теперь возникает вопрос о том, что подразумевается под взаимодействием.
Если взаимодействие означает, что, пока пользователь находится на странице, которую вы хотите узнать, является ли это вашим расширением или каким-либо другим, то ближайший, который вы можете получить, - это перечислить вашу страницу в манифесте расширений в разделе приложения, как описано здесь
Это позволит вам спросить на странице, установлено ли приложение с помощью
chrome.app.isInstalled
Это вернет логическое отображение, пока ваше приложение не будет установлено. Команда зарегистрирована здесь
Однако это не решает проблему, так как расширение может быть установлено, но не включено, и есть еще одно расширение, высмеивающее связь с вашим сайтом.
Кроме того, проверка выполняется на стороне клиента, поэтому любая функция, использующая эту проверку, может быть перезаписана, чтобы игнорировать результат этой переменной.
Если, однако, взаимодействие означает создание XMLHttpRequests, вам не повезло. Невозможно выполнить текущие методы из-за видимости исходного кода, как описано выше.
Однако, если он ограничивает юзабилити сайтов авторизованными объектами, я предлагаю использовать обычные средства аутентификации: наличие входа в систему пользователя позволит вам создать сеанс. Этот сеанс будет распространяться на все запросы, сделанные расширением, поэтому вы попадаете в обычный клиентский журнал с такими проблемами доверия, как совместное использование учетной записи и т.д. Этому, конечно же, можно управлять, заставляя пользователя регистрироваться через свою учетную запись Google, что больше всего неохотно для совместного использования и дальнейшего смягчения путем блокировки учетных записей, которые, как представляется, используются неправильно.