微軟旗下的 IE 瀏覽器已逐步被使用者淘汰，屆時在 IE 上所使用的 ActiveX 套件，將無法在其他新式瀏覽器上使用，如：Chrome、Firefox、Opera 或 EDGE，基於安全性考量，不再支援 ActiveX 等相關 NPAPI（ Netscape Plugin Application Programming Interface；網景外掛模組應用程式介面）元件的呼叫。但如自然人憑證與金融憑證的相關 PKI（Public Key Infrastructure）資安應用，仍然有存在的必要性，uPKI（ubiquitous Public Key Infrastructure）將是 PKI 資安控管暢行各大瀏覽器的關鍵！
瀏覽器技術：從 NPAPI 過渡到 PPAPI
1995 年由網景公司提出了 NPAPI 標準，制訂了一連串瀏覽器的模組介面。NPAPI 的用意為可直接存取系統端 API （Application Programming Interface）的介面，來達到由網頁端來控制 Client（用戶端）如讀卡機的聯繫。然而在 Chrome 瀏覽器推出後，Google 重新制訂了一套名為 Pepper Plugin Application Programming Interface（簡稱 PPAPI）標準，將所有的系統呼叫都放進沙箱內執行以增進安全性，時至今日幾乎所有的新式瀏覽器皆支援 PPAPI 標準，然而，PPAPI 並不含讀卡機的相關介面制訂，Google 則是制訂了另一套名為 Native Messaging 的 plug-in（插件）技術來處理。
瀏覽器 Plug-in 方案 成為廠商維護資安夢魘
在各大新式瀏覽器的設計中，因安全考量在讀取 Client 端讀卡機設備技術上，各自制訂了 Native Messaging 技術，透過 JavaScript、HTML5 與 JSON，來驅動安裝在自身瀏覽器上的 Plug-in，藉此取得與 Client 端的硬體聯繫。
Native Messaging 技術在 Chrome、Firefox 或 EDGE 都有各自的實做，但對開發廠商而言卻是個無止盡的維護夢魘，因為 Plug-in 並沒有統一的規範，也就代表每一套瀏覽器，都需要使用者另外安裝一套相對應的 Plug-in，才能實現在不同瀏覽器上都能使用安控元件的目的。
uPKI 讓資安控管在不同瀏覽器暢行無阻
為了實現跨瀏覽器的元件應用，我們嵌入了一塊輕量級獨立服務框架，用來與本機端硬體進行聯繫。只要在使用者端的系統平台上建立服務，並使用一個埠號來監聽請求，如此網頁端只要透過 HTTP（HyperText Transfer Protocol；超文本傳輸協定）呼叫，如 POST、GET、PUT、DELETE 等方法，就可與撰寫在獨立服務上的函式進行互動，可稱之為 Local Service 技術。透過 Local Service，可由本機端任何具備傳輸 HTTP 呼叫的載體來呼叫獨立服務，同理也可應用在所有瀏覽器上，如此一來，資安控管便能在不同瀏覽器暢行無阻。
