Codestream: Die Slack-Integration erfordert zu viele Berechtigungen, und weder die Datenschutzrichtlinie noch die Adresse der Nutzungsbedingungen erklären, wie oder warum CodeStream diese Berechtigungen verwendet oder die von Slack gesammelten Informationen schützt

Schätze deine Besorgnis total @BernsteinA . Das Wichtigste, was hier zu beachten ist, ist, dass außer deinem Benutzernamen, deiner E-Mail-Adresse und einigen Profilfeldern keine deiner Slack-Workspace-Informationen von unseren Servern abgerufen oder auf diesen gespeichert werden.

Wir arbeiten aktiv mit dem Engineering-Team von Slack zusammen, um zu versuchen, die Anzahl der Bereiche auf das absolute Minimum zu reduzieren, das erforderlich ist, um die von CodeStream bereitgestellten Funktionen zu ermöglichen.

Vielleicht könnten Sie in Ihre Datenschutzrichtlinie aufnehmen: „Außer Ihrem Benutzernamen, Ihrer E-Mail-Adresse und einigen Profilfeldern wird auf keine Ihrer Slack-Workspace-Informationen zugegriffen oder auf unseren Servern gespeichert“?

Ausgezeichneter Vorschlag! Unsere aktuelle Datenschutzrichtlinie wurde offensichtlich geschrieben, bevor wir die Slack-Integration hinzugefügt haben.

Dem nachgehen.

Die aktuellen Slack-Berechtigungen fragen nach:

• Erhalten Sie alle Ereignisse von MadKudu in Echtzeit
• Greifen Sie auf alle Inhalte in MadKudu zu

Dies scheint besser zu sein als das, was ursprünglich in der Ausgabe beschrieben wurde, ist aber immer noch übertrieben. Nachdem ich eine Slack-Integration erstellt habe, weiß ich, wie nervig das sein kann. Aber im Moment kann ich mir diese Berechtigungsstufe ohne eine rechtliche Vereinbarung in Codestream nicht leisten.

Mein Team würde gerne Ihr Produkt verwenden, also zögern Sie nicht, mich unter [email protected] zu kontaktieren

@pcothenet - Ich werde Sie per E-Mail kontaktieren.

@planteater irgendeine Bewegung dazu? Sie fordern immer noch vollen Lese-/Schreibzugriff auf jeden Slack-Kanal an

@BernsteinA - Noch keine Änderungen. Lassen Sie mich die Situation hier skizzieren, da ich gerne Ihre Meinung erfahren würde. Generell haben wir zwei Möglichkeiten.

Die erste Option ist die, die wir heute haben, die einerseits einen breiten Zugriff erfordert, andererseits aber ein Modell ermöglicht, bei dem Ihr Messaging überhaupt nicht durch das CodeStream-Backend geht. Dein VS Code-Client kommuniziert direkt mit Slack. Obwohl die von uns geforderten Umfänge lästig klingen, soll es Ihnen eigentlich ermöglichen, über Ihren Editor auf Slack und nicht auf die Server von CodeStream zuzugreifen.

Die andere Option wäre, die Slack-Integration so neu zu implementieren, dass eingeschränktere Bereiche erforderlich wären, Sie jedoch explizit einen CodeStream-Bot zu jeder Slack-Konversation hinzufügen müssten, mit der Sie über CodeStream interagieren möchten. Wichtig ist, dass dies auch bedeuten würde, dass Ihre Nachrichten an/von Slack das Backend von CodeSteam durchlaufen müssten.

Was haltet ihr von diesen beiden Optionen?

Wenn die Berechtigungen meinem VS Code-Client den Zugriff auf Slack erlauben sollen, sollten Sie den Benutzern die Möglichkeit geben, ihre eigene Integration unter https://api.slack.com/apps einzurichten

Die andere Option, das Erstellen eines Bot-Benutzers oder eine Pro-Channel-Integration, wäre eher Standard und würde den Endbenutzern ein viel klareres Bild davon vermitteln, welche Nachrichten / Daten von CodeStream gesehen werden können (d. h. nur Nachrichten, die an den Bot oder in ein Kanal, dem der Bot explizit hinzugefügt wurde).

Ich muss sagen, dass ich auch ein bisschen besorgt war, als ich die Bereiche sah, die CodeStream gefragt hat ... Verbesserungen zu diesem Thema werden sicherlich geschätzt 😉

Dies ist auch für mein Unternehmen ein Deal-Breaker! Uns geht es gut, wenn CodeStream Zugang zu Konversationen rund um den Code hat, aber für uns ist alles ein No-Go...

Hier gilt das gleiche. Das Tool selbst sieht fantastisch aus, aber es passt für viele Leute nicht zu den Unternehmensrichtlinien, denke ich.
Ich denke, Bots in ausgewählten Kanälen einzusetzen, ist der (Standard-) Weg, dies zu implementieren, ohne dass dies erforderlich ist

Würde mich über Neuigkeiten zu diesem Thema freuen!

Benutzerdefinierte Slack-Integrationen klingen ebenfalls gut, aber die vorgeschlagene Bot-Lösung scheint bequemer zu sein.

Unterstütze dies. Das war eine große Hürde, und wenn meine Firma feststellt, dass ich in Schwierigkeiten geraten kann.

@BernsteinA - Noch keine Änderungen. Lassen Sie mich die Situation hier skizzieren, da ich gerne Ihre Meinung erfahren würde. Generell haben wir zwei Möglichkeiten.

Die erste Option ist die, die wir heute haben, die einerseits einen breiten Zugriff erfordert, andererseits aber ein Modell ermöglicht, bei dem Ihr Messaging überhaupt nicht durch das CodeStream-Backend geht. Dein VS Code-Client kommuniziert direkt mit Slack. Obwohl die von uns geforderten Umfänge lästig klingen, soll es Ihnen eigentlich ermöglichen, über Ihren Editor auf Slack und nicht auf die Server von CodeStream zuzugreifen.

Die andere Option wäre, die Slack-Integration so neu zu implementieren, dass eingeschränktere Bereiche erforderlich wären, Sie jedoch explizit einen CodeStream-Bot zu jeder Slack-Konversation hinzufügen müssten, mit der Sie über CodeStream interagieren möchten. Wichtig ist, dass dies auch bedeuten würde, dass Ihre Nachrichten an/von Slack das Backend von CodeSteam durchlaufen müssten.

Was haltet ihr von diesen beiden Optionen?

Für meinen eigenen Slack oder einen teambasierten Slack wäre der erste akzeptabel; Für mein Unternehmen ist dies jedoch ein großes No-Go.

Ich hätte lieber Bots, wenn das machbar ist.

Wollen Sie hier einige Meinungen zu möglichen Änderungen einholen. Wenn die Slack-App von CodeStream…

• War im Slack-App-Verzeichnis
• Der Bereich „Alle Ereignisse von $workspace in Echtzeit empfangen“ wurde nicht mehr benötigt
• Nur erforderlicher Zugriff auf „alle Inhalte“ in Ihren öffentlichen Kanälen (möglicherweise mit einer Option für Sie, auch den Zugriff auf private Kanäle/DMs zuzulassen, wenn Sie Codemarken in privaten Kanälen/DMs teilen möchten)
• Es wurden nur Antworten auf Codemarken in diesen Kanälen und keine anderen Posts abgehört.

Würde Ihnen das die nötige Sicherheit geben, um die Slack-Integration zu nutzen?

@planteater das klingt vernünftig. Gibt es eine Möglichkeit, den Hörer nur zu bestimmten Kanälen hinzuzufügen?

Außerdem nehme ich an, dass Sie die Nutzungsbedingungen und die Datenschutzrichtlinie aktualisieren werden? Soweit ich das beurteilen kann, gibt es dort nichts, was entweder die über Slack gesammelten Daten, die Codestream-Kommentare oder den Quellcode selbst abdeckt.

@planteater das klingt besser, aber ich habe die gleichen Kommentare wie @BernsteinA

@planteater Irgendwelche Bewegungen dazu? Mein Unternehmen kann/wird Codestream nicht verwenden, bis dieses Problem behoben ist. Ich kann mir vorstellen, dass es vielen anderen ähnlich geht. Es ist eine Schande, denn Codestream sieht toll aus, aber diese Berechtigungen sind für fast jedes Unternehmen einfach nicht in Ordnung.

@AndrewMorsillo – Im Moment können Sie entweder ein Team haben, das das Messaging von Slack nutzt, oder eines, das das eigene Messaging von CodeStream verwendet. Es gibt einfach keine Möglichkeit, die aktuelle Slack-Integration ohne diese umfassenden Berechtigungen durchzuführen, da dies die einzige Möglichkeit ist, von Slack gepostete Antworten in CodeStream erscheinen zu lassen.

Unser Plan ist es jedoch, den Teams, die die Nachrichten von CodeStream verwenden, eine andere Art der Slack-Integration hinzuzufügen. Grundsätzlich eine Möglichkeit, beliebige Codemarken als Benachrichtigungsmittel an Slack weiterzugeben. Diese Slack-Integration wird die sehr grundlegenden Berechtigungen haben, an die Sie wahrscheinlich gewöhnt sind, also wird es dieses Problem lösen, aber als Ergebnis werden Sie nicht in der Lage sein, direkt von Slack aus zu antworten. Sie könnten sich jedoch von Slack zu einer Webseite durchklicken, auf der Sie antworten könnten, oder direkt in Ihre IDE verlinken, wo Sie über CodeStream antworten könnten. Und natürlich gibt es E-Mail-Benachrichtigungen, auf die Sie auch antworten können.

Wenn Sie jetzt mit CodeStream loslegen möchten, würde ich vorschlagen, sich ohne die Slack-Option anzumelden, und dann können Sie diese neuen Freigabefunktionen nutzen, wenn sie im nächsten Monat oder so fertig sind.

@planteater danke! Wir werden es vorerst ohne die Slack-Integration versuchen. Ich denke, es wäre vollkommen in Ordnung für CodeStream, eine "normalere" Slack-Integration zu verwenden, bei der die CodeStream-App nur Zugriff auf Kanäle hat, die wir kontrollieren können. Zumindest für mein Team wäre das genauso nützlich wie das aktuelle Modell und es gäbe keine Berechtigungsprobleme.

Um auf Ihren anderen Kommentar zu antworten https://github.com/TeamCodeStream/CodeStream/issues/14#issuecomment -493461174 Ich glaube nicht, dass irgendeine Art von Integration, bei der CodeStream "alle Inhalte" anfordert, für viele Menschen funktionieren wird. Für mein Team würde es nicht funktionieren. Es stellt einfach ein zu großes Sicherheitsrisiko dar, da es keine Möglichkeit gibt zu wissen, wer auf "alle Inhalte" zugreift. Selbst wenn Sie der Community versichern (wir glauben Ihnen!), dass es sich nur um den In-Editor-Slack-Client handelt oder dass er nur bestimmte Nachrichten abhört, wird es sich immer wie ein zu großes Risiko anfühlen – was ist, wenn Ihr Dienst pwned wird und jetzt a Ein schändlicher Akteur kontrolliert eine Slack-App, die vollen Zugriff auf unzählige Slack-Instanzen von Personen hat?

Die neue Slack-Integration erfordert keine umfangreichen Berechtigungen mehr für deinen Workspace. Insbesondere benötigen wir keinen Zugriff mehr auf Ihren Kanal-/DM-Verlauf.