ユーザーになりすますことについての考え

コミュニティ
67

これは非常に興味深いトピックですが、ほとんど誤解から生じているようです。

これはディスコースの問題ではありません。この問題は、エンドツーエンドの暗号化がなく、メッセージにデジタル署名/検証がないあらゆるオンラインシステムに浸透しています。ディスコースには、標準ではどちらもありません。

実際には、どちらについても議論していませんし、ディスコースという製品やCDCKというチームが行った決定に実際に関連するものでもありません。多くの誤解がありますが、あなたはソフトウェアがシステムの究極の権限を管理できないことを学んでいるにすぎません。これは、私たちの中の多くの人が何十年にもわたって様々な程度で知っていたことです。

コミュニティの評判は、ディスコースの機能にかかっているのではなく、ほぼ完全に誰に鍵を渡すかにかかっています。悪意のある管理者がコミュニティを激怒させるようなことをした場合、最終的には特定のボタンではなくあなた自身が彼らにそれを実行する力を与えたため、誰も彼らがその行為をどれほど容易に実行できたかなど気にしないでしょう。

むしろ、人々が管理者が持つ力に気づかなくなっているように聞こえます。なりすましは氷山の一角です。

「いいね！」 7
68

このように状況を整理していただき、ありがとうございます。はい、私自身、管理者としての自分の権限の大きさに（しばしば非常に恐ろしく感じるほど）衝撃を受けてきました。

私がエンドツーエンド暗号化を望むことが多いのは、まさにその理由からです。管理者としての私の権限を減らし、その権限がもたらす可能性のあること（例えば、メッセージの読み取り/変更能力、プライベートな会話で人々が何を言っているかを報告しなければならない法的責任など）に対する恐れを減らすためです。

「いいね！」 3
69

しかし、これらは、たとえ10年前から存在していたとしても、フリーでオープンなソフトウェアが容易に解決できる問題ではありません。

結局のところ、それは、あなたのサービスを構成するアプリケーションと、その王国の鍵を握る人々の間の、リスクと信頼のバランスに集約されます。

自分が持っているアクセスレベルを認識することは、実際には良い第一歩です。

それらをシンプルでユーザーフレンドリーに見せるために必要な、膨大な量のエンジニアリングに関する経験はありますか？

それらは、単純な見落としのために省略されているわけではありません。

「いいね！」 3
70

シグナルエンジニアへの多大な敬意と、自分で暗号化を実装することへの多くの恐怖を抱くには十分です :slight_smile: 2012/13年に暗号化されたジャーナリングアプリを構築しましたが、それは1人のユーザーが1つのデバイスで自分自身と話すだけのものでした…それでもそれは大変で、おそらくそれほどユーザーフレンドリーではなく、どれほど安全かはわかりません。

ですから、はい、同意します。シンプルで、ユーザーフレンドリーで、安全なマルチユーザー通信技術を作成および維持することは、非常に困難な場合があります。おそらく、Discourse Encryptプラグインが存在することにとても驚いた理由です。

いずれにせよ、あなたのコメントは、このプラットフォームが無料のオープンソースであるということを思い出させてくれます。つまり、コアチームが何らかの理由で何かをしないと決定した場合（たとえば、チャット暗号化やなりすまし禁止など）、自分でプラグインを構築したり、誰かに構築を依頼したりすることができます。そして、もし私が望むならそれを構築できるという自由は、私がDiscourseをこれほど愛している理由の1つです。

ありがとうございます :pray:

「いいね！」 2
71

IMHO、モデレーターはディスコースにおいて多くの権限を持っていますが、私はPHPBB3環境から来ており、そこではモデレーターの権限ははるかに少なかったです。（私は20年以上Mailmanサイトも運営しており、20年分のメッセージをディスコースに移行する方法がわかればすぐにでも移行したいと思っています。）

私は15年以上そのPHPBB3サイトの唯一のシステム管理者でしたが、数年前に引退しました。そのプラットフォームがディスコースに移行するのを楽しみにしています。なぜなら、おそらく他の誰かが管理者になるでしょうし、私はモデレーターにさえなりたくなく、ただの参加者でいたいからです。私はプロジェクトリーダーに、長年対処してきたフォーラム管理の問題についてアドバイスしてきました。それらのいくつかは、彼が選択する設定に影響を与える可能性があり、他のいくつかは、組織がユーザーやスタッフのために設けるポリシーに影響を与える可能性があります。

とはいえ、なりすましボタンの使用者を制限することは悪い考えではないように思えます。経験豊富な管理者にとっては、ほとんど象徴的なものに過ぎません。そしてもちろん、開発チームやシステム管理者（セルフホストシステムの場合）は、十分な努力をすれば何でもできるでしょう。

「いいね！」 2
72

なりすましは、管理者にとって不可欠で広く普及しているツールです。私はウェブホスティング業界におり、請求パネルで顧客になりすます（「〜としてログイン」）ことが非常に多いです。このような機能が不可欠なケースは十分にあり、次のようなシナリオが発生する可能性があります。

  1. ユーザーを支援しており、ユーザー側で何が起こっているかを確認する必要がある場合
  2. すべてのユーザーに発生しているわけではないバグをトラブルシューティングしている場合
  3. ユーザーの視点からフロントエンドを確認する必要がある場合
  4. ユーザーエクスペリエンス/フローをテストしている場合

Discourseは請求パネルではありませんが、ユースケースはいくぶん似ています。管理者は、バグをトラブルシューティングしたり、特定のグループやユーザーの視点からフォーラムがどのように見えるかを確認したりする必要がある場合があります。私は通常、特定のグループに属している、または特定のTL/モデレーター/カテゴリモデレーターのステータスを持っている自分の別アカウントになりすまして、相手側の視点からすべてがどのように見えるか、そして明白な設定を見逃していないかを確認します。

あるいは、なりすましなしでは不可能なことについてユーザーを支援する場合もあります。なりすましなしではアクセスできないユーザー設定があるかどうかはわかりません。

さらに、任意のルート管理者はすでにデータベース内のあらゆる情報にアクセスできます。これは、管理者が本質的に持っているアクセス権の1つです。なりすまし機能は、管理者の生活を楽にするために存在します。他のすべての設定と同様に、管理タスクを容易にするために存在します。これは、/admin/インターフェースから行われます。

「いいね！」 6
73

問題となる設定は管理者が変更できるものだと思いますが、いくつかの場所でユーザーの設定ではなく、あなた自身の表示設定が表示されます。インターフェースタブでは、ユーザーのテーマと配色設定ではなく、あなた自身のものが表示されるため、正しい値を確認するにはなりすましを行う必要があります。

「いいね！」 2
74

なりすましなしでは不可能なもう1つは、サブスクリプション設定です Make u/username/billing/ accessible to admins

「いいね！」 3
75

なりすましを削除することについて話している人はいません。

ところで、私のトピックが最初から開いている唯一の質問に誰か答えてくれませんか？

それはDiscourseであり、それは明確な決定です。

76

私は単に質問に答えていただけです

77

この質問にはすでに答えが出ていませんか？

「なりすましボタンを削除する」を「なりすましボタンをより簡単に利用できないようにする」に置き換えると、文の意味は変わりませんよね？

「いいね！」 3
78

念のためお知らせします。
わずか10行未満のコードで構成される小さなプラグインをインストールするだけで、管理者のなりすましを完全に無効にできる可能性を多くの人が忘れているのではないでしょうか？

おそらく、なりすまし機能には、ささやき、タグ付け、ユーザーページ、プライベートメッセージアクセスログなど、他のすべての機能と同様に、サイト設定で切り替え機能を持たせることができると思います。

「いいね！」 10
79

その切り替えがサイト設定にある場合、管理者なら誰でもそれを再度オンにできるため、ワンクリックが数クリックになってしまいます。これは、これを問題だと考えている人々の心の問題を解決するものではないかもしれません。しかし、詮索のために使用する誘惑を減らす可能性はあります。

「いいね！」 2
80

Samが作成したPM/DMには、優れたEmcryptプラグインがあります。

「いいね！」 2
81

サイト上のどの管理者（複数可）がこの機能にアクセスできるかをコマンドラインで設定できると素晴らしいと思います。管理者によっては、権限の昇格が必要な場合があるためです。とはいえ、@jimkleiber さんのCSSを使ってボタンをX+以外には非表示にするというシンプルなアイデアでも、ほとんどの場合十分でしょう。これは、単にそれが見えることへの誘惑を取り除くためだけだからです。ただし、プラグインシリアライザーも同様のアイデアで、おそらくより良いでしょう。なぜなら、見えないボタンを押すことができると想像できるからです。

確かにその場合は、ルートコマンドラインオプションが必要です。ただし、ほとんどの場合は「誘惑」の問題に過ぎないため、そのままにしておくでしょう。

「いいね！」 2
82

このトピックでは、多くのドラマがありました。

これを無効にするためのグローバル設定へのPRを以下に示します。これは、クラスターをインストールして実行している人がクラスター全体で設定したいものであるため、正しい忠実度だと思います。

「いいね！」 13
83

素晴らしいPRです！しかし、この新機能により、なりすましの設定をオン・オフするのが少し簡単すぎると感じます。ほとんどのユーザーは、管理者の気まぐれでなりすましをオン・オフできることを知ると不快に感じるのではないでしょうか！

おそらく、この新しい allow_impersonation 設定をオン・オフできる追加の設定を検討すべきです。そうすれば、allow_impersonation 設定を「オン」に設定することにそれほど簡単に誘惑されなくなります。allow_allow_impersonation のような設定です。どう思いますか？

（これはジョークです :upside_down_face: ）

「いいね！」 12
84

顧客サポート時には、問題がブラウザ/OS/広告ブロッカーに関連していないことを確認するために、管理者がまれに奇妙な状況でなりすましを行うことがあります。そのような場合、それは非常に便利で目立たないものです。管理者は自分の代わりに投稿したり、そうでなければ見ることができないものにアクセスしたりすることはありません。

「いいね！」 2
86

技術的な側面と社会的な側面の間で多くの混乱が見られます。技術的な見方では、なりすましは有用であり、それをオフにしても十分には防げません。社会的な見方では、なりすましは使用が容易すぎ、一部のフォーラムの文化では社会契約に違反します。

なりすましが有用である、あるいは不可欠であると指摘することは、社会的な有用性やメッセージングについては何も述べていません。そのため、人々は互いに話が通じなくなっています。特に、異なる文化における社会的な期待という観点から考えることに慣れていない人々にとっては、なおさらです。

グローバルスイッチに感謝します。（それでも、間の警告があれば改善されると思います！）

「いいね！」 4
87

コンソールにこの設定を許可するか、ソースコードに許可する必要があります。あるいは、何らかの警告を出すべきでしょうか？いずれにしても、誘惑は残ります。どうすればいいでしょうか :grimacing:

「いいね！」 3