Codestream: Для интеграции со Slack требуется слишком много разрешений, и ни политика конфиденциальности, ни условия обслуживания не объясняют, как и почему CodeStream использует эти разрешения или защищает информацию, полученную от Slack.

Полностью ценю вашу заботу @BernsteinA . Здесь важно отметить, что, кроме вашего имени пользователя, электронной почты и нескольких полей профиля, никакая информация о вашем рабочем пространстве Slack не используется и не хранится на наших серверах.

Мы активно работаем с командой инженеров Slack, чтобы попытаться сократить количество областей до минимума, необходимого для использования функций, предоставляемых CodeStream.

Возможно, вы могли бы указать в своей политике конфиденциальности, что «кроме вашего имени пользователя, электронной почты и нескольких полей профиля, никакая информация о вашем рабочем пространстве Slack не используется и не хранится на наших серверах»?

Отличное предложение! Наша текущая политика конфиденциальности, очевидно, была написана до того, как мы добавили интеграцию со Slack.

Следим за этим.

Текущие разрешения Slack запрашивают:

• Получайте все события от MadKudu в режиме реального времени
• Доступ ко всему контенту в MadKudu

Это кажется лучше, чем то, что было первоначально описано в выпуске, но все еще выходит за рамки. Создав интеграцию со Slack, я знаю, как это может раздражать. Но на данный момент я не могу позволить себе такой уровень разрешений без юридического соглашения с Codestream.

Моя команда хотела бы использовать ваш продукт, поэтому не стесняйтесь обращаться ко мне по адресу [email protected]

@pcothenet - я свяжусь с вами по электронной почте.

@planteater какие-нибудь движения по этому поводу? Вы по-прежнему запрашиваете полный доступ для чтения/записи ко всем каналам Slack.

@BernsteinA - пока без изменений. Позвольте мне обрисовать ситуацию здесь, так как я хотел бы получить ваши мысли. Вообще говоря, у нас есть два варианта.

Сегодня мы имеем первый вариант, который, с одной стороны, требует широкого доступа, но, с другой стороны, допускает модель, при которой ваши сообщения вообще не проходят через серверную часть CodeStream. Ваш клиент VS Code взаимодействует напрямую со Slack. Хотя объемы, которые нам требуются, звучат обременительно, на самом деле они позволяют вам через редактор получать доступ к Slack, а не к серверам CodeStream.

Другим вариантом может быть повторная реализация интеграции Slack таким образом, который потребует более ограниченных областей, но потребует от вас явного добавления бота CodeStream в любой диалог Slack, с которым вы хотите взаимодействовать через CodeStream. Важно отметить, что это также будет означать, что ваши сообщения в/из Slack должны будут проходить через серверную часть CodeSteam.

Что вы думаете об этих двух вариантах?

Если это тот случай, когда разрешения позволяют моему клиенту VS Code получать доступ к Slack, вы должны предоставить пользователям возможность настроить свою собственную интеграцию на странице https://api.slack.com/apps .

Другой вариант, создание пользователя-бота или поканальная интеграция, был бы более стандартным и дал бы конечным пользователям гораздо более четкое представление о том, какие сообщения/данные могут быть видны CodeStream (т. е. только сообщения, отправленные боту или в канал, к которому бот был явно добавлен).

Должен сказать, что я тоже немного забеспокоился, когда увидел области, которые задавал CodeStream... улучшения в этой теме, безусловно, будут оценены по достоинству 😉

Это нарушение условий сделки и для моей компании! Мы в порядке, если CodeStream имеет доступ к разговорам о коде, но для нас это не годится...

То же самое. Сам инструмент выглядит потрясающе, но я думаю, что для многих он не будет соответствовать политике компании.
Я думаю, что использование ботов на выбранных каналах — это (стандартный) способ реализовать это без необходимости

Хотелось бы услышать новости по этому вопросу!

Индивидуальные интеграции slack тоже звучат хорошо, но предлагаемое решение с ботами кажется более удобным.

Присоединяюсь к этому. Это было большим препятствием, и если моя компания обнаружит это, у меня могут быть проблемы.

@BernsteinA - пока без изменений. Позвольте мне обрисовать ситуацию здесь, так как я хотел бы получить ваши мысли. Вообще говоря, у нас есть два варианта.

Сегодня мы имеем первый вариант, который, с одной стороны, требует широкого доступа, но, с другой стороны, допускает модель, при которой ваши сообщения вообще не проходят через серверную часть CodeStream. Ваш клиент VS Code взаимодействует напрямую со Slack. Хотя объемы, которые нам требуются, звучат обременительно, на самом деле они позволяют вам через редактор получать доступ к Slack, а не к серверам CodeStream.

Другим вариантом может быть повторная реализация интеграции Slack таким образом, который потребует более ограниченных областей, но потребует от вас явного добавления бота CodeStream в любой диалог Slack, с которым вы хотите взаимодействовать через CodeStream. Важно отметить, что это также будет означать, что ваши сообщения в/из Slack должны будут проходить через серверную часть CodeSteam.

Что вы думаете об этих двух вариантах?

Для моего собственного слака или слака, основанного на команде, первый вариант был бы приемлемым; однако для моей компании это большой запрет.

Я бы предпочел иметь ботов, если это возможно.

Хотите получить некоторые мнения о возможных изменениях здесь. Если приложение CodeStream Slack…

• Был в Slack App Directory
• Больше не требуется область действия «Получать все события из $workspace в реальном времени».
• Требуется только доступ ко «всему контенту» в ваших общедоступных каналах (возможно, с возможностью разрешить доступ к частным каналам/DM, если вы хотите поделиться кодовыми метками в частных каналах/DM)
• Прослушивал только ответы на кодовые знаки на этих каналах, а не какие-либо другие сообщения.

Даст ли это вам душевное спокойствие, необходимое для использования интеграции со Slack?

@planteater звучит разумно. Есть ли способ добавить слушателя только к определенным каналам?

Кроме того, я предполагаю, что вы обновите TOS и политику конфиденциальности? Насколько я могу судить, там нет ничего, что касалось бы данных, собранных через Slack, комментариев кодового потока или самого исходного кода.

@planteater звучит лучше, но у меня те же комментарии, что и у @BernsteinA

@planteater Есть какие-нибудь движения по этому поводу? Моя компания не может/не будет использовать кодовый поток, пока эта проблема не будет решена. Я думаю, что то же самое для многих других. Это позор, потому что codestream выглядит потрясающе, но эти разрешения просто не подходят почти для любой компании.

@AndrewMorsillo. Прямо сейчас у вас может быть либо команда, использующая обмен сообщениями Slack, либо команда, использующая собственный обмен сообщениями CodeStream. Текущая интеграция Slack просто невозможна без этих широких разрешений, поскольку это единственный способ, чтобы ответы, отправленные из Slack, отображались в CodeStream.

Тем не менее, наш план состоит в том, чтобы добавить другой тип интеграции Slack для команд, использующих сообщения CodeStream. По сути, способ поделиться любым кодовым знаком в Slack в качестве средства уведомления. Эта интеграция Slack будет иметь самые базовые разрешения, к которым вы, вероятно, привыкли, поэтому она решит эту проблему, но в результате вы не сможете отвечать прямо из Slack. Однако вы могли бы перейти из Slack на веб-страницу, где вы могли бы ответить, или сделать прямую ссылку прямо в вашей IDE, где вы могли бы ответить через CodeStream. И, конечно же, будут уведомления по электронной почте, на которые вы также можете ответить.

Если вы хотите начать пинать шины на CodeStream сейчас, я бы посоветовал зарегистрироваться без опции Slack, и тогда вы сможете использовать эти новые функции обмена, когда они будут готовы в следующем месяце или около того.

@planteater спасибо! Пока попробуем без слабой интеграции. Я думаю, что для CodeStream было бы совершенно нормально использовать более «нормальную» слабую интеграцию, когда приложение CodeStream имеет доступ только к каналам, которые мы можем контролировать. По крайней мере, для моей команды это было бы так же полезно, как и текущая модель, и не было бы проблем с разрешениями.

Чтобы ответить на ваш другой комментарий https://github.com/TeamCodeStream/CodeStream/issues/14#issuecomment -493461174 Я не думаю, что любой тип интеграции, при котором CodeStream запрашивает «весь контент», будет работать для многих людей. Это не сработало бы для моей команды. Это просто представляет слишком большую угрозу безопасности, поскольку нет способа узнать, кто / хочет получить доступ ко «всему контенту». Даже если вы даете сообществу заверения (мы вам верим!), что это всего лишь слабый клиент в редакторе или что он прослушивает только определенные сообщения, всегда будет ощущаться слишком большой риск — что, если ваш сервис будет заблокирован, а теперь гнусный актер контролирует слабое приложение, которое имеет полный доступ к множеству слабых экземпляров людей?

Новая интеграция Slack больше не требует расширенных разрешений для вашей рабочей области. В частности, нам больше не нужен доступ к истории вашего канала/DM.