\section{Motivation}

Une première méthode de cloisonnement qui n'a pas beaucoup été explorée est de
cloisonner l'application par module et non par objet de libvlccore.

Cette méthode permet d'arriver plus rapidement à une situation où l'ensemble
des modules de VLC est cloisonné, mais libvlccore ne profite pas du tout de ce
cloisonnement et il nous reste alors environ 100 000 lignes de code à auditer
pour s'approcher de loin de la méthode précédente. Il est intéressant de
mentionner cette technique du point de vue de l'architecture, étant donné
qu'elle montre une autre façon de procéder à l'injection de la sandbox dans les
modules et peut souligner de nouveaux défauts dans la conception du code.

Comme on l'a vu dans les premières parties, VLC fonctionne à travers libvlccore
en instanciant des modules, stockés dans des \inltype{vlc_object_t}. Chaque
module étant créé puis détruit par le core, tout en fournissant une API commune
au type de module, il peut être tentant de proposer de nouveaux modules avec un
type similaire à celui demandé mais qui jouerait le rôle de passerelle vers le
module réel dans un autre processus.

Avec cette technique, le sandboxing est plus facile à intégrer dans
l'application mais moins efficace.

\section{Implémentation}

La partie \og{}injection\fg{} consiste à complètement rediriger \inltype{module_need}
vers le cœur de la sandbox pour transformer les requêtes de module vers des
modules proxies. Le nom du module ou de la classe de module peut correspondre à
une politique et permet ainsi de décider très finement et automatiquement quel
module doit être redirigé vers un autre processus, nouveau ou déjà existant.
C'est à ce moment que les étages définis précédemment vont intervenir pour
permettre d'écrire le code de façon naturelle.

Néanmoins, cette technique n'a pas été implémenté à cause des défauts
d'isolation qu'elle possédait.