嵌入式服務應否在你的網站取得相機或位置權限？

先由顧客要完成的事開始

分店搜尋器可能要求位置，以推薦附近分店；嵌入式身份核實服務可能要求相機，以拍攝文件。兩者都是面向顧客的任務，但不代表網站每頁或所有第三方框架都應得到這些能力。先列出確切頁面、嵌入服務的來源網域、所需瀏覽器功能，以及觸發功能的顧客動作。然後決定若顧客拒絕或瀏覽器不支援，仍可怎樣完成工作。地圖可提供手動地區搜尋；文件流程可能需要另設上載或人手協助途徑。權限是產品決定，也有技術邊界，不應為方便而一概開啟。

瀏覽器權限提示與 Permissions Policy 處理不同問題。提示是詢問用戶是否容許某來源使用敏感功能；Permissions Policy 則透過 HTTP 回應標頭，有時配合 iframe 的 allow 屬性，限制哪些文件甚至可以提出要求。MDN 說明，政策若封鎖地理位置，呼叫會被拒；父頁標頭沒有包括的嵌入來源，也不能單靠 iframe 的 allow 屬性補回。相機方面，跨來源嵌入文件須先獲頂層頁面明確容許，才有機會向用戶請求。通過政策關卡仍不等於自動取得相機；用戶許可仍然必要。

按實際來源網域畫出界線

來源網域由協定、主機及連接埠組成，因此同一品牌的說明頁與嵌入應用，也可能屬於不同來源。向供應商確認真正提供功能的來源，以及 iframe 在流程中會否跳到另一來源。記下哪些頁面嵌入它，開發、測試和正式環境的地址是否不同。這份清單很重要：過寬的萬用規則可能讓不必要的網站取得能力，填錯來源則會令功能失效。不要只根據可見標誌或起始網址猜測，應在受控測試中核對實際網絡請求及框架導航。

例如零售商的分店頁設於自家來源，地圖則嵌入另一供應商來源。若地圖只根據用戶輸入的地區顯示標記，它可能完全不需要地理位置。如果地圖內提供「使用我的位置」按鈕，跨來源位置功能便需要頁面政策及 iframe 政策都容許該供應商，並仍受瀏覽器支援情況和用戶選擇限制。MDN 的地理位置指令文件展示指定來源標頭配合 iframe allow 的模式。另要記錄父頁本身有否使用同一功能；為嵌入服務改動全站標頭，可能同時影響自家頁面。

規則收窄，選擇說清楚

某功能若在頁面及其框架都完全不應使用，可設空允許清單；只有經測試的需要，才列出特定來源。頁面標頭與框架屬性共同作用，實際許可受兩者限制。不要把文件範例原封不動複製到所有回應，而不檢查它會改變哪些業務旅程。位置地圖、影片播放器及文件拍攝供應商使用不同能力，應分別決定。MDN 亦把部分 Permissions Policy 指令標為瀏覽器支援有限，故上線計劃要涵蓋顧客實際使用的瀏覽器，並準備在指令不支援或表現不同時仍可完成任務的途徑。

介面應在有意義的時刻才要求敏感功能。瀏覽器跳出提示前，先說明顧客將進行甚麼，並提供手動替代方法。顧客拒絕後，頁面其餘部分仍應可用，並以一般語言交代情況。也不要把每次拒絕都稱作顧客主動拒絕：可能是框架缺乏政策許可、裝置沒有相機，或頁面並非安全環境。MDN 指出 getUserMedia 需要安全環境，而且相機使用仍需用戶許可。分辨這些原因，客服才能提供合適下一步，而不是一再要求顧客更改瀏覽器設定。

以分店搜尋及拍攝流程驗證

以已知供應商嵌入的分店搜尋器為例。先載入頁面而不按「使用我的位置」；畫面應提供手動搜尋，亦不應因此需要位置提示。再於支援的瀏覽器按下控制項，檢查框架來源是否與政策記錄一致。允許後確認能顯示以位置為基礎的結果，但不要聲稱定位一定準確。拒絕後確認手動地區搜尋仍可用。再在測試環境移除 iframe allow，或在父頁標頭排除測試來源；位置要求應按預期失敗，而分店頁其他內容仍然可用。

文件拍攝嵌入服務要另作測試。核實頁面使用 HTTPS、預期框架來源獲准使用相機，以及瀏覽器在啟動裝置前會徵求顧客同意。確認顧客能停止拍攝、重拍模糊影像，並明白相片其後如何處理；這些是政策規則以外的服務要求。還應在沒有相機的手提電腦，以及指令表現不同或不支援的瀏覽器測試，提供可行替代途徑，避免顧客困在重複提示之中。政策測試成功，並不證明拍攝流程在無障礙、安全或敏感文件處理方面都合格，這些須另行審核。

供應商變動時同步更新權限

可為每項嵌入功能保存簡短紀錄：負責人、所在頁面、準確來源、所需瀏覽器能力、原因、替代途徑及最近測試的瀏覽器。供應商更換嵌入網域或新增框架時，擴大允許清單前先重看政策。測試環境的封鎖訊息是有用線索，但緊急加入全面萬用規則不應成為長期做法。應確認新來源、核對業務需要、只更新受影響頁面，並重試允許與拒絕兩種旅程。已移除的嵌入服務也要覆核，避免舊權限無限期留在共用標頭。

業主的上線決定應建基於可觀察行為：在顧客同意後，獲批准來源可以使用所需功能；在有執行政策的瀏覽器中，未批准框架不能提出該要求；拒絕或不支援時，顧客仍有可用路線。這並非聲稱所有瀏覽器都以完全相同方式執行每條指令，而是為中小企建立可維護邊界及誠實的顧客體驗。香港雙語頁面應分別檢查英文及繁體中文的解釋、按鈕名稱與替代途徑。即使政策技術上正確，若顧客不明白網站為何要求敏感能力，服務仍然不理想。

修改權限前先找出阻擋層

功能失敗時，應分別查看頂層回應標頭、iframe allow 屬性、框架實際來源、頁面是否安全環境，以及瀏覽器自身的權限決定。它們是不同阻擋層。若框架沒有政策許可，瀏覽器可能根本不顯示提示；叫顧客在設定裏允許，也修不好頁面配置。若政策容許提出要求而顧客拒絕，改動標頭同樣無關。客服紀錄可包括已測試的瀏覽器及版本、頁面網址、框架來源、執行動作和觀察結果，避免不必要地收集顧客精確位置或拍攝文件。

先在一個具代表性的頁面測試變更，不要假設邊緣伺服器新增的標頭必然出現在所有頁面。檢查經轉址和快取層後的最終 HTTP 回應，再於瀏覽器查看嵌入文件。供應商可能在驗證或拍攝途中把框架轉往另一來源；只符合起始地址的規則會在半途失效。MDN 的政策文件解釋父頁及框架限制如何共同作用，因此應按觀察到的最終來源，判斷是否有理由狹窄地加進允許清單。若新來源同時提供無關內容，應考慮另設整合途徑，而非盲目擴大權限。

簽收前，應記下三種狀態的顧客結果：功能獲准、顧客拒絕、技術原因令功能不可用。獲准時須能完成原本任務；拒絕時須有可理解的替代方法；技術失敗時須讓客服有足夠資料排查，而不是責怪顧客。每次嵌入服務改動都重看三種狀態，可避免供應商悄悄增加新能力後，商戶便把所有權限一併開放的營運偏移。即使程式由另一家公司提供，商戶仍須對嵌入旅程向顧客提出的要求負責。