陳文義
Google 剛釋出了一款名為 Native Client（簡稱 NaCl）的試驗性開發工具，可用來在以瀏覽器為基礎的應用中執行 x86 原生程式碼。這項開放原始碼研究計畫代表了可完整利用本地電腦運算能力的外掛程式 (plug-in) 的隔離測試環境 (sandbox)，一如微軟的 Active X，但具有更強的安全性。
NaCl 企圖藉由使用一個內部的隔離測試環境來限縮原生程式碼模組與主系統間的互動，使其能納入未受信任的 x86 程式碼。它使用了靜態分析來偵測安全問題，再利用結構規則將之放大，以確保程式碼能夠被可靠地拆解，並將不安全的部份辨識出來。
該計畫簡稱 NaCl 正是氯化鈉的化學式，或可被視為微軟傷口上的鹽巴。倘若 Google 的 Native Client 成為一套更完整穩固的系統，則桌面應用軟體與網頁應用間的效能差異，可能會煙消雲散。
對於仍持續仰賴桌面軟體營收的業者，例如微軟、 Adobe，這項新技術恐怕會進一步侵蝕他們昂貴軟體產品的商業價值。這種可能性其實符合各方的長遠預期，不過微軟與 Adobe 雖然也都企圖將應用軟體往網路上搬移，卻是採取和瀏覽器保持距離的策略。
NaCl 包含了一個執行環境 (runtime) 、一個瀏覽器外掛，以及一組以 GNU Compiler Collection 為基礎的程式編譯工具。
Google 工程師 Brad Chen 描繪了 Native Client 如何能使一個透過瀏覽器使用、類似 Photoshop 的影像編輯軟體更易於使用的情境。
「目前我們可以透過 JavaScript 與伺服器端運算的整合，來提供線上影像編輯的功能，」他在部落格中解釋道。「不過這種方法必須在瀏覽器與伺服器間有大量影像資料的傳輸，導致只想要做點簡單改變的使用者必須因而經歷痛苦的慢速。透過能夠在使用者端機器上直接執行原生程式碼，你便能將實際的影像運算處理留在桌面電腦的 CPU 上執行，讓應用程式能更快速回應，並將資料傳輸與延遲的狀況減到最低。」
受到爭議的是，早已存在的 Java applet 其實也能夠滿足相同的目的，不過卻需要花費時間下載與啟動。不過對 Google 來說，連千分之一秒都被視為是會影響使用者經驗的負面因素，因此未將 Java applet 列入考慮。
在 Google Groups 討論區的一段貼文中，Chen 詳細解釋了為何 Google 並未選擇 Java 或其他的虛擬機器。「我認為這些東西都很棒，喜歡他們的使用者也應該繼續使用，並幫助他們成功，」他說道。「此時此刻，Native Client 研發動機之一，則是要讓人們擁有更多選擇。 Native Client 只是為了那些想要使用其他程式語言、不想只因為採用特定虛擬機器，就被單一程式語言或開發環境綁住的人們所創造出來的。」
不過在 Google 能夠達成他的承諾之前，還有很長的路要走。依照 Google 的典型作法，此項研究計畫釋出的部份，不過是相當早期的成果。拿 Google 在強化瀏覽器並使之更能與桌面應用方面的努力，即仍處於緩慢導入期的 Google Gears 來看，Native Client 要能與約略相當的技術，如 Adobe 的 AIR 與微軟的 Silverlight 相提並論，可能仍要好幾年的時間。