儘管遭到 Mozilla Firefox 和 Apple Safari 的強烈反對，Google Chrome 仍在推進一個備受爭議的新 HTML <permission> 元素。該功能目前從 Chrome 122 開始進行原始試驗，旨在用內聯的宣告式 HTML 元素替代傳統的許可權彈窗，網站可以直接將其嵌入到頁面中。
這個新元素允許開發者透過 HTML 標記而不是 JavaScript 呼叫來請求瀏覽器許可權，如攝像頭、麥克風和位置訪問許可權。<permission> 元素不再使用打斷使用者瀏覽的熟悉模態對話方塊，而是作為網頁內容的一部分顯示，根據許可權是否被授予、拒絕或待定來顯示不同狀態。
支援的許可權型別（Chrome 122 試驗版）
- 攝像頭訪問許可權
- 麥克風訪問許可權
- 地理位置資料許可權
瀏覽器廠商立場
- Chrome：正在進行原始試驗實施
- Firefox：正式反對立場
- Safari/WebKit：正式反對立場
 |
|---|
| 在使用 Google Meet 時在瀏覽器中啟用麥克風訪問許可權的說明 |
標準流程爭議
開發者社群提出的最重要關切集中在 Google 決定在其他主要瀏覽器廠商正式反對的情況下繼續實施。Mozilla 和 WebKit 都發布了負面的標準立場，但 Chrome 仍透過原始試驗繼續開發。這種做法因可能分裂網路標準並建立其他瀏覽器可能永遠不會支援的 Chrome 專有功能而受到批評。
這種情況凸顯了網路標準治理中持續存在的緊張關係。批評者認為，Chrome 的主導市場份額使 Google 能夠有效地強制採用功能，無論行業共識如何，這破壞了傳統上管理網路開發的協作標準流程。
安全和使用者體驗擔憂
開發者討論顯示出對將許可權請求移入網頁內容的安全影響的深度懷疑。元素的內聯性質引發了對點選劫持攻擊的擔憂，惡意網站可能會覆蓋不可見元素來欺騙使用者無意中授予許可權。
對元素施加的樣式限制創造了額外的挑戰。雖然 Google 限制了網站自定義外觀的方式以防止濫用，但開發者擔心這會創造出令人不快的使用者體驗，許可權按鈕與網站設計不匹配。這些限制似乎也不足以防止複雜的社會工程攻擊。
「它讓使用者更容易啟用許可權，也更容易意外啟用，從而降低安全性和隱私性。Google 產品的設計就是為了利用這一點。」
技術實現問題
社群已經識別出當前提案的幾個技術問題。元素的行為似乎與標準 HTML 模式不一致，其宣告性質也受到質疑，因為底層許可權仍然需要 JavaScript 才能有意義地執行。
開發者還注意到與現有許可權 API 相比缺少功能。試驗版本缺乏永久阻止許可權的選項，只提供每次訪問時允許和本次允許的選擇。這種不對稱性表明該功能可能是為了鼓勵許可權授予而不是真正改善使用者控制而設計的。
許可權元素語法示例
<permission name="camera">
<span>許可權已授予。</span>
<span slot="denied">許可權被拒絕。</span>
<button slot="prompt">請求許可權</button>
</permission>
關鍵屬性
name：許可權型別（攝像頭、麥克風、地理位置）granted：許可權被授予時顯示的內容denied：許可權被拒絕時顯示的內容prompt：許可權狀態未知時顯示的內容
市場影響和未來展望
這一爭議反映了對 Google 透過 Chrome 的市場主導地位對網路標準影響力的更廣泛擔憂。許多開發者擔心成功部署 Chrome 專有功能將迫使其他瀏覽器事後實現它們，無論技術價值或安全擔憂如何。
這種情況反映了之前 Google 單方面引入功能，後來強制行業採用的例項。隨著網路開發者越來越依賴 Chrome 專有 API，許可權元素可能成為透過市場力量而非基於共識的開發進行事實標準化的另一個例子。
這個功能的最終成功可能取決於其他瀏覽器廠商是否最終改變立場，或者網路開發社群是否會在分裂擔憂的情況下接受 Chrome 專有實現。