產業脈動 2026 年 5 月 1 日

2026-05-01 — LinkedIn 掃描 6278 擴充套件、SimpleX v6.5 Consortium 治理、LY Corp SLI/SLO 系列

LinkedIn 掃描 6,278 個瀏覽器擴充套件並以 R…

LinkedIn 掃描 6,278 個瀏覽器擴充套件並以 RSA 加密後注入每個 API 請求

404 Privacy · 2026-04-30

一項技術調查揭露 LinkedIn 在其 Web 應用程式中實作了針對 6,278 個瀏覽器擴充套件的系統性指紋識別機制,偵測結果以 RSA 公鑰加密後封裝進每一個後續 API 請求的 HTTP 標頭。

技術機制一:直接探測(Direct Probing)

LinkedIn 的 JavaScript 維護了一個包含 6,278 個擴充套件 ID 的硬編碼陣列。針對每個擴充套件,系統找到已知的 web-accessible resource 路徑,並發送 fetch() 請求至 chrome-extension://<id>/path/to/resource。若擴充套件已安裝且聲明了 web accessible resources,請求成功;若未安裝,Chrome 阻斷請求。

探測可以兩種模式執行:Promise.allSettled() 並行發送(速度快);或帶有可設定延遲的循序請求(降低在監控工具中的可見性)。

技術機制二:DOM 掃描(Spectroscopy)

輔助系統名為 Spectroscopy,遍歷整個 DOM 樹,檢查所有文字節點與元素屬性中是否含有 chrome-extension:// URL 引用,捕捉即使不在探測清單中、但會修改頁面 DOM 的擴充套件。

資料編碼與傳輸

偵測到的擴充套件 ID 被封裝為 AedEventSpectroscopyEvent 物件,以 RSA 公鑰加密,傳送至 LinkedIn 的 li/track 端點,隨後作為 HTTP 標頭注入後續所有 API 請求,在整個使用者 session 中持續存在。

隱私影響

此擴充套件清單與 LinkedIn 的職業身分直接連結,可識別求職者使用的職缺搜尋工具、開發者的安全研究擴充套件、企業使用者的 VPN/代理工具等。系統還收集包含 48 項設備特徵的更廣泛指紋資訊,使跨平台追蹤成為可能。

原始來源:404 Privacy — LinkedIn extension scanning investigation


SimpleX v6.5:多中繼廣播頻道、SimpleX Network Consortium 治理模型、不可撤銷 IP 授權

SimpleX Chat · 2026-04-30

SimpleX Chat v6.5 引入 Channels(廣播頻道)功能,同步宣布成立 SimpleX Network Consortium 治理機構,目標是以協議層面的法律架構防止未來的企業控制。

Channels 技術架構

SimpleX Channels 的設計核心是「多中繼可靠性 + 所有者持有金鑰」:

  • 多中繼設計:每個頻道使用多個獨立中繼伺服器,任何單一中繼都無法阻斷頻道
  • 金鑰主權:頻道所有者保持對自身密鑰的完全控制,中繼無法代為持有
  • 隱私模型:所有者和訂閱者的真實身分對中繼和彼此均不可知;頻道內容對中繼操作者可見(因為需要傳遞),但訂閱者身分隱藏
  • 公開發現:頻道可列於 SimpleX Directory,支援公開連結加入

SimpleX Network Consortium 治理

Consortium 架構包含:持有協議智慧財產的基金會;對所有貢獻者發放「永久、不可撤銷」授權協議(即使 Consortium 被出售或解散仍然有效);獨立董事會,包括 IP 律師 Heather Meeker;以及防止未來企業接管的結構性約束。

社群眾籌(Regulation Crowdfunding)

以「私人社群積分(Private Community Credits)」形式進行法規眾籌,用於資助伺服器運營、開發與治理,不具投機性,設計上迴避了加密貨幣的監管與投機問題。

原始來源:SimpleX Chat Blog — v6.5 Release


LY 技術部落格 SLI/SLO 系列第三篇:CUJ 分析、error budget 決策與跨職能對齊

LY Corp Tech Blog(LINE・Yahoo Japan)· 2026-04-28

LY Corporation 技術部落格發布 SLI/SLO 可靠性系列的第三篇,從先前的理論概念進入服務層面的實際應用案例,展示在 LY 服務中如何落地四步驟 SLI/SLO 框架。

四步驟框架

  1. CUJ(Critical User Journey)分析:識別使用者使用頻率最高的功能路徑,以及即使不常使用但一旦中斷影響最大的核心流程
  2. SLI 定義:選擇量測位置(API Gateway、前端、後端)與代表性 API,定義「成功請求」的技術標準
  3. SLO 目標設定:以可達成的百分比為基礎(「99.9% SLO 在 28 天允許約 40 分鐘停機」)
  4. 視覺化:以三色儀表板(綠/橘/紅)即時呈現 error budget 消耗狀態

Error Budget 的決策機制

文章展示 error budget 如何作為業務決策的量化依據:error budget 充足時,團隊可以更積極地推進新功能發布;error budget 耗盡或接近時,自動觸發穩定化措施、凍結功能發布。這將「穩定性 vs. 速度」的主觀爭論轉化為基於數據的決策流程。

跨職能對齊

文章強調 SLO 的設定需要基礎設施、產品與 SRE 團隊的共同確認,確保所有利益相關者對可靠性目標有一致理解。LY 的實作案例顯示,這個對齊過程往往比技術指標本身更具挑戰性。

原始來源:LY Corp Tech Blog — Adopting SLI/SLO for improving reliability - Part 3


End of article
0
Would love your thoughts, please comment.x
()
x