Google 開源 C++ 內容憑證函式庫 Credentio、Spotify 拆解 LLM 代打 A/B 測試的統計前提、Cloudflare CT 監控服務轉正式版
developers.googleblog.com · engineering.atspotify.com · blog.cloudflare.com · 2026-08-13
Credentio：本機驗證 C2PA 內容憑證的 C++ 函式庫
Google 開源了 Credentio，一個用於處理 Coalition for Content Provenance and Authenticity（C2PA）內容憑證的 C++ 函式庫。它讓應用程式可以在本機直接驗證媒體檔案的來源與簽章，不必把檔案上傳雲端伺服器比對，藉此避開隱私外洩、延遲與檔案大小限制等問題。C2PA 是由 Adobe、Microsoft、Google、Intel、BBC 等機構組成的聯盟制定的開放規格，目標是在圖片、影片、音訊等媒體中嵌入可驗證的「內容來源」中繼資料（誰拍的、有沒有被 AI 編輯過），對抗深偽與去背景資訊。Credentio 目前支援 C2PA 規格 2.2 與 2.4 兩個版本，已用於近 40 款 Google 內部符合規格的產品中。
用途、格式支援與建置方式
函式庫可解析多種檔案格式的憑證資訊，包括圖片（JPEG、PNG、WebP）、影音（MP4、MOV）與文件（PDF、DOCX），並針對大檔驗證做了記憶體用量優化，同時支援可設定的信任清單（trust list）比對簽章鏈。原始碼放在 Google 自建的 mediaprovenance.googlesource.com，以 Apache 2.0 授權發布，建置工具鏈為 Bazel，需要 Clang、Bazel 與 Git。專案提供一個命令列驗證工具，用法如下：
bazel run tools:c2pa_validate -- \
--asset=/path/to/asset.jpg \
--claim_signer_trust=/path/to/claim_signer_trust_anchors.pem \
--tsa_trust=/path/to/tsa_trust_anchors.pem官方部落格未列出完整 API 類別簽章，但明確定位 Credentio 可嵌入桌面應用、行動軟體或後端媒體處理服務，作為離線驗證元件而非雲端服務的替代品。
Spotify：LLM 能不能代替真人跑 A/B 測試
Spotify 工程團隊發表分析，探討能否用大型語言模型（LLM）的預測結果取代真人在 A/B 測試中的行為，結論是「只有在特定假設成立時才成立，而不是在方法設計上天然成立」。真人 A/B 測試的因果推論正確性來自隨機分派的實驗設計本身，而拿 LLM 輸出取代真人結果則必須額外假設兩個條件成立才站得住腳。研究團隊在 Spotify Engineering 部落格中，用 Upworthy Research Archive（一個公開的新聞標題 A/B 測試點閱率資料集）做實測，並在論文《Statistical Foundations of LLM-based A/B Testing》中提出完整的統計框架。
兩個必要假設：代理性與可比性
第一個條件是代理性（surrogacy）：LLM 的輸出必須完全中介（fully mediate）處理效應對真人結果的影響，也就是「處理對使用者的所有意義」都要能反映在 LLM 的預測裡，否則替代就會失真。第二個條件是可比性（comparability）：LLM 預測與真人行為之間的校準函數（calibration function），必須在不同實驗之間保持穩定；一旦測試的是全新型態的處理（novel treatment），這個假設就愈不可信。實測數據顯示，未經校準的原始 LLM 預測只能還原真人處理效應的 39%，且方向性偏誤明顯地把效應拉向零；用線性校準（OLS）則在 Placebo 檢定中偏離真人基準 3.8 個標準誤，判定失敗，反倒是隨機森林、梯度提升樹等非參數方法能捕捉到非線性關係、把落差補上。
校準無法迴避真人資料，反而暴露悖論
論文作者指出一個悖論：LLM 對 A/B 測試最有價值的場景，正是全新的、缺乏歷史資料可供校準的處理方式——而這恰好是校準最不可靠的時候。要校準 LLM 預測與真人行為的關係，本身就需要先收集一批真人的實際反應數據，這削弱了「用 LLM 取代真人以節省成本」的效率承諾。文章結論明確寫道，對於真正的產品創新測試，真人實驗仍然「不可或缺」（indispensable）。
Cloudflare Certificate Transparency Monitoring 轉正式版
Cloudflare 宣布 Certificate Transparency（CT）Monitoring 服務正式轉為 GA（Generally Available）。CT 監控的原理，是持續掃描公開、可驗證的憑證透明度日誌（append-only 的 Merkle tree 結構），只要有人為某個網域簽發了新的 TLS 憑證，該憑證都會被寫進日誌並可被外部偵測——這套機制正是為了防範任何憑證授權機構（CA）遭入侵或濫權簽發假憑證，2011 年 DigiNotar 遭駭並偽發 *.google.com 憑證即是典型案例。Cloudflare 這項服務自 2019 年 Beta 上線以來，已在超過 650,000 個客戶網域上運作，詳見官方公告。
GA 版解決的核心問題：警報疲勞
Beta 版最大的問題是警報疲勞（alert fatigue）：系統對每一張新簽發或更新的憑證都會發信通知，包含 Cloudflare 自己例行管理、每年最多換發六次的 Universal SSL 憑證，導致客戶抱怨「被大量完全正常的憑證更新訊息淹沒」。GA 版把原本互相獨立的「憑證發放系統」與「CT 警報系統」串接起來，共用 spki_sha256（憑證公鑰 DER 編碼 SubjectPublicKeyInfo 的 SHA-256 雜湊）作為識別碼。這個識別碼在金鑰生成時就已存在（早於憑證簽發）、從 pre-certificate 到最終憑證維持不變、且憑證發放端與 CT 警報端能各自獨立計算出相同值，因此警報系統只要比對這個雜湊，就能過濾掉 Cloudflare 自己核發的憑證，把通知收斂到真正可疑的簽發行為。
原始來源：Introducing Credentio（Google Developers Blog）、When Can LLMs Replace Humans in A/B Tests?（Spotify Engineering）、Certificate Transparency Monitoring is now generally available（Cloudflare Blog）