Chrome 有哪些 NPAPI 的代替方案？WebSocket 可以嗎？

01-22

NPAPI再見：Google將於明年1月起屏蔽大多數插件
顯然 NPAPI 是要被遺棄的，如一些網銀（如工行等）就不支持，但這對於其他互聯網公司確實非常重要的，如 QQ 就用它來實現非IE瀏覽器的通信介面（如快捷登陸），那可行的替代方案是什麼呢？其中最重要的環節是瀏覽器與「插件」間的數據通信，那 WebSocket 就能實現這個功能，但由於它現在還是個草案，能寄託於它嗎，求思路！
非常抱歉！描述不清，補充如下：

應用場景：
通過客戶端或插件與瀏覽器交互，通過本地處理邏輯控制（C）與視圖渲染（V），伺服器僅負責數據（M）推送及許可權控制，實現 MVC 分離。
目的：

通過數據本地緩存從而減輕資料庫的高頻次非涉密數據的讀取；

真正實現「千人千面」，根據本地數據挖掘實現個性追蹤（Cookies 功能有限）。

痛點：

通過插件實現（NPAPI）原是不錯的方案，但馬上快被歷史遺棄，不太靠譜。

通過 WebSocket 數據通信又涉及數據安全性問題，而且 IE 10.0 以下又不支持 WebSocket（如果用該方案，只能限定為 WebKit 和 moz 了）。

問題：
有比 WebSocket 更好的方案嗎？
（大牛們提到的 NACL 和 PPAPI 還沒深入研究過，待問……）
相關問題：
NPAPI 為什麼會被 Chrome 禁用？受影響的網站有什麼普遍性？

是在沒看懂樓主想問啥。NPAPI 跟 websocket 沒啥必然聯繫吧。

NPAPI 是瀏覽器的應用編程介面，它提供了一組 API 供瀏覽器調用其具體實現代碼。

其生命周期看可能與整個瀏覽器生命周期相同（這要看具體plugin實現了）。

NPAPI 可以與本地系統用戶許可權一致的權利調用任何系統資源。這就打穿了瀏覽器沙箱環境。因此身存在著一定的安全隱患。

如，NPAPI 的插件代碼肆意調用系統資源導致死機、代碼存在漏洞被系統內其他惡意程序利用等。

網銀之類的 NPAPI（如果真的有很多的話 = =|||）同理也是使用此類技術，在用戶本地使用本地應用（dll 或其他編譯好的程序）計算、加密、通過安全（網路）獲取用戶所需證書、密碼等關鍵信息。一旦存在漏洞，也很容易被本地的第三方應用程序利用。

Chrome 的 NACL 與之類似，但是將安全性加高。 NACL 根據 Technical Overview 描述，是運行在獨立沙箱內，並限制：

no support for hardware exceptions
no support for process creation / subprocesses
no support for raw TCP/UDP sockets (analogous versions—websockets for TCP and peer connect for UDP—are in the works and will be available soon)
no support for query to available memory

由此來提高 plugin 的整體安全度和穩定性。

至於 websocket …… 偶真不知道跟 NPAPI 的替代有啥關係，要有關係也是包含關係吧。如： NPAPI 的替代技術實現里不限制在沙箱環境內使用 websocket 技術訪問網路資源啥的。

看了看修改後的問題描述，好像回答的有點不對題了，我本意是回答NPAPI下去之後通用瀏覽器的插件技術應該往什麼方向走的- -

------------------------------------原回答------------------------------------

PPAPI(Pepper)是來自Mozilla的，本意是跨平台封裝需要用到的所有本地API，意圖作為NPAPI的後繼。但現在 Mozilla坑掉只有 Google在搞了。

Mozilla
扔掉Pepper的原因看起來也很簡單：它更希望HTML5標準化來解決一切。比如用WebGL來取代Pepper的OpenGL/ES封裝。PPAPI作為本地API的封裝（而不是NPAPI一樣僅僅提供介面），本身就需要一個「到底要封裝什麼」的規範，而這個規範的形成過程跟HTML5的標準化在某種意義上差不多是重合的。作為希望HTML5儘快、盡全面覆蓋的Mozilla（他們甚至為了阻擊NaCl製造了asm.js）選擇全力支持HTML5是很自然的事情。

至於前幾個答案多次提到的NaCl/PNaCl（區別是前者的可執行部分就是本地CPU代碼，而後者的可執行部分是LLVM IR），它跟PPAPI不能分開去看，這兩者目前是一而二二而一的關係，都是Google獨佔。至於為啥Google作為HTML5領軍廠商卻分神去做這個東東，我想應該是被前景誘惑了吧。LLVM IR是可以通過JIT在運行時轉本地代碼執行的，結合PPAPI作為封裝過的本地API，假設一切都能解決，那麼將既能做到「一次編譯，到處運行」，又可以在所有平台上都達到本地開發的性能，簡直就是Silver Bullet一樣的存在……不過實際上達到這個效果要求LLVM JIT效率進一步真正提高到本地代碼的速度（09年看評測很多特定測試在性能上已經可以達到甚至超過本地代碼，但也有不少更慢的），也要求對所有平台都封裝好需要的各種API，需要的開發力量相當龐大。這些年Google縱橫捭闔，借著準備HTML5標準化的名義里在各平台的Chrome瀏覽器里大肆封裝各種看起來用得上用不上的API（畢竟Pepper封裝後提供一個js介面是再簡單不過的了）我覺得從這個角度看上去就很容易理解了。

總結：HTML5+asm.js和Pepper+PNaCl，這就是該新聞中傳出要拋棄NPAPI的兩大巨頭各自給出的選擇。前者暫時擁有時間，後者也許擁有未來。至於哪個最終會勝出，還是讓歷史來說話吧。

按照我的理解（有誤請不吝指出），NPAPI是用native code寫browser的plugin，和ActiveX類似，而和用javascript/css寫的plugin相對。網銀什麼的一般用這個配合自己的本地操作系統驅動來實現安全密碼輸入（防key logger）之類的事情。

因此不是很明白提問中所說的「瀏覽器與"插件"間的數據通信」具體所指為何。猜測一下，莫非原意是問「瀏覽器和本地應用/驅動間的數據通信」？

如果只是為了性能或者重用舊代碼之類的原因必須使用native code寫plugin（遊戲什麼的），Chrome的解決方案是Portable Native Client（故意縮寫為NaCl，食鹽）: Technical Overview。PNaCl運行經過校驗的native code，因此可以做到兼顧安全性和性能。PNaCl提供一套受限制的API（例如OpenGL ES之類），不提供TCP/UDP，要通信也要使用websocket之類的機制。

PPAPI里不能直接調用本地借口只能通過自身的API間接調用，所以並不適合，比較實際的方式使用nativemessaging，這個比較合適

替代品是PPAPI，NPAPI在我看來最大的缺點是平台相關性太大，特別是圖形相關的部分，和瀏覽器所處的系統和使用的窗口管理器息息相關，跨平台基本上是扯淡。

來自chromium項目的PPAPI致力於解決這些問題，而且還提供了更加豐富的介面，如近似於OpenGL的3D介面，使大型網頁遊戲這種應用也能通過插件的方式獲得很好的效能。另外Mozilla的Gecho也已經支持PPAPI，天下大同指日可待。

有人提到NaCL，實際上也只是一個使用PPAPI介面的超級插件，手機輸入太費事，就不展開說了。另外websocket與這些介面並無直接聯繫。

我見過把你說的這個思路申請專利的。