Пользователи операционной системы Debian выявили факт скрытой загрузки и установки в Chromium бинарного модуля с закрытым исходным кодом. Как вскоре выяснилось, этот модуль отвечает за работу голосового помощника "Окей, Гугл". Мы постарались собрать в этом посте все основные претензии к разработчикам браузера, а также дождались официальных комментариев.
Что случилось?
Один из пользователей Debian опубликовал багрепорт, в котором пожаловался на скрытую установку модуля "Chrome Hotword Shared Module" в браузере Chromium (который, к слову, распространялся через родной Debian-репозиторий силами сообщества Debian). Загрузка и установка происходила в обязательном порядке сразу же после первого запуска браузера. Сам модуль не является частью проекта Chromium, его исходный код нигде не публиковался.
В ходе дальнейшего разбирательства удалось выяснить, что этот модуль написан на базе Native Client, используется для работы голосового помощника и содержит запатентованные технологии Google.
Пользователи Линукса, как и многие другие сторонники открытого кода, возмутились этим фактом. Причем поводов для критики было озвучено сразу несколько. Попробуем пройтись по ним, приведем комментарии разработчиков Хрома и свое собственное мнение.
1. "Использование проприетарного кода в Chromium - это плохо"
Многих возмутил тот факт, что браузер, позиционируемый опенсорсным, в своей работе использует модули с закрытым исходным кодом. Широко распространено мнение, что подобная практика некорректна. И во многом это мнение подпитывается тем фактом, что Chromium действительно не использует многие "закрытые" компоненты браузера Chrome. Например, в Chromium отсутствуют flash-плагин, поддержка многих кодеков (MP3, H264). Да и PDF-просмотрщик не являлся частью проекта ровно до тех пор, пока не раскрыл свой код в рамках проекта PDFium.
И если пользователи открытого Хрома раньше мирились с этими неудобствами, то теперь может возникнуть вполне резонный вопрос: почему что-то можно подгружать отдельно и использовать в работе, а, например, Flash или PDF было нельзя? Мы не исключаем, что ограничения были связаны с лицензиями на использование подобных компонентов. Ведь Flash был разработан компанией Adobe, а PDF-ридер - на базе технологий Foxit. Соглашения с этими сторонними компаниями могли ограничить использование компонентов лишь продуктами Google, к коим проект Chromium не относится. Вот даже цитата разработчика браузера:
The key here is that Chromium is not a Google product (we do not directly distribute it, or make any guarantees with respect to compliance with various open source policies).
В то время, как обсуждаемый Chrome Hotword Shared Module создан исключительно сотрудниками Google, поэтому может распространяться без ограничений. И если это наше предположение верно, то мнение о неиспользовании в Chromium проприетарных компонентов является лишь распространенным ошибочным мифом. Разработчики браузера ничем не ограничены.
2. "Использование проприетарного кода в софте для Debian - это плохо"
С другой стороны, у таких проектов как Debian, вполне могут существовать собственные правила, согласно которым подобная практика явно запрещена.
Вот только команда Chromium официально не собирает сборки для Debian и уж тем более не распространяет их через репозиторий, поэтому формально они не обязаны следовать правилам конкретного дистрибутива, даже если эти правила широко поддерживаются всем Linux-сообществом. Отвечать за соблюдение правил должны те, кто распространяет сборки. И комментарий разработчика браузера на это явно намекает:
If a third party (such as Debian) destributes it, it is their responsibility to enforce their own policy.
3. "А почему нельзя было просто вырезать это из Chromium и использовать только в Chrome?"
Некоторые пользователи предложили разработчикам использовать закрытый код только в закрытом Chrome, а Chromium оставить полностью открытым.
Проблема тут ровно в том, что Chromium по факту это не самостоятельный и уж точно не свободный проект. Его главная задача: максимально совпадать с Chrome. Т.е. чем меньше разработчики из Google будут тратить усилий на превращение открытого браузера в закрытый, тем лучше. Именно этим они объясняют решение подгружать закрытый модуль отдельно. С одной стороны, это позволяет унифицировать исходный код Chrome и Chromium, с другой, запатентованные технологии не будут раскрыты.
We had a choice to either bake it into Google Chrome (and take it out of Chromium), or provide it as a separate NaCl module. Since our policy is to put as little proprietary code in Google Chrome as possible (to keep it almost identical to Chromium), we chose the latter.
4. "А почему этот модуль не видно на chrome:extensions?"
С точки зрения части пользователей, если браузер использует подключаемый модуль, то он должен быть обязательно виден на странице chrome:extensions. А если его там не видно, то кто-то что-то скрывает.
Это тоже миф. В современной браузерной (да и не только) индустрии сплошь и рядом можно найти возможности и эксперименты, которые подключается в виде расширений. Это удобно. Позволяет испытать фичу без серьезных доработок в исходном коде. Например, новый менеджер закладок в Chrome тоже тестировался в виде подключенного без спроса расширения.
Но почему их не видно на chrome:extensions? Потому что эта страница создана для пользователей. И на ней должны отображаться установленные пользователем расширения, а не все те части браузера, которые технологически являются расширениями. Эксперименты и обсуждаемый модуль по сути - это части базового браузера. И если кто-то хочет отслеживать такие части, то стоит идти не на chrome:extensions, а на chrome:net-internals#modules.
We call extensions that are built into or automatically downloaded by Chrome "component extensions" and we do not show them in the extension list by design. This is because as I was saying above, we consider component extensions to be part of the basic Chrome experience (it is an implementation detail that they are separate extensions). The chrome://extensions UI is a place for users to manage the extensions that they have installed themselves; it would be confusing if that list was pre-populated with bits and pieces that are a core part of the browser.
5. "А почему вы скачиваете и включаете его сразу, а не ждете, пока пользователь явно включит функцию?"
Пожалуй, мы, наконец-то, добрались до первого момента, который действительно может стать не самым приятным для Google. И дело тут не в том, что модуль загружается сразу и до активации "Окей, Гугл" в настройках. В конце концов, подготовить браузер заранее - это не такая уж и плохая мысль, учитывая, что скорость интернета у всех разная, и экстренно скачать компонент можно просто не успеть.
Основная проблема тут в том, что, согласно комментариям разработчиков Chromium, модуль не должен быть активирован до включения голосового помощника в настройках.
First and foremost, while we do download the hotword module on startup, we *do not* activate it unless you opt in to hotwording. If you go into "chrome://settings", you will see a checkbox "Enable "Ok Google" to start a voice search". This should be unchecked by default, and if you do not check it, the hotword module will not be started.
В то время как в реальности, согласно некоторым пользователям, модуль включается сразу после загрузки и никак не реагирует на опцию в настройках. Мы решили проверить это на Google Chrome. Отключили голосовой помощник в настройках и зашли на специальную страницу chrome://voicesearch/. Результат:
На chrome://net-internals/#modules, кстати, тоже видно, что модуль включен. А вот это уже проблема. Причем проблема не в том, что модуль активируется или загружается, а в том, что ответственные за фичу люди сами не знают, как она работает.
Вместо вывода
Один из сотрудников Google решил резюмировать переписку в багрепорте следующими словами:
It's fine to make it an extension. It's fine to make it a transparent extension, it's fine to have it be an opt-in feature that is implemented as an extension. It's not fine to download it *before* the user chose it. That's the only problem here!
Вот только не ясно, имеет ли этот сотрудник какое-то отношение к модулю или просто проходил мимо и не смог сдержать свое частное мнение?
Если коротко пробежаться по всем нашим пунктам, то можно вынести следующее.
- Открытый код сам по себе не накладывает никаких обязательств и может использовать проприетарщину в своей работе.
- За соблюдение правил Debian отвечает ответственный за браузер Chromium в репозитории Debian (и это не команда Chromium).
- Распространение фичи через расширение - это обыденность и норма. Само расширение специально никто не прятал.
- Модуль активируется сразу после установки - это ничего не нарушает само себе, хотя и неприятно для open source сообщества и многих продвинутых пользователей.
- Противоречивые комментарии сотрудников Google - вот это плохо и подрывает доверие к разработчикам.
- Несмотря на то, что Google и Chromium не обязаны соблюдать, скажем так, традиции сообщества open source и Linux, описанный в этом посте скандал тем не менее ударил по репутации браузера среди данной аудитории.
- Никогда не забывайте, что Chromium - это не свободный проект, а лишь предварительный этап в сборе Google Chrome (речь идет о фактической продуктовой свободе проекта Chromium от коммерческого проприетарного продукта Chrome, а не о тексте лицензии). Без каких-либо обязательств.
В завершении можно еще сказать, что разработчики Chromium добавили поддержку специального флага, который позволяет собрать Хром, не загружающий спорный модуль. И мейнтейнеры из Debian, насколько нам известно, уже им воспользовались.