После того как в теме Discobot thread было отмечено отклонение от темы, я задумался: хочет ли сообщество Discourse обсудить, допустимо ли имитировать пользователей в один клик или же это стоит ограничить только для конкретных сценариев.
С моей точки зрения, это похоже на использование чужого IP-адреса или идентификатора. Такое поведение не соответствует этическим и моральным нормам (прежде чем говорить о законности или незаконности).
Я считаю, что то же самое относится и к функции имитации пользователей в один клик, когда администраторы могут публиковать сообщения от имени других пользователей одним нажатием кнопки.
Я имею в виду, что для изменения некоторых настроек в Discourse требуется вручную зайти в приложение, использовать Postgres и выполнять множество запросов к данным.
Почему имитация пользователей так проста, когда речь идёт о теме с множеством точек зрения и различными юридическими интересами?
Об этом, вероятно, не знает большинство пользователей. Все мы знаем, что администраторы могут получить доступ к базе данных и изменить что-либо, но это совершенно не то же самое, что нажать кнопку и опубликовать сообщение от имени другого пользователя.
Администраторы могут приостанавливать и блокировать пользователей, если на форуме происходит что-то плохое, и они несут юридическую ответственность за веб-сайт.
Я — нет. Так что в каком-то месте это верно, а в каком-то — нет. То же самое, что и ограничение в 13 лет назад. Или запись собственных телефонных разговоров.
Потому что это мощный инструмент при решении проблем — технических и других.
Для меня сам акт не является незаконным. Однако то, что я делаю, притворяясь кем-то другим, может быть таковым. Всё зависит от обстоятельств.
И IP-адрес не является личной собственностью человека.
Как разработчик, я считаю функцию «Имперсонация» исключительно полезной для процесса разработки. Она позволяет быстро переключаться из роли администратора в роль нового пользователя, чтобы проверить, что тот увидит…
Я считаю, что суть в том, что простое (и скрытное) имперсонация может нарушать ожидания, по крайней мере в некоторых сообществах.
Мы не должны рассматривать это как вопрос права — это вопрос политики, культуры, и, возможно, это именно тот вид политики, где администратор сайта может выбрать один из подходов.
Иногда имперсонация бывает полезной, но, возможно, в таком случае соответствующее лицо должно получить уведомление. Возможно, во многих случаях это лицо могло бы одобритьзапрос на имперсонацию.
Честно говоря, на мой взгляд, эта функция не нужна и её следует удалить. Но я уверен, что у команды могут быть причины для её наличия. Например, переключение на тестовую учётную запись.
Что касается функции подмены личности для публикации от имени другого пользователя, то публично это можно сделать, просто изменив владельца в три клика.
Главное: назначайте администраторами только тех, кто хорошо зарекомендовал себя.
Это может вызывать проблемы, так как некоторые администраторы поддерживают только интерфейс, как в случае с @pfaffman и его клиентами. У всех администраторов есть полные права, но они не используют функции, выходящие за рамки их обязанностей. Как уже упоминалось, необходимо учитывать законы своего региона; однако следует быть осторожным и при путешествиях.
Предлагается создать API, который позволит предоставлять пользователю частичные функции администратора, необходимые дизайнеру или техподдержке.
Это верно, но это можно реализовать с помощью специально созданных тестовых аккаунтов. Здесь всё сводится к честности конечного пользователя. Как предполагает автор темы, эту функцию могут злоупотреблять и использовать во вред.
Мне вспоминается предупреждение в Linux, которое появляется при первом использовании команды sudo:
Мы полагаем, что вы получили обычное напутствие от локального системного
администратора. Оно обычно сводится к трём вещам:
#1) Уважайте приватность других.
#2) Думайте прежде чем печатать.
#3) С великой силой приходит великая ответственность.
То есть, при первом или каждом использовании Impersonate администратору может быть предложено согласиться с условиями, кликнув по кнопке, с сообщением о необходимости уважать приватность и действовать с integrity.
Функция имперсонации — это хорошая вещь, если подумать о ней хоть немного, но не только по уже упомянутым причинам.
Имперсонация записывает своё использование в административный лог. Конечно, администратор может удалить эту запись через rails console или напрямую через SQL-запрос в Postgres, но это оставит свой след — разрыв в ID логов, который заметят другие сотрудники, если будут искать.
Отсутствие функции имперсонации активно подтолкнёт администраторов к злоупотреблению гораздо более зловещей альтернативой, которая не будет логироваться, и я подозреваю, что любой разработчик, читающий эти строки, уже догадался, что я собираюсь сказать.
Хотите иметь одну запись в логе, которую легко скрыть, и сделать это даже за несколько месяцев до события, чтобы другие сотрудники форума не связали эти действия? Создайте API-ключ для всех пользователей. Одна запись в логе, и вы можете делать что угодно от имени любого пользователя в любое время, и если это действие обычно не логировалось бы для того пользователя, от имени которого вы действуете, это не оставит никакого следа.
В любом случае в среде разработки они часто являются тестовыми аккаунтами, однако настройка таких аккаунтов в Dev требует дополнительных усилий. Это избавляет вас от необходимости выходить из системы и входить снова, что замедляет рабочий процесс. Особенно раздражает необходимость настраивать несколько паролей — это неприятный опыт, который замедляет работу и не добавляет никакой ценности в среде разработки. При использовании функции «Имитация» вам нужно запомнить только пароль администратора.
Я просто иллюстрирую дополнительное преимущество этой функциональности для данного конкретного случая использования.
Создание тестовых аккаунтов действительно не занимает времени, и в рамках этой идеи они должны стать стандартной частью установки Discourse, подобно Discobot и системным аккаунтам. Функция «Имитация» останется, но будет работать только с, например, 3–4 тестовыми пустыми аккаунтами, которые можно модифицировать для имитации пользователей различных уровней.
Как уже говорилось, люди с высокими моральными принципами и честностью могут не использовать функцию «Имитация» в злонамеренных целях. Однако соблазн всё же существует. Кроме того, если участники сайта узнают, что администратор может использовать их аккаунт для имитации, это может подорвать их доверие к платформе. В настоящее время функция «Имитация» полагается исключительно на честность и не имеет дополнительных мер защиты, в отличие от того, как «Плагин шифрования» решает проблемы конфиденциальности личных сообщений (PM/DM) на форуме Discourse, обеспечивая приватность, ожидаемую пользователями, если только явно не указано, что личные сообщения не являются безопасными и приватными, как это обычно ожидается в сообществе. В положительном ключе: я специально спрашивал, можно ли с помощью функции «Имитация» обойти «Плагин шифрования», на что Сэм ответил и подтвердил, что это невозможно, так как используется сквозное шифрование.
Я использую функцию «Имитация» только на своих тестовых аккаунтах.
Это не так. Создание тестовых пользователей каждый раз — это сплошная головная боль. Я часто создаю чистые установки для разработчиков и запускаю их с фикстурами для ускорения процесса. (К сожалению, у пользователей из фикстур, насколько мне известно, нет известных паролей.) Затем нужно добавить только один аккаунт администратора, и имперсонация позволяет мне удобно переключаться между ними через интерфейс. Работа выполнена.
Меня немного озадачила ваша негативная реакция… Я просто хвалил платформу за наличие полезной функции, которую я регулярно использую в своей работе, а теперь вы нападаете на эту функциональность и мой подход. С какой целью? Чтобы усложнить нам жизнь? Не думаю, что мне это нравится!
В чём действительно проблема с функцией «имперсонация»? Почему вы делаете из мухи слона? В любом случае, эта функция довольно полезна, и даже крупные технологические компании используют подобные механизмы. Если говорить о конфиденциальности, то администратор всё равно видит всё и может делать что угодно с данными на сайте — Google, Facebook и другие гиганты индустрии делают то же самое. В этом нет ничего нового.
И зачем разработчику создавать учётную запись, если проблема на стороне пользователя? В таких случаях эта функция очень полезна. Если у вас есть проблемы с ней — просто не используйте её.
Я не атакую это вообще. Просто указываю, что это функция, которую легко можно злоупотребить, и она может создать множество проблем. Встроенные тестовые аккаунты для прямого использования устраняют потенциальное злоупотребление, делая их недоступными. Что касается создания тестового аккаунта: я открыл новую вкладку, создал аккаунт с поддельным адресом электронной почты, затем вернулся к своей учетной записи администратора и подтвердил.
Функция «Имперсонация» определённо является полезным инструментом. Если бы были предусмотрены стандартные тестовые аккаунты или возможность для администратора создавать «нулевые» аккаунты в панели администратора для использования с функцией имперсонации, это закрыло бы возможность злоупотребления.
Как уже упоминалось, если сообщество узнает, что аккаунты сотрудников могут имперсонировать их, они могут потерять доверие к платформе сообщества.
Судя по тому, что я прочитал о вас и множестве других замечательных людей здесь, вы вряд ли когда-либо будете злоупотреблять этой функцией. Однако открытая функциональность этой функции может заставить сообщества меньше доверять Discourse как платформе для форумов.
Открытое обсуждение не должно восприниматься как негативное взвешивание плюсов и минусов.
Плагин Sam’s Encrypt предотвращает просмотр личных сообщений (DM/PM) администраторами и модераторами, аналогично тому, как приложения вроде WhatsApp заявляют, что не могут просматривать переписку, если не приглашены. Таким образом, закрывается функция просмотра личных сообщений, которая может восприниматься как нарушение ожидаемой конфиденциальности, особенно если явно не указано, что они не являются по-настоящему приватными.
Это совершенно бессмысленно. Если вы действительно хотите читать личные сообщения пользователей, то как администратор вы можете просто заглянуть в базу данных (если только не включено шифрование).
Как владелец сайта вы в любом случае имеете доступ ко всему, можете применять любые изменения, включать и отключать шифрование — что угодно.
Когда вы используете стороннюю систему как пользователь, у вас нет прямого контроля над тем, что люди могут делать с вашими данными.
В любом случае я не спорю о Production; моя цель состояла лишь в том, чтобы сказать, что эта функциональность также имеет свои преимущества в Development, и их легко продемонстрировать.
Так что с моей точки зрения +1 за это. Сейчас я слишком занят, чтобы продолжать этот спор. Хорошего дня.
Тогда не используйте Google, Facebook, Microsoft и всех остальных, поскольку все они делают то же самое. Они не открыто заявляют, что могут «притворяться» вами. Они могут делать всё, что вы только можете представить, но при этом вы им доверяете и продолжаете их использовать, зная, что они могут сделать всё, так что я не понимаю, в чём действительно проблема, друг. Возможно, вы беспокоитесь о модераторах и администраторах вашего форума, но даже в этом случае все действия логируются, если любой администратор использует функцию «притворяться». Поэтому я не могу понять, в чём проблема. Если бы эта функция была проблемной, команда Discourse не стала бы внедрять её изначально.
