社會第 70 期

以保護兒童為名的法律,正在改變網路的入口

兒童保護是真正的議題。但解決方案非得是把每個人的身分資訊刻進作業系統嗎?

以保護兒童為名的法律,正在改變網路的入口

前言

各位讀者,上週 Linux 社群發生了一點小風波。大多數 Linux 發行版所使用的核心系統管理員 systemd 新增了一個名為 birthDate 的欄位。這個欄位會在作業系統層級儲存使用者的出生日期

systemd 的創辦人 Lennart Poettering 澄清說:「這只是一個選填欄位,既不是政策引擎,也不是應用程式 API。」但追根究底這個小欄位為何被加入,就會看到一幅更大的圖景。是為了應對加州、科羅拉多州、巴西等地已通過的年齡驗證法1

然而仔細檢視這些法律,發現它們並非單純的兒童保護政策。而是強制要求建立一套基礎設施,讓作業系統能將使用者的年齡即時告知所有應用程式。而在這些法律背後,有一位出乎意料的受益者。

作業系統檢驗年齡的世界

2025 年 10 月,加州州長蓋文紐森簽署了 AB-1043(數位年齡保證法),該法將於 2027 年 1 月 1 日施行。其核心內容可歸納如下:

所有作業系統供應商在建立帳號時,必須收集使用者的出生日期或年齡。並以此資訊為基礎,當應用程式開發者提出請求時,透過即時 API 傳遞使用者的年齡區間(13 歲以下、13~15 歲、16~17 歲、18 歲以上)。

這裡**「作業系統供應商」的定義至關重要。根據法律原文,指的是「開發、授權或管控電腦、行動裝置或其他通用計算裝置之作業系統軟體者」。Windows、macOS、iOS、Android 當然在列,Linux 發行版以及 Valve 的 SteamOS 也涵蓋在內**。

這與在特定成人網站上進行年齡驗證完全不同層級。從開啟裝置的那一刻起,使用者的年齡資訊就內建於作業系統中,所有已安裝的應用程式都能查詢這些資訊——這是一套常態化的身分驗證基礎設施。

這不只是加州一州的規定。猶他州(SB-142)和路易斯安那州(HB-570)已施行類似法律,科羅拉多州(SB26-051)已以 28 比 7 的票數通過參議院,正在眾議院審議中。紐約州(S8102A)更進一步,禁止自我申報,要求使用生物辨識或政府身分證件驗證。伊利諾伊州、俄亥俄州、喬治亞州、南卡羅來納州也有類似法案待審,聯邦層面則有 KOSA 和 ASAA 正在推進中。

這些法律的共同模板是 ICMEC(國際兒童失蹤與剝削預防中心)所擬定的「數位年齡保證法(Digital Age Assurance Act)」。但有一個值得注意的模式:這些法律將義務加諸於應用程式商店和作業系統,卻未對直接將內容暴露給兒童的社群媒體平台課予新的義務。

遊說:執筆的手,出錢的手

根據 2025 年 7 月彭博社的報導,Meta 曾資助一個名為數位兒童聯盟(Digital Childhood Alliance, DCA)的保守派兒童保護組織聯盟。DCA 自稱由 50 個以上的保守組織組成,但實際公開可確認名稱的組織僅有 6 個。

今年 3 月,一位 OSINT(開源情報)2​ 研究員公開了調查結果,追蹤了 IRS 稅務申報表、參議院遊說公開資料、各州(州)倫理委員會資料庫等公開紀錄。其內容整理如下:

DCA 的法律主體問題:DCA 的 EIN(稅務識別號碼)直到最近才確認,2024 稅年度總收入低於 2 萬 5 千美元(990-N 簡易申報)。一個在 20 個以上州推動立法運動的組織,正式收入卻不到 2 萬 5 千美元,這意味著實際資金並未透過這個法人實體流動。

路易斯安那州案例:提出 HB-570 的 Kim Carver 議員公開承認,Meta 的遊說者直接提供了法案條文。Meta 為這單一法案動用了 9 家遊說公司的 12 名遊說者,支出至少 32 萬 5 千美元。法案在每個階段都以全票通過,而需要 12 名遊說者的原因不是表決,而是掌控法案條文的措辭。

Meta 的遊說立場:透過科羅拉多州州務長官的 SODA API 確認的 117 筆遊說紀錄分析顯示,Meta 對規範自身的社群媒體法案採取「修正(Amending)」立場,而對將負擔加諸於 OS 供應商的法案則採取「關注(Monitoring)」立場。規範自己的法律要抗爭,規範競爭對手的法律就旁觀。

有先例可循:2022 年 3 月,華盛頓郵報報導 Meta 僱用共和黨顧問公司 Targeted Victory,對 TikTok 展開全國性的抹黑運動。該運動在地方媒體植入署名投稿,實際上將源自 Facebook 的危險趨勢歸咎於 TikTok。運動的核心框架?「TikTok 對兒童有害。」當時與現在的策略手冊驚人地相似。

換句話說,一家靠收集使用者數據獲利的手,撰寫了強制所有作業系統收集年齡數據並向所有應用程式廣播的法律條文,同時設計讓自家平台不受該法管轄。

同樣的問題,截然不同的設計

在此處檢視 EU 的做法,對比便十分鮮明。

EU 的數位服務法(DSA)將年齡驗證義務加諸於月活躍使用者達 4,500 萬以上的超大型線上平台(VLOP),而非作業系統。而且針對開源專案設有 5 項豁免條款。

技術路徑也不同。EU 依據 eIDAS 2.0 規定正在開發歐洲數位身分錢包(EUDI Wallet),核心是零知識證明(ZKP)3​。使用者無需暴露出生日期或身分資訊,只需證明「我年滿 18 歲」這一事實即可。就像進酒吧時不是出示整張身分證,而是出示一張只蓋了「此人是成年人」印章的卡片。

EU 的參考實作以 Apache 2.0/EUPL 授權開源公開,非商業專案使用成本為零。2025 年 10 月公開了第二版,目前已在 5 個會員國(丹麥、希臘、西班牙、法國、義大利)進行試點運行。

當然,EU 的做法也有侷限。錢包 App 依賴 Google Play 服務或 iOS,因此在 GrapheneOS 等隱私導向的發行版上無法運作。而且 ZKP 是密碼學機制,不是信任架構。若發證方與驗證方串通,仍可能進行活動追蹤。

但結構性的差異是明確的。

同樣是「保護兒童」的目標,一個在建立證明架構,另一個在建立監控基礎設施。

Oz 的視角

老實說,我關注這個議題時,比起技術問題,更擔心的是抽象化錯誤。

原文部落格作者精準地指出了這一點。這場辯論的核心失誤在於混淆了內容審查與監護人角色(guardianship)。內容審查是「是否要封鎖這個內容」的分類問題。監護人角色是「這對我的孩子是否合適、何時可以例外」的情境判斷。前者在技術上可以部分解決,但本質上是關係性的、情境性的,後者則是如此。

在制定 GTM 策略時,我見過無數次同一個模式:將複雜的社會問題包裝成一個技術解決方案來銷售。年齡驗證法正是這個模式。「兒童有危險」→「確認身分就行了」→「在作業系統上建立 API。」這條邏輯鏈中缺失的,是對傷害實際發生環節的分析。我們國家其實也是這樣開始的——不就是遊戲宵禁制度嗎。

對兒童造成傷害的,不是內容的存在本身。而是推薦演算法、暗黑設計4​、令人成癮的指標、獎勵擴散的商業模式。然而這些法律既不規範推薦演算法,也不禁止暗黑設計。取而代之的是要求作業系統建立年齡驗證 API。

而且一旦建成的基礎設施,從不只會用於原始目的。為年齡而建的基礎設施,可以擴展到位置、公民權、法律地位、平台政策——下一個恐懼所要求的任何東西。這就是有限度的驗證(check)變成通用閘門(gate)的方式。我同意原文作者(同時也是一位父母)的話:兒童需要保護。但不需要網路上有許可制度。

結語

第一,美國的年齡驗證法以兒童保護為名,但技術實質是建立 OS 層級的常態化身分驗證基礎設施。 一旦建成,用途很可能不會只停留在年齡驗證上。

第二,這些法案中有相當一部分背後是 Meta 有組織的遊說,且法案設計上社群媒體平台被排除在規管之外。不規範兒童傷害實際發生環節的兒童保護法,難以名副其實。

第三,EU 對同一問題選擇了隱私保護型路徑(ZKP + 開源 + 以平台為中心的規管)。雖不完美,但至少與「把每個人的年齡刻進作業系統」的做法在設計上根本不同。

如果想深入了解這個主題,建議直接查看下方參考資料中 GitHub 上的 OSINT 調查倉庫。每項主張都附有原始公開紀錄的連結。下一期電子報將探討這個結構的另一面——AI 時代中隱私保護與便利性之間的設計取捨。

參考資料 & 延伸閱讀

作者 安光涉(Oswarld) 現任世宗大學兼任教授,INLEVEL9 策略顧問。職涯經歷、研究、著作與近期活動會持續更新在作者介紹。 最新動態 · 2026年7月:HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI

각주

  1. 年齡驗證法(Age Verification Law):強制要求在線上服務使用時驗證使用者年齡的法律。過去僅限於成人內容網站,但近期已擴展至作業系統與應用程式商店。

  2. OSINT(Open Source Intelligence):系統性地收集與分析公開可取得資訊(新聞、公共紀錄、社群媒體、企業登記資訊等)的調查方法。不僅情報機構使用,調查報導中也廣泛應用。

  3. ZKP(Zero-Knowledge Proof,零知識證明):在證明自己知道某項資訊的同時,不揭露該資訊本身的密碼學技術。例如證明「我年滿 18 歲」但不透露出生日期。是 EU 數位身分錢包的核心技術。

  4. 暗黑設計(Dark Pattern):誘導使用者做出非預期行為(如維持訂閱、同意個資收集等)的 UI/UX 設計手法。簡單來說,就是把「不同意」按鈕做得極小,把「同意」按鈕做得又大又醒目。