Chrome 81 淘汰與移除功能

Joe Medley
Joe Medley

淘汰並移除「basic-card」支援付款處理常式

這個版本的 Chrome 移除 Payment Request API 的基本卡片 polyfill 。因此,Payment Request API 的停用日期為: iOS Chrome。詳情請參閱重新考慮 iOS 的付款要求

意圖移除 | Chrome 平台狀態 | Chromium 錯誤

從 BasicCardRequest 中移除 supportedType 欄位

正在為 "basic-card" 付款方式指定 "supportedTypes":[type] 參數 僅顯示要求類型的資訊卡,也就是「信用卡」、「"debit"」或 "prepaid"

卡片類型參數已從規格中移除,目前已從規格中移除 Chrome,因為判斷卡片類型不易判斷。商家 今日就必須與 PSP 確認卡片類型,因為他們無法信任該卡片 在瀏覽器中輸入篩選器:

  • 只有發卡銀行知道卡片類型,才能確定卡片是否提供確定性且可下載的卡片 因此模型無法準確預測 儲存在瀏覽器中的卡片類型
  • 「基本卡片」Chrome 的付款方式將不再顯示 Google 提供的卡片 付款 (可能與發卡銀行聯繫)。

意圖移除 | Chrome 平台狀態 | Chromium 錯誤

移除 元素

Chrome 第 81 版會移除 <discard> 元素。這個架構只會在 Chromium 中實作。 因此無法進行互通操作在大多數情況下 替換為 display 屬性的動畫和移除項目 (JavaScript) 回呼/事件處理常式。

意圖移除 | Chrome 平台狀態 | Chromium 錯誤

移除 TLS 1.0 和 TLS 1.1

TLS (傳輸層安全標準) 是確保 HTTPS 安全的通訊協定。這個平台提供 可回溯回溯至近二十年的 TLS 1.0 SSLTLS 1.0 和 1.1 都有許多弱點。

  • TLS 1.0 和 1.1 在轉錄稿雜湊中都使用 MD5 和 SHA-1,這兩種雜湊皆較弱的雜湊。 就會看到已完成訊息
  • TLS 1.0 和 1.1 會在伺服器簽章中使用 MD5 和 SHA-1。(注意:這並不是 憑證中的簽章)。
  • TLS 1.0 和 1.1 僅支援 RC4 和 CBC 加密。RC4 故障且 已移除TLS 的 CBC 模式架構出現瑕疵,且容易遭受攻擊 網路攻擊。
  • TLS 1.0 的 CBC 加密會另外建構其初始化向量 不正確。
  • 傳輸層安全標準 (TLS) 1.0 不再符合 PCI-DSS。

如要避免發生上述問題,您必須先支援 TLS 1.2。TLS 工作群組已淘汰 TLS 1.0 和 1.1。Chrome 現已淘汰 這些通訊協定

意圖移除 | Chromestatus Tracker | Chromium 錯誤

TLS 1.3 降級略過強化機制

TLS 1.3 提供具有回溯相容性的強化措施,以強化降級防護機制。 不過,我們去年推出 TLS 1.3 時,必須部分停用了這項功能 評估基礎為不相容於某些不符合 TLS 規定的情況 Proxy 執行要求。Chrome 目前採用憑證的強化措施 可鏈結至已知根,但允許繞過憑證鏈結 未知的根。我們打算為所有連線啟用這項功能。

降級的保護措施可降低各種舊版選項對安全性的影響 但還是保有相容性這表示使用者的連線更加安全 發現安全漏洞時 或回應他們(如此一來,使用者 road.)這也與 RFC 8446 一致。

意圖移除 | Chrome 平台狀態 | Chromium 錯誤

廢止政策

為維持平台的健康狀態,我們有時會將執行相關課程的 API 從網路平台中移除。我們可能會基於許多原因 API,例如:

  • 會由較新的 API 取代。
  • 這些更新庫會反映這些規格的變更,讓其他瀏覽器的一致性和一致性。
  • 這些初期實驗從未在其他瀏覽器上實現,因此可為網頁開發人員增加支援負擔。

上述變更中的部分變更會對極少數網站造成影響。為了提前解決問題,我們會提前向開發人員提供必要調整,確保網站持續運作。

Chrome 目前有 API 的淘汰及移除程序,基本上:

  • 告知 blink-dev 郵寄清單。
  • 在網頁上偵測到使用情況時,在 Chrome 開發人員工具控制台中設定警告並提供時間比例。
  • 等待、監控,然後隨著用量下降的功能移除。

如要查看 chromestatus.com 中所有已淘汰功能的清單,請使用 已淘汰的篩選器 ,然後套用已移除的篩選器來移除功能。我們也會盡量摘要說明這些文章中的部分異動、原因和遷移路徑。