こういうことかな? #fedibird
主に、Fediverseへの関心に基づいた投稿を行うアカウントです。DTP・印刷に関する話をしたり、同人の話をしたり、カレーをブーストしたりします。
Mastodonのcollaborator(開発者の一員)です。また、独自機能を盛り込んだFedibirdを管理・開発しています!
Mastodonサーバ『fedibird.com』の管理者アカウントでもあります。ご連絡は当アカウントへ、サーバインフォメーションについては https://fedibird.com/about/more と @info を参照してください。
ちなみにこれは、Fedibird固有機能で『自分の投稿文字列に制限をかける』やつです。
公開投稿を禁止したり、投稿を禁止することもできます。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このへん拾っておけばいい?
QT: https://fedibird.com/@noellabo/109317294765022697 [参照]
DMの内容が当事者以外にみえるケースですが、
まず、そのDMの発信元か配送先であることが必要です。
DMを送信した人のサーバと、宛先に指定した人のサーバ(複数)のデータベースに内容が記録されます。
無関係のサーバからはみえません。
それから、DMの当事者の誰かがこれを通報した場合、通報の宛先となったサーバの管理者およびモデレーターがこれを確認できるようになります。
(悪い改造がされていなければ)管理者やモデレーターはMastodonの操作を通じてDMをみることはできません。
ただし、データベースに直接アクセスできる人は、DMの内容を取り出して見ることができます。
これは主に管理者が該当しますが、技術担当が別にいる場合や、ホスティングで委任している場合もありますので、ケースバイケースです。
このほか、警察や軍など司法・国家機構からデータベースを明け渡すよう求められたり、クラッキングによりデータを盗まれるケースもあります。
こうした場合に、サーバ上に鍵が存在しない方法で暗号化されていれば内容は読めないのですが、平文で保存されておりそのまま読める状態になっています。
それから、FediverseはMastodon以外の様々なタイプのサーバがあり、DMに相当するものをどう扱うかは未知数です。
Pleroma、Misskeyなどよく知られたサーバであれば期待通り扱ってくれることが期待できますが、
最悪の場合、管理者が任意に閲覧できるサーバであることも、誰でもみられる状態で受け取るサーバも考えられます。
先に悪い改造と申しましたが、見えるように改造されていた場合は、これを防げません。
従って、宛先に指定するサーバが信頼できるかどうかも考えなくてはなりません。
よく知った相手のサーバは多分大丈夫だろう、ぐらいの判断は可能かと思いますが、まぁ知らないサーバのことは判断できませんよね。
またこれは別の問題ですが、添付したデータ(画像や動画)はURLが漏洩すると誰でも参照できます。
また、オブジェクトストレージに保管していることが多いため、AWSだったりWasabiだったりに監視されることもあります。
また、添付データ(画像や動画)をモデレーション対象とするサーバもあります。
というわけで、
まあ最悪漏れてもいい内容までにしておきましょう。
さきほどのDMの話とも関連しますが、
フォロワー限定の投稿を安心して運用するために、フォロワーはよく選んで下さい。
特に、FollowBotやGhost、素性の怪しいアカウントに注意してください。
FollowBotやGhostは、あなたをフォローして投稿を集めます。
この時、公開している投稿だけを収集するのであればまだいいのですが、フォロワー限定の投稿も一緒に収集しています。
一見するとBot自体は無害に見えるかもしれませんが、受け取ったサーバ側で悪用されることもあります。Botの所属サーバも判断材料です。
素性の怪しいアカウントは、身分を隠したストーカーかもしれませんし、保護者や学校の先生かもしれませんし、国家の捜査機関かもしれません。
FedibirdではBotフラグのついたアカウントはフォローリクエストになってワンクッション入りますが、Botが必ずBotフラグをつけているとは限りません。
全部公開で投稿するつもりの人はあまり気にする必要はないですが、肝心なときにフォロワー限定が機能しなくなることは留意しておきましょう。
これは、いざというときのために利用者ができるリスク回避の話をしてたときのやつ
QT: https://fedibird.com/@noellabo/109918477262246448 [参照]
一般の利用者としてできる最大のリスク回避は、ホーム運用することです。
つまり、普段はローカルを中心にコミュニケーションをとっていて全然構わないのですが、
仲良くしている、あるいはずっとその人の投稿を見ていたい人を、フォローしておくことです。
ついでにいうと、みたくない人はフォローしないことです。
ホームに切り替えても、困らない状態にしておきます。
そうすると、いつでも別のサーバに移れるようになります。
あるいは、ローカルの雰囲気が悪くなったときに、ホームに切り替えられます。
※ フォローリストを書き出ししておきましょう。アカウントやサーバが死んだ時のバックアップです。
サーバを選ぶリスク、たいして個人情報とか預けるわけじゃないので、いつでも逃げられるようにさえしておけば、たいしたことありません。
まあ、コンテンツ発信とか信用を扱ってる場合はそれだけでは足りませんが、それはまた別のお話です。
Mastodonは基本的に所属サーバだけを信頼してもらうモデルで、クライアントは所属サーバとだけ通信して、リモートの情報もすべて所属サーバから取得する。
Mastodon本体は基本的にそういう設計で作られているけど、
たとえば管理者がGoogleのアクセス解析をつけていたり、広告を挟んだりすれば、あまり意味を成さなくなります。
ユーザー側で、リアルタイム翻訳使ってみたりね。
あと、クライアントアプリにはリモートのURI / URLが渡されているので、それを使って直接取得しにいくことができ、この場合も所属サーバに閉じ込めたモデルにはならなくなる。
クライアントアプリは、所属サーバへのAPIアクセス以外に、任意にリクエストが可能なので、追加機能を提供することができる。翻訳もそうだし、外部検索サイトに対応したり。
広告がついてたり、自サーバを経由して何かするタイプは、もうほとんど全面委任するしかないです。
鍵を預けて全部まかせるエージェントになるので、何をしているか明示していて、妥当な方法をとっている、できればソース公開のものを選ぶと良いです。