Это увлекательная тема, которая, по-видимому, в основном порождена недопониманием.
Однако это не проблема самого Discourse; эта проблема присуща любой онлайн-системе, в которой отсутствует сквозное шифрование и цифровые подписи/проверка подлинности сообщений. В Discourse ни того, ни другого нет «из коробки».
Вы здесь на самом деле не ведете дискуссию, и это также не относится к решениям, принятым Discourse как продуктом или командой CDCK. Существует множество заблуждений, и вы лишь осознаёте, что программное обеспечение не может контролировать высшую степень власти в системе — это то, что многие из нас знают в той или иной степени уже десятилетиями.
Репутация сообщества зависит не от функций Discourse, а почти исключительно от того, кому вы доверяете ключи управления. Если администратор с недобрыми намерениями совершит действие, вызывающее бурную реакцию сообщества, никому не будет важно, насколько легко ему было это сделать, поскольку в конечном итоге именно вы, а не какая-то конкретная кнопка, дали ему такую возможность.
Кажется, что люди просто не осознают, какой властью обладает администратор. Функция «Имитация» — это лишь верхушка айсберга.
Мне нравится, как вы это сформулировали, потому что да, для меня было настоящим шоком (и часто даже страшно) узнать, насколько велика моя власть как администратора.
Именно поэтому я так часто стремился к сквозному шифрованию: чтобы уменьшить свою власть как администратора и снизить страх перед тем, что может произойти с этой властью (например, возможность читать или изменять сообщения, юридическая ответственность за необходимость докладывать о том, что люди говорят в частных разговорах и т. д.).
Однако это не те проблемы, которые легко решаются свободным и открытым программным обеспечением, даже тем, что существует уже десятилетие.
В конечном счёте всё сводится к балансу между риском и доверием между приложениями, из которых состоит ваш сервис, и людьми, у которых есть ключи к этому королевству.
Осознание уровня доступа, который у вас есть, — это на самом деле хороший первый шаг.
У вас есть опыт работы с огромными объёмами инженерной работы, необходимыми для того, чтобы сделать эти вещи простыми и удобными для пользователя?
Они не были упущены из-за какой-то простой ошибки.
Достаточно, чтобы я испытывал безмерное уважение к инженерам Signal и одновременно испытывал страх перед попыткой написать свою собственную криптографию В 2012–2013 годах я создал приложение для зашифрованного ведения дневника, где всего один пользователь общался сам с собой на одном устройстве… и даже это было мучением, вероятно, не слишком удобным, и я не уверен в его безопасности.
Так что да, я согласен: создание и поддержка простых, удобных и безопасных технологий многопользовательской связи может быть чрезвычайно сложной задачей. Возможно, именно поэтому я был так приятно удивлен существованию плагина Discourse Encrypt.
В любом случае, ваши комментарии напомнили мне, что да, эта платформа бесплатна и с открытым исходным кодом, а это значит, что если основная команда решит не делать что-то (например, шифрование чата или блокировку подмены личности) по любой причине, я могу сам создать плагин или нанять кого-то для его разработки. И именно эта свобода сделать это, если я захочу, является одной из вещей, которые мне так нравятся в Discourse.
По моему скромному мнению, даже модераторы обладают значительной властью в дискуссиях, но я привык к среде phpBB3, где у модераторов было гораздо меньше полномочий. (Также я более 20 лет управлял сайтом на базе Mailman и планирую перенести его на Discourse, как только разберусь, как перенести туда 20 лет переписки.)
Я был единственным системным администратором этого сайта на phpBB3 более 15 лет, хотя несколько лет назад вышел на пенсию. На самом деле я с нетерпением жду перехода этой платформы на Discourse, так как предполагаю, что администратором станет кто-то другой. Мне даже не хотелось бы быть модератором там, я просто хочу быть участником. Я консультировал руководителя проекта по вопросам администрирования форума, с которыми мы сталкивались за эти годы; некоторые из них могут повлиять на настройки, которые он выберет, другие — на политику, которую организация внедрит как для пользователей, так и для сотрудников.
Тем не менее, введение ограничений на то, кто может использовать кнопку «Имперсонация», кажется мне не плохой идеей, а скорее символической мерой для опытного администратора. И, конечно же, команда разработчиков или системный администратор (в случае самохостинга) при желании и достаточных усилиях могут сделать практически всё.
Симуляция входа — это важный и широко используемый инструмент для администраторов. Я работаю в сфере веб-хостинга и очень часто использую функцию «Войти как» (имперсонацию) в своей панели биллинга для входа в аккаунты клиентов. Существует множество случаев, когда такая функция критически важна. В частности, могут возникать следующие ситуации:
Вы оказываете поддержку пользователю и должны видеть, что происходит на его стороне.
Вы устраняете ошибку, которая проявляется не у всех пользователей.
Вам нужно увидеть фронтенд с точки зрения пользователя.
Вы тестируете пользовательский опыт и сценарии использования.
Хотя Discourse — это не панель биллинга, случаи использования во многом схожи. Администраторам может потребоваться устранить ошибку или посмотреть, как форум выглядит для конкретной группы или пользователя. Я обычно симулирую вход в свои альтернативные аккаунты, которые состоят в определенных группах или имеют статус TL/модератора/модератора категории, чтобы проверить, как всё выглядит с их стороны, и не упустил ли я каких-либо очевидных настроек.
Или же просто помогаю пользователю в задачах, которые невозможно выполнить без имперсонации — не уверен, существуют ли настройки пользователя, к которым нельзя получить доступ без этой функции.
Кроме того, любой root-администратор уже может получить доступ к любой информации в базе данных. Это одно из прав доступа, которыми администратор обладает по умолчанию. Функция имперсонации существует для того, чтобы облегчить жизнь администраторам, точно так же, как и любые другие настройки: они призваны упростить административные задачи через интерфейс /admin/.
Единственные настройки, о которых я знаю, что они вызывают проблемы, я полагаю, можно изменить как администратор, но в нескольких местах отображаются ваши настройки вместо его. На вкладке «Интерфейс» отображаются ваши настройки темы и цветовой схемы вместо настроек пользователя, поэтому вам нужно имперсонировать его, чтобы быть уверенным, что вы видите правильные значения.
Просто хочу напомнить:
Возможно, многие люди уже забыли о возможности полностью отключить имперсонацию администратора, просто установив крошечный плагин размером менее десяти строк кода?
Возможно, стоит добавить переключатель для функции имперсонации в настройках сайта, как для всех остальных функций, например, для шёпота, упоминаний, страницы пользователя, журнала доступа к личным сообщениям и т. д.
Если этот переключатель будет находиться в настройках сайта, то любой администратор сможет включить его обратно, и теперь одно нажатие превратится в несколько. Не уверен, что это решит проблему в глазах тех, кто считает её проблемой. Но это может сделать использование функции для подглядывания менее заманчивым.
Я думаю, было бы здорово иметь возможность настраивать через командную строку, какие администраторы на сайте могут получить доступ к этой функции. Ведь могут быть администраторы, которым требуется повышенный уровень доступа. Хотя даже простая идея @jimkleiber — скрыть кнопку с помощью CSS для всех, кроме пользователей уровня X+, — была бы достаточной для большинства случаев, так как это лишь устраняет соблазн увидеть её. Однако, вероятно, лучше использовать плагин-сериализатор в том же духе, ведь представьте, что можно нажать на невидимую кнопку(?).
Действительно, в таком случае нужен корневой параметр командной строки. Хотя большинство оставят всё как есть, если речь идёт лишь о проблеме «соблазна».
Вот PR для глобальной настройки отключения этой функции. Я считаю, что это правильный подход. Это то, что администратор, устанавливающий и запускающий кластер, хочет настроить для всего кластера.
Отличный PR! Однако я считаю, что с этой новой функцией включение и выключение настройки имперсонации происходит слишком легко. Мне кажется, большинство пользователей будут некомфортно чувствовать себя, зная, что имперсонацию можно включить или выключить по прихоти администратора!
Возможно, стоит рассмотреть дополнительную настройку, которая позволит включать или выключать саму новую настройку allow_impersonation. Тогда мне будет сложнее соблазниться и установить allow_impersonation в значение «вкл». Что-то вроде настройки allow_allow_impersonation. Что вы думаете?
При поддержке клиентов мы иногда используем функцию имперсонации администратора в нестандартных ситуациях, чтобы убедиться, что проблема не связана с браузером, операционной системой или блокировщиком рекламы. В таких случаях это очень удобно и ненавязчиво: администратор не публикует сообщения от имени пользователя и не получает доступа к информации, которая и так была бы ему видна.
Я вижу много путаницы между техническими и социальными аспектами. С технической точки зрения, имитация полезна, и её отключение не предотвращает достаточно проблем. С социальной точки зрения, имитация слишком проста в использовании и в культуре некоторых форумов нарушает социальный договор.
Утверждение, что имитация полезна или даже необходима, ничего не говорит о её социальной полезности или о том, как это воспринимается. Поэтому люди говорят друг с другом, не слыша друг друга — особенно, возможно, те, кто не привык думать в терминах социальных ожиданий в разных культурах.
Спасибо за глобальный переключатель. (Я всё ещё считаю, что предупреждение в виде промежуточного экрана стало бы улучшением!)
Или это должно быть в консоли, чтобы разрешить эту настройку. Или это должно быть в исходном коде, чтобы разрешить это. Или хотя бы какие-то предупреждения? В любом случае соблазн всё ещё остаётся. Что делать?
В 2012–2013 годах я создал приложение для зашифрованного ведения дневника, где всего один пользователь общался сам с собой на одном устройстве… и даже это было мучением, вероятно, не слишком удобным, и я не уверен в его безопасности.
)