今天殆知阁又被人爆出干了一件阴间事，未经帐户所有者同意，在其所控制的实例上创建与原帐户相同的镜像帐户，并且没有做出任何声明。甚至还像正常帐户一样与其它用户互动。
这样的行为与360快视频未经授权镜像B站一样，是极其严重的侵权行为。
先说结论：daizhige的镜像账号甚至不是爬虫，是当年mao.daizhige.org和其他站互通留下的的联邦宇宙数据缓存。在服务器后台处理生成。
是明显的故意行为。
此人不得好死。
下面是分析：
嘟文右上角的时间，点开是pawoo的链接，如果是爬虫通过正常流程发嘟，是不可能这样的。
爬虫不可能精确复制关注人数和关注者人数
根据一嘟友的分析，殆知阁这些李鬼帐户并不是创建帐户然后通过爬虫抓取，而是利用 ActivityPub 网络的互联互通特性，直接将实例中缓存的外站用户数据创建为李鬼帐户。
不同实例互联互通是联邦宇宙（fediverse）的最大优点，但是难免会存在殆知阁这样的恶意节点/实例存在，那么应如何确保本站的数据不流入这些恶意节点呢？
答案是开启 secure mode 。
所需条件：服务器运行 Mastodon v3.2.0 以上版本。
具体操作步骤是：
向
.env.production文件中添加AUTHORIZED_FETCH=true。重启 Mastodon 相关服务。
运行
tootctl accounts rotate --all管理命令，更换当前实例所有帐户的密钥。
完成上述步骤后，本站在此操作之后的新嘟文就将不会流入被封禁（suspend）的实例。
下面介绍原理。
我们先看一看开启 secure mode 之后，Mastodon服务器有什么改变？
三大改变：
改变一：Mastodon 将不再为 public 属性的嘟文生成 linked-data signatures 。
改变二：所有 ActivityPub 请求均需带有 HTTP Signatures 。
改变三：所有涉及用户的API请求，必须携带有效的Token。
什么是 HTTP Signatures？
ActivityPub 协议标准中只定义了客户端与服务端，服务端与服务端之间如何通迅，以什么格式进行通迅，但对于身份认证并没有做出相应的规定。
如果不进行身份认证，必然会出现仿冒他人身份（actor）大发垃圾信息（SPAM）的情况出现。
因此，Mastodon 在实现 ActivityPub 协议标准时，采用了 HTTP Signatures 的认证方式。
Mastodon 为每个帐户（actor）生成一对RSA密钥，在向其它实例的 inbox 投递信息时，所发送的 HTTP 请求中附带有 Signature 请求头。 该请求头中，指明了本条消息的签名密钥所在位置以及签名内容。
当 inbox 收到 ActivityPub 相关请求时，Mastodon 将会验证 Signatures 请求头中附带的签名的有效性，如果该签名通过验证，则接受该请求，否则拒绝该请求。
Mastodon验签流程，参见 signature_verification.rb
什么是 Linked Data Signatures？
除了上述 HTTP Signatures， Mastodon 还支持 Linked Data Signatures。
Linked Data Signatures 顾名思义，即附加于 JSON-LD 数据中的签名。
设想这样一个场景：
你的实例加入了一个中继（relay），该中继有数百个成员，你向该中继投递一条 public 属性的嘟文，然后该中继向加入该中继的数百个实例投递转发了你的这条嘟文。
如果没有 LD-Signatures，这些实例收到中继转投的这条嘟文，因为无法确定该条消息的可靠性，将要据嘟文URL，从原站（即你的实例）尝试抓取这条消息，你的服务器必须要应对纷至踏来的抓取请求。如果你加入了一个大型中继，这将对你的服务器造成很大的压力。
如果向中继投递时附上了 LD-Signatures ，加入该中继的其它实例将便能自行验证该消息的可靠性，而无须从原站重新抓取。
但这样带来的问题是，由于 LD-Signatures 的存在，该消息是可以自验证的，所以你无法控制该嘟文的传播范围。
当你启用 secure mode 之后，由于停止了 Linked Data Signatures，当一条嘟文因为转发或中继到达新实例时，新实例为了验证该嘟文的可靠性，该实例必须从原站（你的实例）重新抓取。因此你可以控制嘟文的传播范围。
此外，Mastodon v3.2.0 后 ActivityPub 相关的 GET 请求也需要有效签名。
如果你的实例从一开始便屏蔽了实例A，并且同时开启 secure mode。
实例A将不能获得到你实例帐户的密钥，来自你实例的请求，将由于缺少相关密钥，无法验签而直接被Mastodon拒绝，因此你实例的嘟文将不会流入实例A。
如果你之前没有开启 secure mode，在开启 secure mode 之后，使用 tootctl accounts rotate --all 更换所有已存在帐户的密钥，也可以达到同样的效果。
secure mode 的副作用大概是对于旧版本（低于 v3.0.0）实例兼容性不好，您实例的数据可能无法被这些装有旧版本的实例接受。
不过，现在 v3.3.0 都已快出来了，绝大部分的中文实例也都升级至 v3.0.0 版本以上了，开启 secure mode 并不会带来太大冲击。
当然，万年不升级的 Pawoo 除外。
以下是开启 secure mode 并更换所有帐户密钥后在 Pawoo 上的体验，你可以借此大致体验一下 secure mode 对于被封禁实例的效果。
BGME实例可以看见Pawoo实例发出的消息，但Pawoo实例看不见BGME实例发出消息。
此外，Pawoo实例也将无法发现BGME实例的新用户。
位于Pawoo实例的嘟友，对不住了。