Tout d'abord, merci pour ta réponse intéressante et argumentée.
De rien et merci a toi de partager ton point de vue. Participant au projet Enlightenment, c'est une discussion on ne peut plus interressante pour moi.
Je connais et j'admire MagicInk, mais je ne pense pas que ces applications soient aussi répondérantes aujourd'hui que tu le dis. Dans les logiciels que j'utilise tous les jours aucune ne fait vraiment ça, à part le logiciel distant hébergé par Google (spécialisation des résultats de recherche, qui d'ailleurs me gonfle pas mal, et publicité personnalisée). Je ne crois pas qu'on puisse dire aujourd'hui que ça constitue la "grandes majorité des applications", en tout cas sur des distributions GNU/Linux classiques.
Tu mets exactement le doigt sur une lacune du monde GNU/Linux. Le cloud (via Google, Facebook, voir meme github) et Android qui vient globalement du meme monde, offre une plus grande integration et plus de possibilite d'etendre les fonctions d'une application que ne le permette des applications locales. Pourtant mon PC a acces a tous les cloud en meme temps et a plus de donnees personnelles stocke localement que n'importe lequel de ces services en ligne. Donc pourquoi les developpeurs ne font il pas plus pour integrer tout ca et faciliter la vie de l'utilisateur ? En fait, le projet KDE a pas mal d'avance dans le domaine (principalement parce qu'il redeveloppe toutes leurs applications), mais on est encore loin de ce qu'on peut juste imaginer aujourd'hui.
J'ai donc très peu d'expérience sur la conception et la structure de ces "applications contextuelles" et je peux difficilement en dire plus sur comment les intégrer à ces modèles de sécurité. Je suis cependant confiant du fait qu'on pourra le faire quand elles se développeront (l'idée est d'isoler le composant qui construit le contexte pour le faire tourner dans un processus à part ayant des droits spécialiser, et de travailler sur son interface avec les autres composants pour qu'elle ne transmette pas trop d'information).
Idee interressante. En gros, on obtient un modele ou on a un grabber qui aura des droits particuliers et sera en mesure d'extraire l'information pour la presenter aux applications. Ca complexifie clairement le code et augmente la consomation de ressource, mais faut voir si cela a un impact important au final. C'est une idee a creuser, voir plus bas.
Quand je regarde les applications que j'utilise aujourd'hui (un navigateur web, un éditeur de textes/programmes, des programmes pour lire des images/musiques/vidéos, un client mail, un lecteur PDF, quelques jeux, plus tout le userland invisible qui fait tourner tout ça), elles sont toutes simples à sécuriser par une restriction de droits (approximative au début, puis de plus en plus fine quand les modèles de sécurité s'améliorent), sauf peut-être le navigateur web qui a en plus le problème d'être devenu un sous-monde à part au sein duquel les problématiques de sécurité/compartementalisation se re-posent. Mais je reste confiant qu'un modèle même relativement simple permettrait de réduire de plusieurs ordres de grandeur la surface de la Trusted Computing Base.
Le client mail est loin d'etre simple, c'est le premier composant d'une suite de communication et il doit etre a terme capable de fournir un contexte fort en nourrissant, calendrier, carnet d'adresse, todo, im, … en information pertinente. A partir du moment ou tu commences a ajouter des fonctions de communication et de contexte facilement integrable dans une application externe, tu peux imaginer les scenarios suivant :
Dans ton editeur de code, tu as une ligne de code que tu ne comprend pas, tu veux en discuter avec l'auteur. Tu fais un petit tour dans le menu contextuel, celui-ci te propose de discuter avec l'auteur sur IRC ou par IM en utilisant les informations fournit par Git, ton carnet d'adresse et ton client IRC/IM.
Tu ouvres un PDF depuis ton client mail, ajoute des notes dedans, puis repond au mail precedent. Ce serait plutot utile si le client mail pouvait t'afficher les notes prises dans ton lecteur de PDF.
Tu recois un lien via une discussion dans un mail. Tu navigues un peu dans le site. Puis tu reviens dans le mail pour faire une reponse. Ce serait interressant de pouvoir afficher une arborescence du sites visite de maniere a pouvoir mieux ce souvenir de ce qu'on voulait repondre.
Tu te souviens que suites a une discussion avec quelqu'un en particulier, tu avais fait une recherche qui t'avait donnee un resultat interressant. Tu ouvres ton carnet d'adresse, clicke sur la personne et tu as acces a l'historique de toutes les actions que tu as fait en rapport avec cette personne. Il devient ainsi facile de retrouver le resultat que tu cherchais.
C'est juste des idees, mais tu peux imaginer le meme genre de scenario avec ton IM, IRC ou les SMS. Aujourd'hui, ils n'existent aucun environnement qui fournit ce genre d'infrastructure. Les plus proche sont Android et KDE. Mais ils ont tous les deux des problemes de securites de mon point de vue. Maintenant si on developpe une telle suite de communication, il est absolument necessaire de penser comment realiser la securite de l'ensemble, sans impacter les performances (faut que ca tourne sur n'importe quel machine a peu pres moderne du smartphone au desktop en incluant les netbook) et en ayant une UI qui facilite le plus possible la vie de l'utilisateur.
D'ailleur, je pense bien que c'est un gros fail de Apple de ne pas permettre ce genre de fonctionnalite. Mais bon, on verra si le futur ira dans cette direction ou non.
Pour moi ce n'est pas au calendrier d'indexer mes mails mais plutôt au client mail de prévenir le calendrier s'il détecte un événement; ou alors à un démon externe de faire la médiation entre les deux. Dans tous les cas le processus calendrier n'a pas besoin des droits sur mes mails.
Hum, un demon externe en charge de processer les mails, voyons les problemes. Comment peut-on etendre l'analyse du contenu des mails ? Est-ce qu'un langage de script sera suffisant ? Ou faut-il inclure aussi la possibilite d'avoir des modules binaires ? Comment tagger automatiquement les images inclus en piece jointe en passant dessus un OCR ou une reconnaissance faciale ? Dans quel langage serait ecrit une IA qui comprendrait le contenu meme du mail ? Je pense que tu as maintenant une idee plus precise des contraintes.
Pour moi dans un bon design il y a des cycles de conception avec une discussion entre les concepteurs du modèle de sécurité et les concepteurs des applications.
C'est ce que l'on fait ici :-) Bon, j'avoue j'ai hijacke ce thread a propos d'Apple…
[^] # Re: La politique de sécurité est bonne
Posté par cedric . En réponse à la dépêche Bref, MPlayerX quitte le Mac App Store. Évalué à 2.
De rien et merci a toi de partager ton point de vue. Participant au projet Enlightenment, c'est une discussion on ne peut plus interressante pour moi.
Tu mets exactement le doigt sur une lacune du monde GNU/Linux. Le cloud (via Google, Facebook, voir meme github) et Android qui vient globalement du meme monde, offre une plus grande integration et plus de possibilite d'etendre les fonctions d'une application que ne le permette des applications locales. Pourtant mon PC a acces a tous les cloud en meme temps et a plus de donnees personnelles stocke localement que n'importe lequel de ces services en ligne. Donc pourquoi les developpeurs ne font il pas plus pour integrer tout ca et faciliter la vie de l'utilisateur ? En fait, le projet KDE a pas mal d'avance dans le domaine (principalement parce qu'il redeveloppe toutes leurs applications), mais on est encore loin de ce qu'on peut juste imaginer aujourd'hui.
Idee interressante. En gros, on obtient un modele ou on a un grabber qui aura des droits particuliers et sera en mesure d'extraire l'information pour la presenter aux applications. Ca complexifie clairement le code et augmente la consomation de ressource, mais faut voir si cela a un impact important au final. C'est une idee a creuser, voir plus bas.
Le client mail est loin d'etre simple, c'est le premier composant d'une suite de communication et il doit etre a terme capable de fournir un contexte fort en nourrissant, calendrier, carnet d'adresse, todo, im, … en information pertinente. A partir du moment ou tu commences a ajouter des fonctions de communication et de contexte facilement integrable dans une application externe, tu peux imaginer les scenarios suivant :
Dans ton editeur de code, tu as une ligne de code que tu ne comprend pas, tu veux en discuter avec l'auteur. Tu fais un petit tour dans le menu contextuel, celui-ci te propose de discuter avec l'auteur sur IRC ou par IM en utilisant les informations fournit par Git, ton carnet d'adresse et ton client IRC/IM.
Tu ouvres un PDF depuis ton client mail, ajoute des notes dedans, puis repond au mail precedent. Ce serait plutot utile si le client mail pouvait t'afficher les notes prises dans ton lecteur de PDF.
Tu recois un lien via une discussion dans un mail. Tu navigues un peu dans le site. Puis tu reviens dans le mail pour faire une reponse. Ce serait interressant de pouvoir afficher une arborescence du sites visite de maniere a pouvoir mieux ce souvenir de ce qu'on voulait repondre.
Tu te souviens que suites a une discussion avec quelqu'un en particulier, tu avais fait une recherche qui t'avait donnee un resultat interressant. Tu ouvres ton carnet d'adresse, clicke sur la personne et tu as acces a l'historique de toutes les actions que tu as fait en rapport avec cette personne. Il devient ainsi facile de retrouver le resultat que tu cherchais.
C'est juste des idees, mais tu peux imaginer le meme genre de scenario avec ton IM, IRC ou les SMS. Aujourd'hui, ils n'existent aucun environnement qui fournit ce genre d'infrastructure. Les plus proche sont Android et KDE. Mais ils ont tous les deux des problemes de securites de mon point de vue. Maintenant si on developpe une telle suite de communication, il est absolument necessaire de penser comment realiser la securite de l'ensemble, sans impacter les performances (faut que ca tourne sur n'importe quel machine a peu pres moderne du smartphone au desktop en incluant les netbook) et en ayant une UI qui facilite le plus possible la vie de l'utilisateur.
D'ailleur, je pense bien que c'est un gros fail de Apple de ne pas permettre ce genre de fonctionnalite. Mais bon, on verra si le futur ira dans cette direction ou non.
Hum, un demon externe en charge de processer les mails, voyons les problemes. Comment peut-on etendre l'analyse du contenu des mails ? Est-ce qu'un langage de script sera suffisant ? Ou faut-il inclure aussi la possibilite d'avoir des modules binaires ? Comment tagger automatiquement les images inclus en piece jointe en passant dessus un OCR ou une reconnaissance faciale ? Dans quel langage serait ecrit une IA qui comprendrait le contenu meme du mail ? Je pense que tu as maintenant une idee plus precise des contraintes.
C'est ce que l'on fait ici :-) Bon, j'avoue j'ai hijacke ce thread a propos d'Apple…