Un e-mail qui s’autosupprime pour garantir la confidentialité, un brevet déposé par AT&T

Un e-mail qui s’autosupprime après lecture pour garantir la confidentialité
Ou même sans lecture, un brevet déposé par AT&T


Si vous n’avez pas eu votre dose de roman d’espionnage avec l’affaire Snowden/PRISM, ce brevet de AT&T va certainement vous combler.

Le géant des télécoms américains vient en effet d’imaginer un e-mail à la « Mission Impossible » qui s’autosupprime.

Deux options sont possibles : soit l'e-mail disparaît une fois ouvert, lu puis fermé. Soit l'e-mail est effacé à une date et une heure données, que le destinataire l’ait lu ou pas (les puristes feront remarquer que l’on n’est donc pas exactement dans la configuration imposée à Jim Phelps).

http://ftp-developpez.com/gordon-fow...struct%201.png

Le document d’AT&T explique cependant que cette opération de suppression nécessite à la fois une application particulière pour le destinataire (un client de messagerie spécifique) et une application côté serveur. C’est le client qui effacera l'e-mail, sur ordre du serveur.

http://ftp-developpez.com/gordon-fow...struct%202.png

Autrement dit, il ne sera pas possible d’envoyer un e-mail de ce type à une adresse sur un service hébergé (Hotmail, Gmail, etc.). Le destinataire devra être équipé avec la bonne application, et donc avoir donné son consentement pour recevoir ce type de message - en milieu professionnel, dans une entreprise par exemple.

Intéressant dans le cadre de problématiques de confidentialité professionnelle. Pas pour envoyer des e-mails compromettants ou que l’on pourrait regretter ensuite (ou alors à un(e) collègue équipé(e) du système ?).

Reste à savoir si AT&T a mis des équipes sur ce projet ou s’il ne s’agit que d’un brevet déposé « au cas où ».

http://ftp-developpez.com/gordon-fow...struct%203.png

Source : brevet de AT&T

Et vous ?

:fleche: Idée intéressante ou conseilleriez-vous d’autres méthodes pour garantir la confidentialité d’un e-mail ?

Citation:

---

Envoyé par Gordon Fowler

:fleche: Idée intéressante ou conseilleriez-vous d’autres méthodes pour garantir la confidentialité d’un mail ?

---

Idée intéressante mais nécessitant client et serveur spécifique, donc quelque peu limitée. Ceci dit faire évoluer les clients et serveurs n'est pas chose impossible.

Quant à la confidentialité, le mail dans la boite du destinataire ou dans le logiciel client n'est quand même qu'un petit aspect du problème.

Il existe quand même encore et toujours une grosse faille dans le système : les mails circulent toujours en texte clair sur le réseau.

Cette fonctionnalité peut être sympa pour faire du ménage automatiquement dans la boite mail, inutile de conserver plusieurs jours/semaines/mois un événement anecdotique comme le prochain essai de sirène d'alarme du bâtiment mercredi à 11H15.

Par contre pour la fonction sécurité, je n'y crois absolument pas. Rien n'empêche durant la lecture d'enregistrer le message dans un autre format et ce nouveau format ne sera pas impacté par la fonction de sécurité sur le mail.

Sinon, il y a ZeroBin, qui marche très bien : lien

On peut choisir directement le moment de suppression : à la première lecture, dans quelques minutes, heures ...

C'est globalement une bonne idée, mais je ne pense pas que ça necessite un brevet, dans le sens où ça n'a rien d'une innovation ou d'une invention ...

M'enfin bon, le monde est comme ça, on pense à un moindre truc, hop, brevet !

Et si le destinataire copie-colle le texte du mail pour le stocker dans un fichier txt? lol

Citation:

---

Envoyé par totocaracana

C'est globalement une bonne idée, mais je ne pense pas que ça necessite un brevet, dans le sens où ça n'a rien d'une innovation ou d'une invention ...

M'enfin bon, le monde est comme ça, on pense à un moindre truc, hop, brevet !

---

Si c'est une innovation dans le sens ou ce n'est pas prévu dans les protocoles de gestion des mails, que ce n'est pas encore implanté, mais que ce, somme toute, relativement simple à mettre en place et à normaliser.
Ne pas oublier qu'il ya quelques années, les mails ne savaient pas transmettre de fichier binaires ni de pièces jointes, qu'il n'y a pas si longtemps non plus, c'était impensable que le corps du mail soit autre chose que du pur texte, comme du texte enrichi sauce html. D'ailleurs tous les clients encore à l'heure actuelle ne supporte pas l'html.

Donc oui, c'est une idée relativement bonne susceptible d'avoir du succès.

Et dans ce monde brute, si tu as une idée et que tu ne veux pas te la faire piquer*, faut déposer un brevet !

* Traduire : Si tu veux te faire un max de blé avec car il est fort probable qu'elle puisse être largement reprise

Il faut peut être un hardware spécifique qui explose après la lecture du mail ?

Ca relancerait le marché du PC et mettrait un peu d'ambiance dans les bureaux un truc pareil :mouarf:

Plus sérieusement, s'il faut un serveur spécifique et un client spécifique, je n'appelle pas ça un mail.

Citation:

---

Envoyé par sinople

Plus sérieusement, s'il faut un serveur spécifique et un client spécifique, je n'appelle pas ça un mail.

---

Je crois que tu as mis le doigt sur ce qui me titillait sans que je trouve ce que c'était.

Je trouvais déjà que si ça nécessitait un serveur mais surtout un client spécifique, c'était pas vraiment utile.
Mais effectivement, si on y réfléchit bien, ce n'est même pas vraiment un mail. C'est juste un message transitant sur le réseau par le même protocole que le mail mais dont les spécificités sont telles qu'elles ne permettent pas de la qualifier de mail. Un peu comme les "invitations Outlook" qui transitent de la même façon qu'un mail mais n'en sont pas vraiment vu que spécifiques à Outlook.

La question n'est pas de savoir d'où il vient ou où il va, mais par où il passe :aie:

Idée : un portable qui appelle "dans le vide" pour ne pas être écouté par la NSA...
;)

Sympatique comme tout, ça fait penser un peu à mission impossible :mrgreen:

Gros bémol, le besoin d'avoir une application server spécifique.
A voir...

Citation:

---

Envoyé par sinople

Plus sérieusement, s'il faut un serveur spécifique et un client spécifique, je n'appelle pas ça un mail.

---

Citation:

---

Envoyé par Loceka

Je trouvais déjà que si ça nécessitait un serveur mais surtout un client spécifique, c'était pas vraiment utile.
Mais effectivement, si on y réfléchit bien, ce n'est même pas vraiment un mail.

---

Citation:

---

Envoyé par Shuty

Gros bémol, le besoin d'avoir une application server spécifique.

---

Oui et Non !

Oui, actuellement c'est une fonctionnalité qui n'est prise en charge par aucun serveur et client. Ça ne peut donc pas être déployer de façon universelle, et si on veut l'utiliser dans l'immédiat il faudra utiliser des logiciels spécifiques compatible entre-eux.

Non, il suffit que l'idée soit suffisamment séduisante pour l'objet d'une RFC amendant le service mail, ajoutant cette fonctionnalité et indiquant les modalités de mise en oeuvre. Il suffit que, ensuite, les logiciels des serveurs mails et des clients mails soient mis à jours pour que cette fonctionnalité devienne petit-à-petit universelle.
C'est pas immédiat, mais si l’intérêt est important et que les choses bougent, ça peut être effectif à l'échelle de 3-4ans.

Rapellez-vous la transmission de fichiers binaires ou à encodage différents au début,ce n'était pas possible. Puis les type MIME ont été mis en place, les codage Base64 et autres aussi. Aujourd'hui c'est une réalité au point que personne ne puisse imaginer qu'un jour c'était pas possible.

Citation:

---

Envoyé par fadace

La question n'est pas de savoir d'où il vient ou où il va, mais par où il passe :aie:

---

Ce point reste bien le plus important en matière de sécurité de communication.
Un mail qui s’autodétruit ne représente absolument aucune sécurité supplémentaire s'il a pu être lu ou intercepté avant destruction.

Citation:

---

Envoyé par sinople

Plus sérieusement, s'il faut un serveur spécifique et un client spécifique, je n'appelle pas ça un mail.

---

Confond pas l'aspect fonctionnel et l'aspect technique.
Fonctionnellement, c'est bien un mail : ça a un destinataire, un destinateur, un sujet, un message et des attchements.
Techniquement, ok ça diffère de l'email conventionnel.

Citation:

---

Envoyé par sevyc64

Et dans ce monde brute, si tu as une idée et que tu ne veux pas te la faire piquer*, faut déposer un brevet !

---

Mais bien sur !

Pour reprendre ton annecdote, qu'est-ce qui ce serait passer si l'inventeur du type MIME ou du codage base64 ( qui est utilisé bien au delà des mails entre nous ) avaient mis leur "concept" sous brevet ?

Le fait qu'une idée aussi triviale puisse être mise sous brevet, montre juste encore une fois de plus que les bureaux des brevets méritent des coups de pied au cul.
C'est vrai que c'est réellement "révolutionnaire" un client mail capable d'effacer tout seul l'email reçu.. Woot woot... une èleve de première année info aurait certainement avoir l'idée sans peine.

Sans parler qu'il n'y est pas possible physiquement de s'assurer que le client efface réellement le contenu à partir du moment où il a été affiché quelque part...
Cette saleté n'est rien d'autre qu'un DRM appliqué aux emails avec le paramètre "vu_authorisee=1".... Techniquement ça ne peut pas marcher.

D'abord, il n'y a pas d'affaire "Snowden/Prism" mais une affaire Prism/Google/Apple/Microsoft/etc.

Ensuite cette idée ne répond en rien à la problématique de l'espionnage.

À ce sujet, je me demande si la forte insistance des uns et des autres, y compris Mozilla avec l'arrêt des développements Thunderbird, à aller vers le webmail plutôt que le client lourd n'est pas poussée par les autorités pour mieux nous surveiller. Et puis faut être bien naïf pour croire que ceux qui ont vraiment l'intention de commettre des actes terroristes vont se laisser piéger par ces intrusions. Désolé pour le HS.

Il me semble que les spécialistes informatiques de la Gendarmerie National ont déjà mis au point quelle que chose de ressemblant à partir d'un serveur et client Thunderbird lié à la lecture d'email dans la chaine de commandement.

Il faut aussi penser à virer la touche printscreen du clavier...
Bref j'y crois pas, et en plus y'a aucune raison que cette idée en carton soit un brevet.

Citation:

---

Envoyé par sevyc64

Si c'est une innovation dans le sens ou ce n'est pas prévu dans les protocoles de gestion des mails, que ce n'est pas encore implanté, mais que ce, somme toute, relativement simple à mettre en place et à normaliser.

---

Faudrait voir quand a été déposé le brevet, car Outlook (à partir de 2003 au moins) permet de mettre une date d'expiration à n'importe quel message... C'est transmis dans l'entête (Expiry-Date), charge au client destinataire de savoir l'utiliser.

Citation:

---

Envoyé par ner0lph

Faudrait voir quand a été déposé le brevet, car Outlook (à partir de 2003 au moins) permet de mettre une date d'expiration à n'importe quel message... C'est transmis dans l'entête (Expiry-Date), charge au client destinataire de savoir l'utiliser.

---

De ce que j'en connais de cette fonction, le message n'est pas supprimé, le titre est juste barré dans la boite de réception quand la date est dépassée, mais le message est toujours présent et consultable.
De plus, il me semble que cela ne fonctionne qu'avec un client Outlook uniquement.

Citation:

---

Envoyé par sevyc64

De ce que j'en connais de cette fonction, le message n'est pas supprimé, le titre est juste barré dans la boite de réception quand la date est dépassée, mais le message est toujours présent et consultable.
De plus, il me semble que cela ne fonctionne qu'avec un client Outlook uniquement.

---

Oui, c'est exact, tu viens de me le rappeler ! Pour le client, il suffit qu'il y en ai un qui sache interpréter les entêtes Expiry-Date et X-Expiry-Date, il ne doit pas y en avoir foule. :aie:

La question est : est-ce que cela suffirait à invalider le brevet ? :question: On verra bien.

Il n'y a pas de brevet dans une idée, ce n'est que dans la manière de la réaliser et les moyens de sa mise en oeuvre que c'est possible, pardon : que c'était possible !
:calim2:

Je suis d'accord, d un point de vue sécurité c est ridicule! Du point de vue des spams qui vous encombre la boîte aux lettres, ils n ont cas pas en envoyer! Et de toute façon ceux qui en envoi se contre foute qu'ils soient un jour effacés! Et pour les personnes qui reçoivent des messages intéressants, ils n'ont pas envi qu'ils disparaissent de leurs boîtes sans être averti. Et qu'en à poser un brevet sur un truc aussi stupide et sur des protocoles d'échange qui se veulent par définition open. Je milite carrément pour que personne ne les implémente avant qu'ils soient dans le domaine public! (Si toute fois quelqu'un y trouve une quelconque utilité)

C'est louable de vouloir enrichir la technologie mél, sauf dans un cadre protégé par brevet, donc fermé.

En plus, moi, je veux être sûr de qui l'a lu, aujourd'hui, on en est pas encore à la reconnaissance faciale ?

Bonsoir a tous.
Un message qui s'efface tout seul, c'est sécure, mais il reste la faille exprimée plus haut dans le fil : ce message peut toujours être intercepté, et pour finir, effectivement recopié bêtement avec un crayon. On parle ailleurs sur le site de ces russes qui vont retourner a la machine a écrire (c'est pas si débile que ça en fait)
Alors , inventeur dans des temps plus anciens, je pense éventuellement breveter le mail ininterceptable et incopiable même a la main : le mail non expédié. tout est résolu coté sécurité (pas du coté émetteur je l'avoue, encore un effort conceptuel a prévoir)
Reste un problème non résolu : quid du contenu qu'on aurait voulu (éventuellement) transmettre dans ce mail . Je laisse ce détail a de plus compétents que moi, j'ai apporté une pierre a l'édifice, je ne peux pas tout faire a moi seul...
A plus.
Dutilleul.

Un vrai réseau où le transporteur assure la confidentialité et la garantie des interlocuteurs.
X25 en était un !
:mrgreen: