運営のアクティビティーがないサーバーの新規登録を非活性にする

[saschanaz]

Summary

mastodon/mastodon#29318 マストドンはそうするらしいので

Purpose

開設あとそのまま放置されたサーバーの数をできるだけ減らして、そういうサーバーからスパムが来ないようにするため

Do you want to implement this feature yourself?

• Yes, I will implement this by myself and send a pull request

[GrapeApple0]

Related: #13122

[samunohito]

引用（機械翻訳込み）

レポートを表示する権限を持つユーザーが 1 週間以上アクティビティ (サーバーへの認証されたリクエスト) を行っていない場合、オープン登録から自動的に切り替わります。
たとえばモデレートに外部ツールを使用している場合は、DISABLE_AUTOMATIC_SWITCHING_TO_APPROVED_REGISTRATIONS 環境変数を使用して無効にできます。電子メール ドメイン許可リスト (EMAIL_DOMAIN_ALLOWLIST) を使用している場合も無効になります。

仕様は…環境変数名はMisskey側の規則に合わせるとして、上記をそのまま踏襲でよさそうですかね？

[samunohito]

仕組みとしていったん実装してしまうのもアリだと考えていますが、DISABLE_AUTOMATIC_SWITCHING_TO_APPROVED_REGISTRATIONSを設定して放置というパターンを懸念しています。

/api/metaで上記設定値とモデレータの最終アクティビティ日時をとれるようにして連合先での自衛に役立てるようにすれば…とも考えましたが、乞うご意見…

[meronmks]

DISABLE_AUTOMATIC_SWITCHING_TO_APPROVED_REGISTRATIONSを設定して放置はあり得ると思うので無効になるのではなく無効になる期間が伸ばせるだけ（1weekが3weekあたりに伸びるだけ）とかに抑えた方がよさそうな気がする。

どうしても止めたいなら責任もってソース改変してでもいい気がしますし

[tkmrgit]

#13344 新規登録開放についてこちらを提出しています
MisskeyはMisskeyのやり方で対応しても良いかなと思います(もちろんMastodon準拠の仕様もあり)

[samunohito]

（強火で行きたい気持ちがある）

しました

[Sayamame-beans]

非活性になった時は管理者/モデレーターに通知出しておいても良さそうです。
Misskey通知 + メール

[tkmrgit]

#14729 (被ったので閉じてます) では以下追加で提案しています

再度管理者またはモデレーターがログインして解除操作を行わない限り新規登録をできないようにする

つまりログインしてもそのままでは解除されないような仕組みが必要と思われます。また、この一定期間ログインの対象にはアプリによるログインが含まれないようにするのが望ましい

[samunohito]

みなさまの書き込みを参考に、実装方針の草案書きました。
ご意見募集中…

• configで非アクティブの猶予を伸ばせるようにする
  • 放置の懸念があるので無効にできるようにはしない
  • 最長90日で、それ以上が設定された場合は90日に丸められる
• 非アクティブのカウンタリセットはisModerator == trueな人がアクティブになったとき
  • リセット処理はusersService.updateLastActiveDateと同じタイミングでよいとおもう
  • 自分の知る限り「アプリによるログイン」かどうかを判定するのは難しいかも…？出来る方法があれば情報提供求む
• カウンタ超過で新規登録を閉じる
  • 発動時に「招待制」に設定変更（新規登録は閉じられる）
    • 既存の招待制の設定をそのまま使うので自動解除はされない（モデレータが手で戻す必要がある）
  • 発動時にモデレータへのmail発信、通知送信。あとSystemWebhook送信もあると良い？

[syuilo]

猶予は1週間のハードコードで良さそう

[samunohito]

反対するとかじゃないんですが、理由を伺っても…？

[syuilo]

通常であれば自分の管理運営しているサーバーに1週間に1回くらいはアクセスすると思う
それ以上アクセスなかったら放置と見做して良さそう

[samunohito]

うーむ

[7shironana]

実際、今回のスパム事案でも管理者と思われる方の最終アクセスが3週間前となっていたようなので1週間のハードコードでいいんじゃないかと…

[shiosyakeyakini-info]

管理用のアカウントと通常使うアカウントを分ける運用をしていて、メールで通報をチェックするようなユースケースでは、管理用のアカウントに頻繁にログインすることがなくなるので、意図せず招待制になる可能性があるように思います。

（管理・モデレーション用のアカウントを普段使いしてしまうと、絵文字の画像を誤ってドライブから消したり、自分のノートを消そうとして誤操作で他人のノートを消したりするリスクがあります。）

[yuba]

猶予期間を設定値でなく固定値にするのに賛成ですね。

この猶予期間は鯖缶の好みとかライフスタイルによって決めるようなものではなくて、misskeyというソフトウェアが管理に熱心でない鯖缶を見分けるための閾値なので、鯖缶が決めるような性質のものではないと思い。

[fruitriin]

期間の是非は置いておいて固定値でいいように思う
(1週間は短いと思う……鯖缶を忘れてバカンスとかしたらあっという間だ)

[fruitriin]

ところで、期限切れる前にn日前に「続けるならログインしてね」　みたいなメール欲しいかも

[CAT5NEKO]

運用方法は数多あると思うのですが今回非活性を実装する目的としては、管理放置状態のサーバーのスパム流入を抑制して、他サーバーへの被害拡大を防ぐ目的にあると思いますので、支障がない程度に厳格な固定値の猶予が適当であると思います。

（管理と普段使いのアカウントを分ける運用をされるケースが多いような場合には、非活性フラグを検知する特別なロールを作るのもありだと思います。）

[syuilo]

管理用のアカウントと通常使うアカウントを分ける運用の場合でも、1週間に1回程度はダッシュボード(コントロールパネル)にアクセスしてサーバーの状態をチェックした方が良いと思うから、その場合でもやっぱり1週間の固定値で妥当な気がするわね
あと通常使うアカウントでアクセスしたときにも管理用のアカウントでアクセスしたと見做せるようにする改修の余地も多いし

[syuilo]

鯖缶を忘れて1週間以上バカンスした場合はそれは事実上放置されている状態と見做していいんじゃないかしら

[yuba]

バカンスで一週間はすぐにありえるというのも真と思いつつ、
新規登録が閉じられるのはサーバー運営にとってそんな致命的なことではないと考えると、そこまで気にすることでもないような

[noellabo]

管理用のアカウントと通常使うアカウントを分ける運用をしていて、メールで通報をチェックするようなユースケースでは、管理用のアカウントに頻繁にログインすることがなくなるので、意図せず招待制になる可能性があるように思います。

（管理・モデレーション用のアカウントを普段使いしてしまうと、絵文字の画像を誤ってドライブから消したり、自分のノートを消そうとして誤操作で他人のノートを消したりするリスクがあります。）

アクティビティのチェック対象になるポリシーをわけて、あえて管理者やモデレーターのロールを付与していないメインアカウントを使っているサーバオーナーでも、そのチェック対象ポリシー適用したロールだけ付与しておけばいいようにするとか？

[syuilo]

そういった実装も考えられるわね
まあ工数的にアカウントが分かれている場合の対応は後々で良さそう

[samunohito]

皆様、ご意見ありがとうございました。
以下の方針で進めようと思います（過不足ありましたらご指摘いただけると助かります… 🙏 ）

• 非アクティブの猶予
  • 7日とする
  • 非アクティブの猶予2日前、1日前、当日になったら対象アカウント¹に向けて通知²
  • 放置の懸念があるので無効にできるようにはしない
• 非アクティブのカウンタリセット
  • 対象アカウント¹のいずれかがアクティブになったときにリセット
  • アクティブの検知（リセット処理）はusersService.updateLastActiveDateと同じタイミングでよいとおもう
• カウンタ超過（8日目になったら）
  • 発動時に「招待制」に設定変更する（新規登録は閉じられる）
    • 既存の招待制の設定をそのまま使うので自動解除はされない（モデレータが手で戻す必要がある）
  • 発動時に対象アカウント¹への通知²

実装は複数段階に分けてprする想定でいます（上から順にやるイメージ）

• 根幹の処理
  • アクティブ検知によるリセット
  • 非アクティブ検知による招待制への移行
• 通知処理
  • isModerator == trueなアカウントへのmail発信と通知送信
  • SystemWebhookの追加
• 対象ユーザの拡大
  • 特定のロールによるアクティブ・非アクティブの検知に対応

Footnotes

1. isModerator == trueなアカウント、特定ロールなどのポリシーが適用されたアカウント ↩ ↩² ↩³

2. 対象アカウントに対してmail発信と通知送信を行うのと、SystemWebhookに新設したイベントを用いて送信 ↩ ↩²

[samunohito]

非アクティブのカウンタリセット

これは「対象アカウントのいずれか」を想定していました（記載修正済み）

[syuilo]

YOSASOU