Discussion :

[teddyalbina]

Tout les concepts utilisés dans les navigateurs modernes (sandbox, séparation multiprocess, etc) sont possible en .NET. Mais il manque quelque chose de taille : un moteur de rendu.

Là, il n'y a en gros que IE et Gecko que l'on peut utiliser, et ce sont des moteurs en C/C++ ...

Et alors il est possible de sécurisé tout ça avec créant un pont avec le moteur de rendu avec C++/CLi du tout les problèmes resteraient au niveau de moteur sans pourvoir remonter par opération du saint esprit.

De tout façon la bibliothèque C est une passoire donc vive dotnet .


Bon soyons fou ça tente quelqu'un un projet DOTNET au dessus de Webkit ?

[Médinoc]

Quelles sont exactement les extensions "officielles" à Firefox? Car mêmes celles disponibles sur le catalogue intégré et passant par addons.mozilla.org sont marqués "auteur non vérifié" sur la boîte de dialogue d'installation...

[Uther]

Pour le moment, il n'y a aucune extension réellement officielle.

Même les extensions issues du Mozilla Labs (Weave, Prism, ...) et donc activement soutenues et/ou développées par Mozilla, ne sont pas considérées comme des extensions officielles. Cependant on peut reconnaitre une certaine légitimité aux extensions disponibles sur le site officiel des add-ons Mozilla.

[thelvin]

Bah coder un nav en dotnet, avec chaque plugin isolé de l'hote dans un appdomain et zappé C++

L'isolation permettrait de détecter plus facilement qu'un addon fait quelque chose qu'il n'est pas censé avoir besoin de faire, ce qui, en soi, suffirait à éveiller des soupçons chez les connaisseurs, et simplifierait la détection de malwares par la communauté.

Mais, isolé de tout, accès à rien, ça veut dire utile à rien. Donc un isolement complet n'est pas souhaitable, et ce n'est pas une solution magique, juste un cran de sécurité de plus.

A-t-on vraiment envie d'investir autant pour un simple cran de sécurité de plus, sans chercher avant s'il n'y a pas une solution moins envahissante ?

[smyley]

Toi tu connais pas les AppDomains

L'idée des domaines d'applications en .NET c'est contrôler les autorisations précises du code exécuté au sein de ce domaine, mais de pouvoir quand même communiquer avec les autres domaines via des moyens que l'on doit (si c'est bien conçu) exposer de façon explicite.

Donc le plugin, on le maîtrise tout en lui laissant accès à ce que l'on veux bien au cas par cas.

[thelvin]

Toi tu connais pas les AppDomains

En effet, mais pas besoin. Une sécurité par confinement est une sécurité par confinement. Ce n'est qu'un bac à sable évolué. Elles ont toutes grosso-modo les mêmes avantages et les mêmes inconvénients théoriques.

Ce que tu m'expliques est très beau... Mais je ne vois pas en quoi je ne l'ai pas abordé dans ce que j'ai dit.

[smyley]

Ce que tu m'expliques est très beau... Mais je ne vois pas en quoi je ne l'ai pas abordé dans ce que j'ai dit.

Mais, isolé de tout, accès à rien, ça veut dire utile à rien.
[...]

A-t-on vraiment envie d'investir autant pour un simple cran de sécurité de plus, sans chercher avant s'il n'y a pas une solution moins envahissante ?

Bon alors, si on est d'accord sur le fait qu'un bac à sable ne signifie pas "isolé de tout, accès à rien, ça veut dire utile à rien", en quoi est-ce envahissant ?

Si un plugin est censé n'accéder qu'à l'interface, en quoi est-ce envahissant de le laisser accéder uniquement à l'interface ? Pour les plugins normaux c'est bon, pour les malwares sur ce côté là on est au pied du mur : même si un système sans faille n'existe pas, sur le coup le bac à sable est une solution extrêmement efficace.

Et tout le monde "semble" converger vers l'isolation des processus / tâches / etc., il ne s'agit pas d'un simple "cran de sécurité en plus", mais bien d'une autre approche de l'exécution des programmes qui tend à se généraliser.

[thelvin]

Bon alors, si on est d'accord sur le fait qu'un bac à sable ne signifie pas "isolé de tout, accès à rien, ça veut dire utile à rien", en quoi est-ce envahissant ?

Ben déjà c'est plus envahissant que de ne pas en avoir, forcément .

Mais je ne parlais pas d'avoir un bac à sable en général, je parlais du fait de partir direct vers la solution C#. J'appelle ça envahissant parce qu'à moins que je me trompe, Mozilla n'avait pas de dépendance centrale à .net.

Si un plugin est censé n'accéder qu'à l'interface, en quoi est-ce envahissant de le laisser accéder uniquement à l'interface ?

Oui non mais c'est pas ça que j'ai dit.

Mais servons-nous de cet exemple pour illustrer : des addons qui n'ont accès qu'à l'interface, bon il y en a c'est vrai... Mais il y en a combien, et est-ce que c'est vraiment une partie significative à étudier ?
Les addons utiles ont tendance à communiquer au moins ce qu'ils récupèrent sur le client, à Internet. C'est suffisant pour voler des cartes bleues.

Et tout le monde "semble" converger vers l'isolation des processus / tâches / etc., il ne s'agit pas d'un simple "cran de sécurité en plus", mais bien d'une autre approche de l'exécution des programmes qui tend à se généraliser.

Pas une raison pour partir sur C# sans réfléchir si une solution ad hoc n'est pas plus adaptée, mais sinon oui, je suis d'accord.

[smyley]

je parlais du fait de partir direct vers la solution C#. J'appelle ça envahissant parce qu'à moins que je me trompe, Mozilla n'avait pas de dépendance centrale à .net.

Au départ, c'était une réponse à ce message

Bah coder un nav en dotnet, avec chaque plugin isolé de l'hote dans un appdomain et zappé C++

Mozilla n'a aucun intérêt à développer en .NET vu qu'il vise des environnements beaucoup plus vaste avec une solution qui remonte jusqu'à Netscape (bien avant .NET).

Mais toutes les techniques d'isolation peuvent être utilisées en .NET, d'ailleurs il serait marrant de voir un browser en .NET utilisant Mono pour les autres plateformes (bah quoi ? apparemment c'est la mode ces temps ci de créer des nouveaux navigateurs & os )

Mais servons-nous de cet exemple pour illustrer : des addons qui n'ont accès qu'à l'interface, bon il y en a c'est vrai... Mais il y en a combien, et est-ce que c'est vraiment une partie significative à étudier ?
Les addons utiles ont tendance à communiquer au moins ce qu'ils récupèrent sur le client, à Internet. C'est suffisant pour voler des cartes bleues.

Et ? c'était un exemple.

On peut isoler les addons entre eux, leur permettre d'accéder à certaines parties de l'application mais pas à d'autre, ou de communiquer entre eux, etc.

Après, pour les addins nécessitant d'avantage d'autorisations, demande à l'utilisateur s'il lui fait confiance, etc.

Ce système est utilisé sur les OS maintenant (UAC, sudo je sais plus quoi, etc.) mais arrive aux navigateurs.

[thelvin]

Pas d'objection, votre honneur.

Je remettais juste en cause l'idée de se concentrer sur C# pour ça au lieu d'une solution maison ou indépendante, juste parce que C# fournit un système d'isolement sûrement très efficace, pratique et probablement vite fait.