Repository with sources and generator of https://larlet.fr/david/ https://larlet.fr/david/
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

преди 5 години
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451
  1. <!doctype html>
  2. <html lang=fr>
  3. <head>
  4. <!-- Always define the charset before the title -->
  5. <meta charset=utf-8>
  6. <title>Ouvert et décentralisé, est-ce suffisant ? — Biologeek — David Larlet</title>
  7. <!-- Define a viewport to mobile devices to use - telling the browser to assume that the page is as wide as the device (width=device-width) and setting the initial page zoom level to be 1 (initial-scale=1.0) -->
  8. <meta name="viewport" content="width=device-width, initial-scale=1"/>
  9. <!-- Fake favicon, to avoid extra request to the server -->
  10. <link rel="icon" href="data:;base64,iVBORw0KGgo=">
  11. <link type="application/atom+xml" rel="alternate" title="Feed" href="/david/log/" />
  12. <link rel="manifest" href="/manifest.json">
  13. <link rel="stylesheet" href="/static/david/css/larlet-david-_J6Rv.css" data-instant-track />
  14. <noscript>
  15. <style type="text/css">
  16. /* Otherwise fonts are loaded by JS for faster initial rendering. See scripts at the bottom. */
  17. body {
  18. font-family: 'EquityTextB', serif;
  19. }
  20. h1, h2, h3, h4, h5, h6, time, nav a, nav a:link, nav a:visited {
  21. font-family: 'EquityCapsB', sans-serif;
  22. font-variant: normal;
  23. }
  24. </style>
  25. </noscript>
  26. <!-- Canonical URL for SEO purposes -->
  27. <link rel="canonical" href="https://larlet.fr/david/biologeek/archives/20090615-ouvert-et-decentralise-est-ce-suffisant">
  28. </head>
  29. <body>
  30. <div>
  31. <header>
  32. <nav>
  33. <p>
  34. <small>
  35. Je suis <a href="/david/" title="Profil public">David Larlet</a>, <a href="/david/pro/" title="Activité professionnelle">artisan</a> du web qui vous <a href="/david/pro/accompagnement/" title="Activité d’accompagnement">accompagne</a><span class="more-infos"> dans l’acquisition de savoirs pour concevoir des <a href="/david/pro/produits-essentiels/" title="Qu’est-ce qu’un produit essentiel ?">produits essentiels</a></span>. <span class="more-more-infos">Discutons ensemble d’une <a href="/david/pro/devis/" title="En savoir plus">non-demande de devis</a>.</span> Je partage ici mes <a href="/david/blog/" title="Expériences bienveillantes">réflexions</a> et <a href="/david/correspondances/2017/" title="Lettres hebdomadaires">correspondances</a>.
  36. </small>
  37. </p>
  38. </nav>
  39. </header>
  40. <section>
  41. <h1 property="schema:name">Ouvert et décentralisé, est-ce suffisant ?</h1>
  42. <article typeof="schema:BlogPosting">
  43. <div property="schema:articleBody">
  44. <img src="/static/david/biologeek/images/logos/identica.png" alt="vignette" style="float:left; margin: 0.5em 1em;" property="schema:thumbnailUrl" />
  45. <p>Prenons le cas pratique du micro-blogging. Comme un irréductible gaulois j'ai résisté des mois à <a href="http://twitter.com/">twitter</a>. Ils ont eu raison de moi et j'ai cédé à un moment où tout le monde parle d'un <a href="http://rn7.net/w/BigSwitch">#BigSwitch</a>. Chacun incite ses contacts à migrer vers <a href="http://identi.ca/">identi.ca</a>, et éventuellement on publie sur les deux plateformes pendant un moment.</p>
  46. <p><em>Note : ce billet a été rédigé par <a href="http://eric.daspet.name">Éric Daspet</a>.</em></p>
  47. <h2>Où on part</h2>
  48. <p>Vous avez certainement déjà connu ça quand une connaissance est passé de hotmail à gmail. Il faut prévenir tous ses contacts afin qu'ils mettent à jour les coordonnées. Trop souvent un message part à l'ancienne adresse ou un contact n'a pas fait attention à la migration. Il y a des pertes, et à terme il y aura une coupure entre les anciens restés sur twitter et les nouveaux passés sur identi.ca.</p>
  49. <p>Du coup j'ai regardé identi.ca. Il y a du mieux fonctionnellement mais <strong>le grand argument c'est l'ouverture, appelée à permettre plus d'innovation et d'interopérabilité</strong>. Pour assurer cette ouverture et cette innovation, la plate-forme est décentralisée : Chacun peut monter son propre serveur <a href="http://laconi.ca/">laconi.ca</a> (nom du logiciel lui-même) et se connecter avec les autres, qu'ils soient sur le même serveur sur identi.ca, ou sur le leur.</p>
  50. <p>Vous avez à peu près le contrôle sur vos données, vous pouvez faire évoluer la plate-forme, mais est-ce vraiment suffisant ?</p>
  51. <h2>Où on recommence</h2>
  52. <p>Sauf que je suis pénible, et que les migrants ne semblent pas apprendre de leurs erreurs : <strong>ils créent majoritairement un compte sur le serveur "officiel" d'identi.ca</strong>. Que ce passera-t-il quand ce serveur ne sera plus innovant ? quand il ajoutera de la publicité dans les messages ? quand il s'arrêtera par faute de sous ? ou simplement qu'il proposera des évolutions peu appréciées ?</p>
  53. <p>Il y aura un second big switch. Tous ces gens vont changer de serveur, trouver un nouvel identifiant, demander à tous leurs contacts de se connecter à nouveau (et dans le pire des cas arrêter de suivre ceux qui sont sur l'ancien serveur, scindant la communauté). C'est déjà pénible de le faire une fois, de voir chaque contact pendant un mois te demander de changer l'adresse à suivre, mais si c'est pour recommencer tous les ans, là, non !</p>
  54. <p>Rien ne permet d'imaginer que ce qui arrive aujourd'hui à twitter n'arrivera pas demain à identi.ca, rien. Ou plutôt tout permet de penser que ça risque d'arriver de nouveau. Personne de votre entourage n'a changé d'adresse email deux fois ? peut être même en moins de deux ans. Nous y voilà. Si c'est pour se lier à un autre prestataire, nous sommes condamnés à recommencer.</p>
  55. <h2>Où on décentralise, mais tous au même endroit</h2>
  56. <p><strong>La décentralisation n'est utile que si on s'en sert, et vous ne vous en servez pas camarades</strong>. Pour bénéficier de la décentralisation il faut contrôler son serveur. Cela implique d'avoir un serveur connecté 24/24, d'y installer et configurer le logiciel, et d'opérer la maintenance régulière. Là vous contrôlerez votre identifiant et serez à l'abri de l'enfermement d'un prestataire. </p>
  57. <p>Entendons nous bien, il existe des serveurs laconi.ca gratuits, plus qu'ils n'en faut, mais cela ne résoudra rien. En fait ça peut même être pire car au lieu d'avoir un big switch une fois que identi.ca dérape, on aura plein de bascules en permanence à chaque fois que c'est un serveur mineur qui tombe ou qui fait quelque chose de mal.</p>
  58. <p>Certains auront leur propre serveur, comme je le fais moi pour mon blog par exemple, mais ils seront rares et on ne peut guère demander à tous de jouer l'informaticien. Même pour ces derniers c'est pénible et chronophage. </p>
  59. <h2>Où on contrôle son identifiant</h2>
  60. <p><strong>Avec la décentralisation ce qui est important c'est le contrôle de l'identifiant</strong>. Un identifiant doit être pérenne, et passer d'un serveur à l'autre sans avoir à changer. Cela veut dire que si demain je change de prestataire pour mon micro-blogging, les gens pourront continuer à me suivre, de façon presque transparente.</p>
  61. <p>Le système laconi.ca ne permet pas d'identifiant pérenne indépendant du serveur. <strong>Voilà la faille</strong>. </p>
  62. <p>Une solution serait que l'identifiant pérenne soit le nom de domaine sur lequel tourne votre serveur laconi.ca. Vous achetez et contrôlez votre nom de domaine pour une somme modique (5 à 15 euros par an) et vous pourrez le faire pointer vers le prestataire que vous souhaitez. C'est déjà ainsi que je procède pour mes pages web, mon adresse mail, mon identifiant de messagerie instantanée, etc. Concernant laconi.ca il suffirait d'un changement léger dans le code du logiciel pour qu'il sache quel domaine utiliser suivant comment on y accède, compatibilité totale avec l'existant non modifié. </p>
  63. <p>C'est la voie royale, qui vous permet de garder toujours contrôle de votre identité, quel que soit le média. <strong>Plus que le contrôle de mes données passées, c'est le contrôle de mon identité elle-même que je sauvegarde</strong>. Pour une dizaine d'euros par an (le prix d'un nom de domaine), ce n'est vraiment pas cher payé.</p>
  64. <h2>Où on indirectionne</h2>
  65. <p>L'indirection est la voie du pauvre, mais c'est aussi celle qui pourra toucher le plus grand monde. C'est par exemple ce qu'utilise la <a href="http://openid.net/specs/openid-authentication-1_1.html#delegating_authentication">délégation OpenID</a>.</p>
  66. <p>Pour joindre le serveur OpenID d'un correspondant, je regarde son identifiant et je vais chercher la page web associée. Là je regarde s'il y est indiqué quel prestataire OpenID je dois utiliser pour cet identifiant. Pour changer de prestataire mon correspondant n'a qu'à mettre à jour sa page web.</p>
  67. <p>Pour laconi.ca il suffirait d'aller regarder la page de profil de mon correspondant, repérer l'adresse de la page personnelle, et y récupérer l'adresse du prestataire de micro-blogging. Si identi.ca ne me convient plus, je peux modifier ma page personnelle. Le serveur de micro-blogging de mes correspondant lira mon ancien profil identi.ca, ira trouver ma page personnelle et y verra mon nouveau serveur. Tout peut être mis à jour en toute transparence sans avoir à avertir tout le monde et à risquer des coupures. Cette vérification peu facilement être réalisée une à deux fois par semaine sans pénaliser les performances.</p>
  68. <p>On ne résout pas tout. En particulier seul le contrôle d'un nom de domaine propre me permettrait de palier un arrêt total d'identi.ca, mais on éviterait exactement ce qu'il se passe actuellement lors de la migration de twitter vers identi.ca. </p>
  69. <h2>Où on pose plein de questions</h2>
  70. <p><strong>Il reste à définir comment déclarer le serveur de micro-blogging dans ma page web</strong>, et c'est là que je fais appel aux informaticiens. Par quel système est-il préférable de faire la déclaration ? une balise &lt;meta&gt; ? un fichier XRDS ? un fichier FOAF ? (et si oui quelles balises)</p>
  71. <p>L'expérience OpenID m'incite à penser qu'une balise &lt;meta&gt; ou &lt;link&gt; est ce qu'il y a de plus simple mais un fichier FOAF reste très tentant. On peut envisager les deux, mais il faut décider des balises et du mécanisme exacte de découverte. Quid ? j'attends vos commentaires et vos propositions.</p>
  72. </div>
  73. </article>
  74. <footer>
  75. <h6 property="schema:datePublished">— 15/06/2009</h6>
  76. </footer>
  77. </section>
  78. <section>
  79. <div>
  80. <h3>Articles peut-être en rapport</h3>
  81. <ul>
  82. <li><a href="/david/biologeek/archives/20101130-de-lopendata-au-linkeddata-exemple-de-nosdonneesfr/" title="Accès à ★ De l&#39;OpenData au LinkedData : exemple de nosdonnees.fr">★ De l&#39;OpenData au LinkedData : exemple de nosdonnees.fr</a></li>
  83. <li><a href="/david/biologeek/archives/20091202-discussions-sur-les-applications-web-libres/" title="Accès à ★ Discussions sur les applications web libres">★ Discussions sur les applications web libres</a></li>
  84. <li><a href="/david/biologeek/archives/20091013-securite-twitter-confiance-habitudes/" title="Accès à Sécurité, twitter, confiance et habitudes">Sécurité, twitter, confiance et habitudes</a></li>
  85. </ul>
  86. </div>
  87. </section>
  88. <section>
  89. <div id="comments">
  90. <h3>Commentaires</h3>
  91. <div class="comment" typeof="schema:UserComments">
  92. <p class="comment-meta">
  93. <span class="comment-author" property="schema:creator">idoric</span> le <span class="comment-date" property="schema:commentTime">15/06/2009</span> :
  94. </p>
  95. <div class="comment-content" property="schema:commentText">
  96. <p>Réflexion très pertinente. Il y a juste un point qui me laisse perplexe :</p>
  97. <p>&gt; « Avec la décentralisation ce qui est important c&#39;est le contrôle de l&#39;identifiant. Un identifiant doit être pérenne, et passer d&#39;un serveur à l&#39;autre sans avoir à changer »</p>
  98. <p>Dans un tel système, qui s&#39;assurerait de l&#39;unicité de l&#39;identifiant si ce n&#39;est le serveur ? L&#39;identifiant pourrait reposer sur un couple clé publique/privée, mais ça serait lourd à gérer et sensible aux avancées dans la science du déchiffrage… une autre idée ?</p>
  99. </div>
  100. </div>
  101. <div class="comment" typeof="schema:UserComments">
  102. <p class="comment-meta">
  103. <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">15/06/2009</span> :
  104. </p>
  105. <div class="comment-content" property="schema:commentText">
  106. <p>&gt; Dans un tel système, qui s&#39;assurerait de l&#39;unicité de l&#39;identifiant si ce n&#39;est le serveur ?</p>
  107. <p>Dans le système web, l&#39;URI garantie l&#39;unicité de cet identifiant.</p>
  108. </div>
  109. </div>
  110. <div class="comment" typeof="schema:UserComments">
  111. <p class="comment-meta">
  112. <span class="comment-author" property="schema:creator">idoric</span> le <span class="comment-date" property="schema:commentTime">15/06/2009</span> :
  113. </p>
  114. <div class="comment-content" property="schema:commentText">
  115. <p>Je me suis mal exprimé. Mon inquiétude porte sur le fait de réussir à éviter l&#39;usurpation d&#39;identifiant. Pour éviter de se faire piquer son URI, il faut soit posséder le serveur dans le cas d&#39;une URL, ou alors il faut… s&#39;identifier auprès d&#39;un tiers de confiance. On n&#39;a alors fait que déplacer le problème qui continue à se poser exactement dans les mêmes termes : comment s&#39;identifier sans serveur et sans clés publiques/privées ?</p>
  116. </div>
  117. </div>
  118. <div class="comment" typeof="schema:UserComments">
  119. <p class="comment-meta">
  120. <span class="comment-author" property="schema:creator">Florent V.</span> le <span class="comment-date" property="schema:commentTime">16/06/2009</span> :
  121. </p>
  122. <div class="comment-content" property="schema:commentText">
  123. <p>Pour ma part, j’ai écarté l’idée d’utiliser identi.ca pour la raison suivante: tous les messages publiés le sont sous une licence Creative Commons. Le site est relativement évasif là-dessus, la seule information explicite est dans la page «Privacy», donc je ne sais pas si ce genre de mention est réellement valable, mais dans le doute je préfère m’abstenir.</p>
  124. <p>Je suis un fan des licences Creative Commons, mais je n’aime pas le principe de placer tout ce qu’on publie sous ce type de licence, de manière automatique. Je trouve ça déjà limite pour des billets de blogs, et ridicule pour des messages de 140 caractères. Je préfère identifier clairement quels œuvres, contenus ou ressources je partage avec ce type de licence.</p>
  125. </div>
  126. </div>
  127. <div class="comment" typeof="schema:UserComments">
  128. <p class="comment-meta">
  129. <span class="comment-author" property="schema:creator">Nicolas Hoizey</span> le <span class="comment-date" property="schema:commentTime">16/06/2009</span> :
  130. </p>
  131. <div class="comment-content" property="schema:commentText">
  132. <p>Opera Unite à la rescousse ?</p>
  133. </div>
  134. </div>
  135. <div class="comment" typeof="schema:UserComments">
  136. <p class="comment-meta">
  137. <span class="comment-author" property="schema:creator">Eric</span> le <span class="comment-date" property="schema:commentTime">16/06/2009</span> :
  138. </p>
  139. <div class="comment-content" property="schema:commentText">
  140. <p>@Idoric: &quot;il faut soit posséder le serveur dans le cas d&#39;une URL, ou alors il faut… s&#39;identifier auprès d&#39;un tiers de confiance&quot;</p>
  141. <p>C&#39;est bien tout le sujet du billet. Tu n&#39;as pas besoin de détenir le serveur. Par contre tu as besoin de détenir ton identifiant.</p>
  142. <p>Si l&#39;identifiant est une URL cela impose au choix <br /> 1. d&#39;avoir un prestataire de confiance pour cette URL <br /> 2. ou de la gérer toi même.</p>
  143. <p>Pour le (1) ce n&#39;est pas si difficile. Trouver un prestataire qui te permet d&#39;avoir une page web que tu contrôles et que tu peux modifier est simple. Si cette page n&#39;est pas gérée par le même prestataire que ton serveur laconica, tu peux t&#39;estimer libre. Si tu veux changer de serveur laconica tu peux changer ce qu&#39;il y a dans ta page web. Si tu veux changer d&#39;URL tu peux changer ton profil laconica.</p>
  144. <p>Le problème n&#39;arrive que si tu dois changer les deux en même temps (ou sur une très courte période), mais c&#39;est tout l&#39;intérêt d&#39;avoir deux prestataires différents.</p>
  145. <p>Pour le (2) c&#39;est loin d&#39;être si complexe ou &quot;geek&quot; que ça n&#39;y parait. Il s&#39;agit juste de se payer un nom de domaine et de trouver un hébergeur qui accepte de l&#39;héberger. Tu peux trouver ça pour 5 à 15€ par an, et je serai étonné qu&#39;il n&#39;y ait pas de prestataires qui te permettent d&#39;héberger ton profil FOAF et OpenID sur ton nom de domaine gratuitement (ou presque) sans rien connaitre à la technique (ni même ce qu&#39;est une page web ou un ftp).</p>
  146. <p>Le nom de domaine te permet de garantir que tu contrôleras toujours ton URL et qu&#39;elle ne changera pas tant que tu payes les quelques euros par an (si un jour l&#39;architecture DNS s&#39;écroule, tu auras bien plus grave que la perte de ton identifiant laconica puisque quasiment tous les identifiants Internet se basent dessus, du mail au web en passant par la messagerie).</p>
  147. <p>Tu peux changer à l&#39;envie de prestataire pour l&#39;enregistrement/paiement de ton nom de domaine, de prestataire pour l&#39;hébergement de ta page web, et le contenu de ta page web pour le choix du serveur laconica.</p>
  148. <p>OpenID fonctionne ainsi. Tu choisis un serveur OpenID, un identifiant sur ce serveur, et tu références les deux sur ta page web. Au lieu de donner ton identifiant réel tu donnes toujours l&#39;URL de ta page. Quand tu veux changer de serveur ça changera aussi ton identifiant sur ce serveur mais peu importe, tu changeras ça sur ta page web (ce que les gens utilisent réellement) et ça sera transparent. Le reste c&#39;est de la sauce technique.</p>
  149. </div>
  150. </div>
  151. <div class="comment" typeof="schema:UserComments">
  152. <p class="comment-meta">
  153. <span class="comment-author" property="schema:creator">Eric</span> le <span class="comment-date" property="schema:commentTime">16/06/2009</span> :
  154. </p>
  155. <div class="comment-content" property="schema:commentText">
  156. <p>@Florent:</p>
  157. <p>Sauf erreur ce problème de licence existe pour identi.ca, pas pour laconi.ca. Rien ne peut t&#39;imposer la licence des contenus que tu publies chez toi. Sauf erreur de ma part rien dans l&#39;AGPL (licence de laconi.ca) ne peut t&#39;imposer la licence des contenus distribués par le logiciel (et quand bien même AGPL le ferait, je doute que ce serait une licence CC).</p>
  158. <p>Tu ne fais justement que renforcer l&#39;idée que même après un changement, tous les migrants risquent d&#39;avoir envie de migrer à nouveau, et donc que des identifiants stables et indépendants sont nécessaires.</p>
  159. </div>
  160. </div>
  161. <div class="comment" typeof="schema:UserComments">
  162. <p class="comment-meta">
  163. <span class="comment-author" property="schema:creator">Eric</span> le <span class="comment-date" property="schema:commentTime">16/06/2009</span> :
  164. </p>
  165. <div class="comment-content" property="schema:commentText">
  166. <p>Sur le même sujet :<br /><a href="http://www.identitywoman.net/personal-anchors-on-the-web-for-digital-identities">http://www.identitywoman.net/personal-anchors-on-the-web-for-digital-identities</a> et <a href="http://iwantmyname.com/">http://iwantmyname.com/</a></p>
  167. <p>Il y en a qui ont tout compris et qui prouvent que chacun peut contrôler son identifiant sans être informaticien.</p>
  168. </div>
  169. </div>
  170. <div class="comment" typeof="schema:UserComments">
  171. <p class="comment-meta">
  172. <span class="comment-author" property="schema:creator">Neovov</span> le <span class="comment-date" property="schema:commentTime">16/06/2009</span> :
  173. </p>
  174. <div class="comment-content" property="schema:commentText">
  175. <p>Je suis d&#39;accord avec toi Éric, mais je me pose d&#39;autres questions.</p>
  176. <p>Tu dis qu&#39;il est simple et qu&#39;il ne coute rien d&#39;acheter un nom de domaine. Là je te suis, mais à partir de ce moment, on restreint énormément les utilisateurs. Madame Michu n&#39;a pas à acheter un NDD, elle n&#39;en ferait rien et cherche à se simplifier la vie.</p>
  177. <p>Si je continuais dans ce sens (à l&#39;extrême), je dirai même que l&#39;identifiant est encore trop geek…</p>
  178. <p>Ensuite, il faut entretenir ce NDD, penser à le renouveler, ne pas se le faire piquer. C&#39;est peut-être absurde, mais ça peut arriver (par exemple le NDD de Monique qui s&#39;est fait squatter). Dans ce cas, on perd tout.</p>
  179. </div>
  180. </div>
  181. <div class="comment" typeof="schema:UserComments">
  182. <p class="comment-meta">
  183. <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">16/06/2009</span> :
  184. </p>
  185. <div class="comment-content" property="schema:commentText">
  186. <p>@Neovov :</p>
  187. <p>&gt; Ensuite, il faut entretenir ce NDD, penser à le renouveler, ne pas se le faire piquer. C&#39;est peut-être absurde, mais ça peut arriver (par exemple le NDD de Monique qui s&#39;est fait squatter). Dans ce cas, on perd tout.</p>
  188. <p>Remplace &quot;NDD&quot; par &quot;carte d&#39;identité&quot; dans ta phrase ;)</p>
  189. </div>
  190. </div>
  191. <div class="comment" typeof="schema:UserComments">
  192. <p class="comment-meta">
  193. <span class="comment-author" property="schema:creator">Eric</span> le <span class="comment-date" property="schema:commentTime">16/06/2009</span> :
  194. </p>
  195. <div class="comment-content" property="schema:commentText">
  196. <p>@Neomov:</p>
  197. <p>Le nom de domaine est le bon stade d&#39;indirection, mais il a effectivement des contraintes. Je crois réellement que 10 euros par an est abordable pour un internaute convaincu. Cela représente 3% des frais de connexion annuels habituels en France.</p>
  198. <p>Cela lui permet d&#39;avoir une adresse email et, une adresse de messagerie instantanée stables, sans être enfermée par un prestataire. Franchement ça concerne aussi Mme Michu.</p>
  199. <p>Combien de mme Michu ont eu à subir des désagréments importants parce qu&#39;elles ont utilisé l&#39;adresse email de leur FAI, ou un netcourrier quelconque, et qu&#39;elles ont du changer ensuite ? Contrairement aux geeks, prévenir tout le monde a été impossible à Mme Michu. Une adresse pérenne, si elle avait su, elle aurait peut être payé 5 à 10 euros par an.</p>
  200. <p>Maintenant :</p>
  201. <p>- Mme michu n&#39;est pas sur twitter, et encore moins sur identi.ca, donc c&#39;est plus à toi qu&#39;à elle que je m&#39;adressais</p>
  202. <p>- Plus bas je définis justement un mécanisme par indirection (passer par une page web quelconque) qui permet d&#39;éviter de forcément passer par son propre domaine (même si ça reste mieux). Le tout est de définir comment doit être faite la découverte.</p>
  203. <p>- le cas de Monique est spécial justement parce qu&#39;elle est dans les geeks, le domaine de mme michu, s&#39;il n&#39;est utilisé que pour ses mails et/ou son twitter-like, je doute qu&#39;il soit suffisamment intéressant pour être cybersquatté.</p>
  204. </div>
  205. </div>
  206. <div class="comment" typeof="schema:UserComments">
  207. <p class="comment-meta">
  208. <span class="comment-author" property="schema:creator">Neovov</span> le <span class="comment-date" property="schema:commentTime">16/06/2009</span> :
  209. </p>
  210. <div class="comment-content" property="schema:commentText">
  211. <p>Oui, ça marche pareil :)<br />Mais (j&#39;suis chiant, je sais), un NDD on le choisit et c&#39;est quand même assez limité… Un autre Larlet serait bien feinté et devrait prendre Larlet1olkthxbye…</p>
  212. </div>
  213. </div>
  214. <div class="comment" typeof="schema:UserComments">
  215. <p class="comment-meta">
  216. <span class="comment-author" property="schema:creator">Neovov</span> le <span class="comment-date" property="schema:commentTime">16/06/2009</span> :
  217. </p>
  218. <div class="comment-content" property="schema:commentText">
  219. <p>Mince, tu as posté en même temps que moi Éric.</p>
  220. <p>Je ne discute pas pour le prix, et je pense aussi que 10€ par an n&#39;est pas inabordable pour une personne convaincu.</p>
  221. <p>Justement, il faut convaincre :), et dans le cas d&#39;une madame Michu c&#39;est très dur (en fait je pense à ma mère, qui n&#39;a pas envie de s&#39;emmerder).</p>
  222. <p>C&#39;est un peu une conversation HS, puisque moi je suis convaincu. J&#39;imagine juste que nos usages se généraliseront plus tard…</p>
  223. </div>
  224. </div>
  225. <div class="comment" typeof="schema:UserComments">
  226. <p class="comment-meta">
  227. <span class="comment-author" property="schema:creator">Stéphane Deschamps</span> le <span class="comment-date" property="schema:commentTime">17/06/2009</span> :
  228. </p>
  229. <div class="comment-content" property="schema:commentText">
  230. <p>@Florent,</p>
  231. <p>Je ne suis pas sûr qu&#39;on soit obligé de cocher la case &quot;publier en CC&quot;. Je l&#39;ai cochée, mais je n&#39;ai pas tenté de créer de compte sans la cocher. Vous connaissez des gens qui ont essayé, les uns ou les autres...?</p>
  232. </div>
  233. </div>
  234. <div class="comment" typeof="schema:UserComments">
  235. <p class="comment-meta">
  236. <span class="comment-author" property="schema:creator">Stéphane Deschamps</span> le <span class="comment-date" property="schema:commentTime">17/06/2009</span> :
  237. </p>
  238. <div class="comment-content" property="schema:commentText">
  239. <p>@Neovov,</p>
  240. <p>Cela dit le FAI que je fréquente génère automatiquement l&#39;OpenID de ses clients. Exit, le problème de Madame Michu. Suffirait d&#39;une bonne page d&#39;aide pour lui expliquer en quoi c&#39;est son identité tant qu&#39;elle est chez ledit FAI. (réflexion jetée comme ça, mon cerveau est à 10% de ses capacités, je dis peut-être des bêtises, pardonnez-moi d&#39;avance)</p>
  241. </div>
  242. </div>
  243. <div class="comment" typeof="schema:UserComments">
  244. <p class="comment-meta">
  245. <span class="comment-author" property="schema:creator">Stéphane Deschamps</span> le <span class="comment-date" property="schema:commentTime">17/06/2009</span> :
  246. </p>
  247. <div class="comment-content" property="schema:commentText">
  248. <p>PS : et pour tout le reste je suis complètement d&#39;accord avec toutes les remarques d&#39;Éric, et je me pose la même question.</p>
  249. <p>Pour moi une balise méta comme le fait OpenID (les link rev=&quot;canonical&quot; sont un bon exemple, aussi) serait sans doute très bien : ce qui est très simple à implémenter est plus facilement adopté.</p>
  250. <p>(voilà, j&#39;arrête là ma salve de commentaires) :)</p>
  251. </div>
  252. </div>
  253. <div class="comment" typeof="schema:UserComments">
  254. <p class="comment-meta">
  255. <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">17/06/2009</span> :
  256. </p>
  257. <div class="comment-content" property="schema:commentText">
  258. <p>@Stéphane Deschamps : je ne le répèterais jamais assez mais je pense que les FAI et/ou les organismes publics ont un bon coup à jouer s&#39;ils réalisent rapidement le potentiel qu&#39;ils ont dans ce domaine. Tout est dans le &quot;rapidement&quot; qui est oxymorique dans ma phrase ;).</p>
  259. <p>Cela dit, le fait de perdre mon identité lorsque je change de FAI ne m&#39;emballe pas du tout. C&#39;est un peu comme la perte du numéro, ça devrait pas être possible... (hormis intentionnellement).</p>
  260. </div>
  261. </div>
  262. <div class="comment" typeof="schema:UserComments">
  263. <p class="comment-meta">
  264. <span class="comment-author" property="schema:creator">Stéphane Deschamps</span> le <span class="comment-date" property="schema:commentTime">17/06/2009</span> :
  265. </p>
  266. <div class="comment-content" property="schema:commentText">
  267. <p>David,</p>
  268. <p>En même temps plus j&#39;y pense et plus je me dis que là encore, Madame Michu change vachement moins souvent de FAI que nous autres déglingos.</p>
  269. <p>D&#39;ailleurs maintenant qu&#39;on en parle, même les geeks bougent beaucoup moins maintenant qu&#39;il y a dix ans.</p>
  270. <p>Mais pour le reste, je suis d&#39;accord. Evidemment on ne peut pas rêver de forwarding d&#39;openID, ce serait monstrueux à mettre en place et à maintenir, et encore plus dangereux sur les risques d&#39;usurpation.</p>
  271. </div>
  272. </div>
  273. <div class="comment" typeof="schema:UserComments">
  274. <p class="comment-meta">
  275. <span class="comment-author" property="schema:creator">Éric</span> le <span class="comment-date" property="schema:commentTime">18/06/2009</span> :
  276. </p>
  277. <div class="comment-content" property="schema:commentText">
  278. <p>J&#39;ai la même crainte qur David sur l&#39;enfermement par le FAI. Quitte à s&#39;enfermer chez un presta je préfère que ce soit google ou yahoo, parce que le risque de perte du compte est plus faible.</p>
  279. <p>On ne change pas souvent de FAI (quoique, définir &quot;pas souvent, desemmerdements liés au changement d&#39;email lors du changement de Fai j&#39;en ai vu plus d&#39;une fois chez des gens normaux, et au pire moment : pendant les déménagements, là où l&#39;email devrait être facteur de stabilité) mais c&#39;est plus un problème de contrainte ( changement d&#39;email, de numéro de tel, d&#39;habitudes, ...) que de manque de volonté. Ajouter l&#39;identité à l&#39;enfermement du FAI ne ferait qu&#39;empirer ces contraintes ( et quand il y en a trop on finit par ne plus vouloir s&#39;y confrnter mais ne transformons pas ça en succès)</p>
  280. <p>Je suis plutot de ceux qui conseillent de toujours creer un email indépendant du fai, toujours (et dans l&#39;ideal un openid indépendant du mail quand on n&#39;en controle pas l&#39;identifiant)</p>
  281. </div>
  282. </div>
  283. <div class="comment" typeof="schema:UserComments">
  284. <p class="comment-meta">
  285. <span class="comment-author" property="schema:creator">Ray</span> le <span class="comment-date" property="schema:commentTime">18/06/2009</span> :
  286. </p>
  287. <div class="comment-content" property="schema:commentText">
  288. <p>Bof, il faut arrêter de tout le temps aller vers le nouveau truc à la mode. La mode ça passe de toute manière alors autant avoir une boite perso fixe et éventuellement faire des redirections vers le dernier truc à la mode si on y tient vraiment. Sinon c&#39;est toujours la mer... et ça fait chi... tout le monde.</p>
  289. </div>
  290. </div>
  291. <div class="comment" typeof="schema:UserComments">
  292. <p class="comment-meta">
  293. <span class="comment-author" property="schema:creator">Grégoire</span> le <span class="comment-date" property="schema:commentTime">19/06/2009</span> :
  294. </p>
  295. <div class="comment-content" property="schema:commentText">
  296. <p>&quot;L&#39;expérience OpenID m&#39;incite à penser qu&#39;une balise ou &quot;</p>
  297. <p>Ou quoi? Il manque la deuxième possibilité.</p>
  298. </div>
  299. </div>
  300. <div class="comment" typeof="schema:UserComments">
  301. <p class="comment-meta">
  302. <span class="comment-author" property="schema:creator">Eric</span> le <span class="comment-date" property="schema:commentTime">19/06/2009</span> :
  303. </p>
  304. <div class="comment-content" property="schema:commentText">
  305. <p>Le &quot;ou&quot; est en trop, désolé pour la coquille.<br />David, tu peux faire la correction s&#39;il te plait ?</p>
  306. </div>
  307. </div>
  308. <div class="comment" typeof="schema:UserComments">
  309. <p class="comment-meta">
  310. <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">20/06/2009</span> :
  311. </p>
  312. <div class="comment-content" property="schema:commentText">
  313. <p>Oups, désolé j&#39;avais oublié d&#39;échapper les balises html... c&#39;est réparé.</p>
  314. </div>
  315. </div>
  316. <div class="comment" typeof="schema:UserComments">
  317. <p class="comment-meta">
  318. <span class="comment-author" property="schema:creator">tangi</span> le <span class="comment-date" property="schema:commentTime">24/06/2009</span> :
  319. </p>
  320. <div class="comment-content" property="schema:commentText">
  321. <p>Me voila surpris : je n&#39;avais pas remarqué ce grand mouvement vers laconica. J&#39;ai découvert cette application par hasard sur framasoft, juste avant de m&#39;empresser de l&#39;installer :)</p>
  322. <p>Je serais tendance à mon insu ?</p>
  323. <p>@Neovov : tu es obligé d&#39;accepter la licence pour créer un compte.</p>
  324. <p>L&#39;identité numérique est un vaste débat, mais (malheureusement), je crois que c&#39;est encore un débat de &quot;spécialiste&quot;. Le commun des mortel est vraiment à mille lieux de ce type de notions.</p>
  325. <p>D&#39;ailleurs on a pu le remarquer avec les &quot;url personnalisés&quot; de facebook : au finale une petite poignée d&#39;utilisateur à cédé à ce mécanisme, la grande majorité ne l&#39;ayant peut être même pas remarqué.</p>
  326. <p>Au finale la majorité des utilisateurs veulent du gratuit, n&#39;ont aucune idée des coût de fonctionnement de tels services, et aller payer déjà 1à€ pour un nom de domaine leur semble aberrant. C&#39;est un vrai travail d&#39;éducation.</p>
  327. <p>Alors de là à imaginer que la masse aille installer son petit serveur laconica (ou autre) sur un hébergement privatif pour sa petite famille, .... Se libérer pour mieux se concentrer en quelque sorte :)</p>
  328. <p>Pour finir, petite question purement technique : la procédure pour connecter mon compte identi.ca avec celui de mon laconica perso ? (mais au faite pourquoi quitter twitter, laconica permet de twitter via laconica de façon native ^^)</p>
  329. <p>Merci pour cet article en tout cas. bonne soirée</p>
  330. </div>
  331. </div>
  332. <div class="comment" typeof="schema:UserComments">
  333. <p class="comment-meta">
  334. <span class="comment-author" property="schema:creator">Clochix</span> le <span class="comment-date" property="schema:commentTime">14/08/2009</span> :
  335. </p>
  336. <div class="comment-content" property="schema:commentText">
  337. <p>Désolé de me réveiller beaucoup plus tard.</p>
  338. <p>Quitte à lier son identité à un nom de domaine, pourquoi ne pas aller plus loin et tout stocker dans l&#39;enregistrement DNS ? Les enregistrements SRV ( <a href="http://fr.wikipedia.org/wiki/Enregistrement_SRV">http://fr.wikipedia.org/wiki/Enregistrement_SRV</a> ) servent plus ou moins à ça. Ca supprime un intermédiaire, la page web. Et la plupart de registars ont déjà des interfaces plus ou moins ergonomiques pour gérer ses enregistrements, donc ça ne devrait pas être trop compliqué à administrer.</p>
  339. </div>
  340. </div>
  341. <div class="comment" typeof="schema:UserComments">
  342. <p class="comment-meta">
  343. <span class="comment-author" property="schema:creator">Eric</span> le <span class="comment-date" property="schema:commentTime">15/08/2009</span> :
  344. </p>
  345. <div class="comment-content" property="schema:commentText">
  346. <p>Ca impose aux gens d&#39;avoir un nom de domaine justement. L&#39;immense majorité des gens ont un email, une page web, mais pas de nom de domaine.</p>
  347. <p>L&#39;indirection par la page web c&#39;est l&#39;indirection du pauvre, ça ne tient que le temps que dure la page web, mais c&#39;est finalement assez efficace pour les besoins qu&#39;on a.</p>
  348. <p>(Par contre oui, pour ceux qui ont un nom de domaine, l&#39;indirection devrait être possible dans les DNS)</p>
  349. </div>
  350. </div>
  351. <div class="comment" typeof="schema:UserComments">
  352. <p class="comment-meta">
  353. <span class="comment-author" property="schema:creator">Lecteur assidu</span> le <span class="comment-date" property="schema:commentTime">20/08/2009</span> :
  354. </p>
  355. <div class="comment-content" property="schema:commentText">
  356. <p>Cela fait bien trop longtemps qu&#39;il n&#39;y a plus de billets sur ton blog. J&#39;espère qu&#39;il y&#39;en aura bientôt des nouveaux car c&#39;est toujours un plaisir d&#39;être informé par tes billets toujours très interessants.</p>
  357. </div>
  358. </div>
  359. <div class="comment" typeof="schema:UserComments">
  360. <p class="comment-meta">
  361. <span class="comment-author" property="schema:creator">Voiture occasion</span> le <span class="comment-date" property="schema:commentTime">23/09/2010</span> :
  362. </p>
  363. <div class="comment-content" property="schema:commentText">
  364. <p>Je ne connaissais pas Identi.ca (comme quoi on en découvre tous les jours !), mais je le trouve très intéressant à tout point de vue.</p>
  365. <p>Reste que comme vu dans l&#39;article, je suis déjà sur Twitter et j&#39;ai peur pour la migration avec mes contacts.</p>
  366. </div>
  367. </div>
  368. </div>
  369. </section>
  370. <footer>
  371. <nav>
  372. <p>
  373. <small>
  374. Je réponds quasiment toujours aux <a href="m&#x61;ilto:d&#x61;vid%40l&#x61;rlet&#46;fr" title="Envoyer un email">emails</a> (<a href="/david/signature/" title="Ma signature actuelle avec possibilité de chiffrement">signés</a>) et vous pouvez me rencontrer à Montréal. <span class="more-infos">N’hésitez pas à <a href="/david/log/" title="Être tenu informé des mises à jour">vous abonner</a> pour être tenu informé des publications récentes.</span>
  375. </small>
  376. </p>
  377. </nav>
  378. </footer>
  379. </div>
  380. <script src="/static/david/js/larlet-david-3ee43f.js" data-no-instant></script>
  381. <script data-no-instant>InstantClick.init()</script>
  382. </body>
  383. </html>