印度记录网络审查的组织在 X 收到的账号下架请求

10 月 31 日与 11 月 2 日，两份署名德里警方的通知送到 X，要求移除或扣留（withhold，只在特定国家隐藏内容）三个记录网络审查的账号。被点名的印度数字权利组织 SFLC.in 公布了 X 转来的副本，用「purportedly issued」（据称发出）形容这两份通知。到 11 月 8 日，德里警方与印度政府都没有公开确认。依 X 的说明页，扣留只限于提出请求的国家，印度以外的读者看到的内容不受影响。

事情从 10 月 29 日开始，两个印度数字权利组织与一个汇总封锁命令的 X 账号收到一封自称代表印度教民族主义组织 RSS 的律师函，要求停止记录受限的内容。依 Newslaundry 转述 IFF（Internet Freedom Foundation，印度的数字权利组织）的说法，事后有几位 RSS 干部在 X 上质疑函件的真伪。两个组织 10 月 30 日在 X 公开这封函件，第一份警方通知点名的就是这两则贴文，理由是诽谤 RSS。

根据 SFLC.in 11 月 5 日的声明，两份通知的法院命令栏位都留白，第一份援引《印度刑法典》（Bharatiya Nyaya Sanhita，BNS）第 356 条的诽谤罪。第二份通知把三个账号整个列进去，内文援引 2000 年《信息技术法》第 79(3)(b) 条与 2021 年《信息技术（中介者指引与数字媒体伦理守则）规则》，并写明依法的通知要在三小时内处理。第 79 条是安全港（safe harbour，平台不必为用户发布的内容负责的保护）条款，第 79(3)(b) 条让平台收到通知后若不移除内容，就可能失去这层保护。

X 11 月 3 日把两份通知的副本转给受影响的组织，依 IFF 的说法，信里没有交代 X 是否已照办。路透社 11 月 4 日的报道写两个组织的账号当天下午仍可浏览，X、德里警方、印度电子与信息技术部（MeitY）与 RSS 都没有回应路透社的询问。之后的状态与回应，到 11 月 8 日本文都查不到，两份通知有没有进 Lumen 这类收集下架通知的数据库也查不到。

SFLC.in 自行查证了通知的来源。发件服务器的 IP 登记在德里警方名下，也列在域名的 SPF 记录（公开列出哪些服务器可以代域名发信的设置）里，但寄到通知上两个警方邮箱的信都被退回。两项证据指向不同方向，SFLC.in 没有据此判定真伪。它向德里警方与 X 求证，到 11 月 5 日没有收到正式回复。

SFLC.in 也测试了 X 的执法机关请求表单（Law Enforcement Request form）。X 的法律请求入口（Legal Request Portal）会发验证链接到官方邮箱，这张表单没有。SFLC.in 11 月 4 日用虚构的电子邮件针对自己的贴文提交请求，X 照样登记了。同一天下午表单已经改成发验证码到提交的邮箱，到 11 月 8 日 X 没有公开说明这项漏洞与修正。

导读观点

平台判断通知是否有效时，要看依据的法律与提交者，受影响的人则要先收到通知才能申诉。通知之外，印度还有 2000 年《信息技术法》第 69A 条这条路径，由中央政府以书面记录理由的命令封锁。依开发者公开的 Apple 通知，10 月 3 日 Bitchat 从印度的 App Store 下架引用的是第 69A 条（见Bitchat 在印度下架的争议）。

本文的推论是，通知加上三小时期限，平台要在很短的时间内判断请求是否有效。表单有没有验证提交者的身份，也就影响冒名的请求能否进入平台的处理流程。SFLC.in 询问 X 两份通知经由哪个渠道送出，到 11 月 5 日没有得到答案。

根据 X 的说明页，X 用它取得的位置信息判断用户所在的国家，被扣留的贴文与账号会显示提示。一种提示表示 X 因法院命令这类有效的法律要求而扣留，另一种表示 X 依当地法律、回应经特定支持渠道提交的举报而扣留。两份通知的标题是 Illegal Content Report，本文推论若被扣留，比较可能显示依当地法律扣留的提示。X 没有说明这批请求的分类。

同一份说明页也写，除非受到法院密封命令这类限制，X 会发信到账号登记的邮箱或在 App 内通知受影响的人。通知通常附上请求的副本，依法律要求扣留的可以直接回信申诉，依当地法律扣留的经由帮助中心申诉。本文据此推论，登记邮箱没人收信的组织可能不知道账号被扣留，也拿不到请求副本。在印度运营组织账号的人可以定期确认登记邮箱，收到 X 的通知后依通知里的渠道申诉。

针对通知引用的诽谤罪，SFLC.in 的分析是 BNS 的刑事诽谤属于非可逮捕罪行，警方要有治安法官的命令才能行动。SFLC.in 也主张，德里邦政府 6 月授权发这类通知的官员不包含通知上署名的职位，限制整个账号而不是个别内容也不符必要性与比例原则（这些是组织的分析，不是法院或政府的认定）。路透社附上印度政府对平台指令的一般说法（不是针对本案），指令针对违法或误导的内容并尊重合法的言论。

依 Inc42 与 SFLC.in 转述《印度快报》（Indian Express）的报道，MeitY 已开始讨论是否重新考虑社交平台的安全港。依 Inc42 的转述，报道写政府在研究把保护限缩在网络服务运营商、电信运营商与点对点通信平台，讨论仍在探索阶段。SFLC.in 转述的理由是平台用算法策展与放大内容，已是发布者。MeitY 到 11 月 8 日没有公开说明，把警方通知与安全港的讨论放在一起是本文的连结，因为两者都涉及第 79 条。

SFLC.in 引用最高法院的先例，主张第 79 条是法定保护，不是行政裁量可以撤回的特权。它也提醒，平台若要为用户内容负责，政治言论、新闻与对官员的批评最容易被过度移除。MediaNama 9 月针对政府消息人士对 Meta 的说法写过分析，认为当时的立场全靠匿名简报，安全港是平台被告时提出的抗辩、由法院判断。分析早于这次的报道，所评的消息人士说法与这次报道相近，把两者并列是本文的连结。

《网络安全法》2025 年修正版（2026 年 1 月 1 日施行）第五十二条规定，网信部门与有关部门发现禁止发布或传输的信息，要求网络运营者停止传输。来源于境外的信息，则通知有关机构采取技术措施阻断，条文没有写法院程序。《网络信息内容生态治理规定》第十六条要求平台设置投诉举报入口，本文查到的条文没有写处置内容时要通知发布者，也没有写发布者可以提出异议。Apple 2 月 28 日通知 Bitchat 的开发者依国家网信办的要求从中国的 App Store 下架，通知引用《具有舆论属性或社会动员能力的互联网信息服务安全评估规定》第三条，没有附命令本身。

在中国大陆，GreatFire 对 twitter.com 的量测显示，最近 70 次有结论的测试有 99% 失败（页面 FAQ 的最后测试日是 10 月 12 日，只涵盖 twitter.com）。X 与 Meta 的透明度报告按国家列出法律请求，Google 的「Government requests to remove content」按国家与半年度列出，Lumen 则收集平台转来的下架通知。本文没有取得这几个来源的最新数字，也查不到台湾与中国大陆的请求数，所以不写这两地的数字。香港有一个 2022 年的旧数字：Hong Kong Free Press 2023 年 5 月 9 日引述 Google 的透明度报告，香港政府 2022 年全年要求 Google 移除 330 个项目，其中 57 个与国家安全有关。

印度以外的读者不必做任何设置。之后可以留意 X 是否在印度扣留这些账号、德里警方或 MeitY 是否公开回应，以及安全港的讨论是否变成正式的修法或规则草案。

EFF 11 月 6 日的文章要求平台公开收到的请求、通知受影响的用户，并让限制措施有申诉的渠道。比较各平台的做法时，也可以看平台有没有验证提交者的身份、通知有没有附上法院命令。依路透社转述的政府说法，指令针对违法与误导的内容，可以问平台在期限内能否分辨通知的真伪与合法性。安全港收紧后，平台是更精准地移除违法内容、还是移除更多合法言论，本文没有找到公开的评估。