Le concept général de NaCl (exécution de code natif dans le navigateur web) a déjà été implémenté dans ActiveX , mais NaCl exécute le contenu dans un environnement isolé (sandbox), tandis qu'une application ActiveX a un accès complet au système (disque, mémoire, interface utilisateur, registre, etc.). Mozilla a proposé asm.js comme alternative à ActiveX et à NaCl. asm.js permet également de compiler des applications écrites en C ou C++ pour les exécuter dans le navigateur et prend en charge la compilation AOT (Ahead-Of-Time). Cependant, étant un sous-ensemble de JavaScript, il est rétrocompatible avec les navigateurs qui ne le prennent pas directement en charge.
En 2016, Google a réduit la priorité accordée au développement de Pepper et de Native Client. Le 30 mai 2017, Google a annoncé l'abandon de PNaCl au profit de WebAssembly . Au cours des années suivantes, Google Chrome a progressivement abandonné et supprimé NaCl sur différentes plateformes. ChromeOS version 137, sortie en 2025, est devenue la dernière plateforme et la dernière version à prendre en charge Native Client.
open source développé par Google . Des jeux tels que Quake , XaoS , Battle for Wesnoth , Doom , Lara Croft and the Guardian of Light , From Dust , et MAME , ainsi que le système de traitement sonore Csound , ont été portés sur Native Client. Native Client est disponible dans le navigateur web Google Chrome depuis la version 14 et est activé par défaut depuis la version 31, date de sortie de Portable Native Client (PNaCl, prononcé : pinnacle). Native Client a également été utilisé pour exécuter en toute sécurité du code téléchargé dans des logiciels autres que les navigateurs web, comme dans le moteur de jeu Dæmon.Une implémentation ARM a été publiée en mars 2010. x86-64 , IA-32 et MIPS étaient également pris en charge.
Pour exécuter une application de manière portable sous PNaCl, elle doit être compilée en un sous-ensemble stable et indépendant de l'architecture du bytecode de représentation intermédiaire LLVM . Les exécutables sont appelés exécutables PNaCl (.pexe). La chaîne d'outils PNaCl génère des fichiers .pexe ; la chaîne d'outils NaCl, des fichiers .nexe. Le nombre magique des fichiers .nexe est 0x7F 'E' 'L' 'F', soit ELF . Sous Chrome, ils sont traduits en exécutables spécifiques à l'architecture pour pouvoir être exécutés.
NaCl utilise la détection et l'isolation des défauts logiciels pour le sandboxing sur les architectures x86-64 et ARM. L'implémentation x86-32 de Native Client se distingue par sa méthode de sandboxing novatrice, qui exploite la fonctionnalité de segmentation rarement utilisée de l'architecture x86 . Native Client configure des segments x86 pour limiter la plage mémoire accessible au code sandboxé. Il utilise un vérificateur de code pour empêcher l'exécution d'instructions non sécurisées, telles que les appels système. Afin d'empêcher l'exécution d'une instruction non sécurisée masquée au sein d'une instruction sécurisée, Native Client exige que tous les sauts indirects soient effectués au début de blocs alignés sur 32 octets, et les instructions ne sont pas autorisées à chevaucher ces blocs. En raison de ces contraintes, le code C et C++ doit être recompilé pour s'exécuter sous Native Client, qui fournit des versions personnalisées de la chaîne d'outils GNU , notamment GNU Compiler Collection (GCC), GNU Binutils et LLVM .
Native Client est distribué sous une licence de type BSD .
Native Client utilise Newlib comme bibliothèque C , mais un portage de la bibliothèque GNU C (GNU libc) est également disponible.
Histoire
Le 8 décembre 2008, Google a présenté Native Client au public peu après le lancement de Google Chrome en septembre. NaCl est devenu accessible au grand public lors de sa sortie dans une version stable de Chrome en septembre 2011.
Le 9 décembre 2011, Google a démontré la maturité de sa technologie en annonçant la disponibilité de plusieurs nouvelles versions exclusives à Chrome de jeux réputés pour leurs graphismes riches et gourmands en ressources processeur , dont Bastion (désormais indisponible sur le Chrome Web Store ). NaCl prend en charge l'accélération matérielle 3D (via OpenGL ES 2.0), le stockage local de fichiers isolé, le chargement dynamique , le mode plein écran et la capture de la souris . Il était également prévu de rendre NaCl disponible sur appareils mobiles.
En 2013, Google a introduit Portable Native Client (PNaCl), une version de NaCl compilée à l'avance et indépendante de l'architecture. PNaCl est une version indépendante de l'architecture. Les applications PNaCl sont compilées à l'avance . PNaCl est recommandé de préférence à NaCl pour la plupart des cas d'utilisation. Le concept général de NaCl (exécution de code natif dans un navigateur web) a déjà été implémenté dans ActiveX , qui, bien qu'encore utilisé, dispose d'un accès complet au système (disque, mémoire, interface utilisateur, registre, etc.). Native Client évite ce problème grâce au sandboxing.
Une alternative proposée par Mozilla était asm.js , qui permet également de compiler des applications écrites en C ou C++ pour qu'elles s'exécutent dans le navigateur et prend également en charge la compilation anticipée, mais qui est un sous-ensemble de JavaScript et est donc rétrocompatible avec les navigateurs qui ne le prennent pas directement en charge.
Le 12 octobre 2016, un commentaire sur le système de suivi des problèmes de Chromium indiquait que les équipes Pepper et Native Client de Google avaient été réduites en effectifs. Le 30 mai 2017, Google annonçait l'abandon de PNaCl au profit de WebAssembly . Bien qu'initialement Google ait prévu de supprimer PNaCl au premier trimestre 2018, puis au deuxième trimestre 2019, il a finalement été supprimé en juin 2022 (en même temps que Chrome Apps ).
LLVM 22, sorti en février 2026, est devenu la première version à perdre la prise en charge de la construction de binaires NaCl.
Poivre
PPAPI
Le 12 août 2009, une page de Google Code présentait un nouveau projet, Pepper, et l'API Pepper Plugin (PPAPI) associée , « un ensemble de modifications apportées à NPAPI pour rendre les plugins plus portables et plus sûrs » . Cette extension est spécifiquement conçue pour faciliter l'exécution de plugins hors processus . De plus, le projet vise à fournir un cadre permettant de rendre les plugins entièrement multiplateformes. Les sujets abordés incluent :
- Sémantique uniforme pour NPAPI sur tous les navigateurs.
- Exécution dans un processus distinct du moteur de rendu et du navigateur.
- Standardiser le rendu en utilisant le processus de composition du navigateur.
- Définition d'événements standardisés et de fonctions de rastérisation 2D.
- Première tentative pour fournir un accès aux graphismes 3D.
- Registre des plugins.
L'API Pepper prend également en charge les manettes de jeu (version 19) et les WebSockets (version 18).
Chromium , était le seul navigateur web à utiliser le nouveau modèle de plug-in. En 2020, Pepper était pris en charge par Chrome, Chromium et les navigateurs basés sur le moteur de rendu Blink, tels qu'Opera et Microsoft Edge.
En août 2020, Google a annoncé que la prise en charge de PPAPI serait supprimée de Google Chrome et Chromium en juin 2022.
PPAPI dans Firefox
En 2014, les développeurs de Firefox ont déclaré qu'ils ne prendraient pas en charge Pepper, car l'API n'était pas entièrement documentée, hormis son implémentation dans Chrome. Ce dernier, conçu exclusivement pour le moteur de rendu Blink , disposait d'API privées spécifiques au plugin Flash Player, non documentées. En octobre 2016, Mozilla a annoncé reconsidérer sa position et étudier la possibilité d'intégrer l'API Pepper et PDFium dans les futures versions de Firefox, mais aucune mesure concrète n'a été prise. En juillet 2017, Adobe a abandonné Flash et annoncé sa fin de vie pour fin 2020. En janvier 2021, Adobe Flash Player, Google Chrome, Firefox, Safari et Windows ont reçu des mises à jour désactivant ou supprimant complètement Flash.
Applications
Un site web a utilisé du NaCl sur le serveur pour permettre aux utilisateurs d'expérimenter le langage de programmation Go depuis leur navigateur.
Utilisation en dehors des navigateurs Web
Le jeu open-source Unvanquished utilise Native Client dans le moteur de jeu Dæmon en remplacement de la Q3VM ( machine virtuelle Quake III ) . Dans ce moteur, l'environnement isolé de Native Client permet d'exécuter en toute sécurité du code de jeu arbitraire ( mods ) téléchargé depuis les serveurs de jeu. L'utilisation de Native Client permet aux développeurs d'utiliser le langage C++ pour les jeux exécutés dans la machine virtuelle, d'utiliser des bibliothèques C++, de partager du code entre le jeu et le moteur et d'obtenir de meilleures performances qu'avec la Q3VM
Réception
Certains groupes de développeurs de navigateurs soutenaient la technologie Native Client, tandis que d'autres ne la soutenaient pas.
Les supporters
Chad Austin (d' IMVU ) a salué la façon dont Native Client peut apporter des applications hautes performances au Web (avec une pénalité d'environ 5 % par rapport au code natif) de manière sécurisée, tout en accélérant l'évolution des applications côté client en offrant un choix du langage de programmation utilisé (outre JavaScript ).
John D. Carmack d' id Software a fait l'éloge de Native Client lors de la QuakeCon 2012, déclarant : « Si vous devez effectuer des opérations dans un navigateur, Native Client est bien plus intéressant. À l'origine, il s'agissait d'une astuce x86 particulièrement ingénieuse permettant d'isoler le tout en mode utilisateur. Désormais, grâce à la recompilation dynamique, le programme en C ou C++ est compilé en un code dont le niveau d'optimisation (-O4) n'est pas celui du code natif pur, mais qui s'en approche fortement. Vous pouvez ainsi réaliser toutes vos manipulations de pointeurs complexes et tout ce que vous souhaitez faire en tant que développeur de jeux « au plus près du matériel ». »
Détracteurs
D'autres professionnels de l'informatique se sont montrés plus critiques à l'égard de cette technologie de sandboxing, car elle présentait des problèmes d'interopérabilité importants.
Le vice-président des produits de Mozilla , Christopher Blizzard de Mozilla a critiqué NaCl, affirmant que le code natif ne peut pas évoluer de la même manière que le Web, qui repose sur le code source. Il a également comparé NaCl à la technologie ActiveX de Microsoft , en proie au problème des DLL complexes .
Håkon Wium Lie , directeur technique d'Opera, estimait que « NaCl semble regretter le bon vieux temps, avant le web », et que « Native Client consiste à construire une nouvelle plateforme – ou à porter une ancienne plateforme sur le web [...] cela engendrera de la complexité et des problèmes de sécurité, et détournera l'attention de la plateforme web. »
Deuxième génération
La deuxième génération de sandboxing développée par Google est gVisor . Elle est destinée à remplacer NaCl dans Google Cloud , plus précisément dans Google App Engine . Google promeut également WebAssembly .