Repository with sources and generator of https://larlet.fr/david/ https://larlet.fr/david/
Nevar pievienot vairāk kā 25 tēmas Tēmai ir jāsākas ar burtu vai ciparu, tā var saturēt domu zīmes ('-') un var būt līdz 35 simboliem gara.

index.html 28KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355
  1. <!doctype html>
  2. <html lang=fr>
  3. <head>
  4. <!-- Always define the charset before the title -->
  5. <meta charset=utf-8>
  6. <title>★ Web social : rendez nous le contrôle de nos données ! — 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/20070906-web-social-rendez-nous-le-controle-de-nos-donnees">
  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">★ Web social : rendez nous le contrôle de nos données !</h1>
  42. <article typeof="schema:BlogPosting">
  43. <div property="schema:articleBody">
  44. <img src="/static/david/biologeek/images/logos/opensocialweb.png" alt="vignette" style="float:left; margin: 0.5em 1em;" property="schema:thumbnailUrl" />
  45. <p>J'ai lu avec intérêt la <a href="http://opensocialweb.org/2007/09/05/bill-of-rights/">Déclaration des Droits de l'Utilisateur 2.0</a> qui est une excellente idée mais il est vraiment dommage que la réflexion n'ait pas été portée un peu plus loin pour approcher davantage <a href="https://larlet.fr/david/biologeek/archives/20070131-reve-de-geek/">mon rêve de geek</a> qui se concrétise peu à peu avec l'avancée des technologies. Quelques pistes pour aller plus loin grâce aux outils actuels.</p>
  46. <h2>Déclaration des droits de l'utilisateur du Web Social</h2>
  47. <p>On commence par la <a href="http://opensocialweb.org/2007/09/05/bill-of-rights/">traduction de la déclaration</a>, rédigée par 4 personnes influentes du web 2.0&nbsp;:</p>
  48. <p>Nous affirmons publiquement que tous les utilisateurs du web social ont droit à certains droits fondamentaux, notamment&nbsp;:</p>
  49. <ul>
  50. <li><strong>la propriété</strong> de leur information personnelle, incluant&nbsp;:
  51. <ul>
  52. <li>les données de leur profil,</li>
  53. <li>la liste de personnes auxquelles elles sont liées,</li>
  54. <li>le flux d'activité du contenu créé&nbsp;;</li>
  55. </ul></li>
  56. <li><strong>le contrôle</strong> de la manière dont cette information personnelle est partagée avec autrui&nbsp;; et</li>
  57. <li><strong>la liberté</strong> d'autoriser les sites externes de confiance à accéder à ces données.</li>
  58. </ul>
  59. <p>Les sites en accord avec ces termes doivent&nbsp;:</p>
  60. <ul>
  61. <li>Permettre à leurs utilisateurs de syndiquer les données de leur profil, leur liste d'amis, et les données qui sont partagées avec elles par l'intermédiaire du service, en utilisant une URL persistante ou une API ainsi que des formats ouverts&nbsp;;</li>
  62. <li>Permettre à leurs utilisateurs de syndiquer leur flux d'activité en dehors du site&nbsp;;</li>
  63. <li>Permettre à leurs utilisateurs de lier leur page de profil à des ressources externes de manière publique&nbsp;; et</li>
  64. <li>Permettre à leurs utilisateurs de découvrir les connaissances qui sont présentes sur ce site, utilisant les mêmes ressources externes que celles utilisables pour accéder au service.</li>
  65. </ul>
  66. <p>En résumé, et l'<a href="http://www.stoweboyd.com/message/2007/09/the-architectur.html">analyse de Stowe Boyd</a> est pertinente là-dessus, <strong>tant qu'il y a une position de monopole dans le web 2.0 tout va bien car l'information est centralisée mais dès qu'il s'agit de rendre les applications interopérables (ce qui n'est pas forcément dans l'intérêt de tous) c'est beaucoup plus difficile</strong>. Jusqu'ici tout allait bien mais même les early-adopters commencent à se lasser de devoir ajouter leur liste d'amis à chaque nouveau service... alors imaginez le grand public.</p>
  67. <p>En revanche, je ne suis pas d'accord avec le fait qu'il faille rendre les applications interopérables entre elles et les graphiques proposés dans l'analyse sont pour moi voués à l'échec car <strong>l'utilisateur devrait être au centre de l'architecture, nous sommes les données après tout</strong>&nbsp;! Explications.</p>
  68. <h2>Notre identité numérique comme <a href="http://fr.wikipedia.org/wiki/Entrep%C3%B4t_de_donn%C3%A9es">datawarehouse</a> grâce au Web Sémantique</h2>
  69. <p>Prenons un exemple simple pour la suite. Considérons justement la liste d'amis qu'il faut partager entre les différents services web sociaux. L'idéal pour l'utilisateur serait de n'avoir à la définir qu'une seule fois et que les modifications (et oui les relations évoluent très vite) soient prises en comptes par chacune des applications aussi.</p>
  70. <p>Pour cela il faut un endroit unique où définir sa liste d'amis et c'est là qu'intervient <a href="https://larlet.fr/david/biologeek/archives/20070104-comment-utiliser-openid-la-solution-d-identification-tant-attendue/">OpenID</a> qui est ce que nous voulons&nbsp;: <strong>une clé unique sur le web, une URL</strong>. Encore mieux, cet identifiant fourni à l'application tierce va vous permettre de vous identifier sans avoir à remplir un n-ième formulaire vous demandant vos nom(s), prénom(s), etc. <strong>L'utilisateur est gagnant</strong>.</p>
  71. <p>L'avantage c'est que vous avez maintenant le contrôle de vos données car celles-ci sont récupérées et synchronisées régulièrement à partir de votre espace. <strong>Les services web deviennent des agrégateurs de votre contenu, sur lequel vous avez un contrôle total</strong>. Si l'on reprend l'exemple des amis, il suffit que vous placiez un fichier <abbr title="Friend Of A Friend">FOAF</abbr> sur la page pointée par votre OpenID et le service peut collecter ces relations immédiatement et régulièrement pour être toujours à jour.</p>
  72. <p>Nous avions une discussion très similaire avec <a href="http://lacot.org/">Xavier</a> il y a de cela un an (!) <strong>au sujet des commentaires des blogs</strong>. Ceux-ci devraient être rédigés et stockés sur votre espace personnel car ce sont vos données que vous devriez être libre de modifier à tout moment. Ils seraient ensuite liés aux blogs qui agrégeraient les commentaires des différentes personnes ayant réagi à cet article, c'est un peu ce que l'on retrouve en partie avec les trackbacks par exemple.</p>
  73. <h2>Que manque-t-il pour avancer&nbsp;?</h2>
  74. <p><strong>OpenID doit devenir plus mature</strong> pour faire face notamment aux <a href="https://larlet.fr/david/biologeek/archives/20070109-openid-et-phishing-sont-dans-un-bateau/">problèmes de phishing</a> mais c'est en bonne voie, je ne me fais pas trop de soucis de ce côté là.</p>
  75. <p><strong>Des applications doivent être créées pour faciliter la construction de ces datawarehouse personnels</strong>, l'absence de tels outils conviviaux est un réel frein à cette migration. Il y a un marché inexploité de ce côté là et le premier à se lancer là-dedans aura une avance significative sur ses concurrents...</p>
  76. <p>Enfin, <strong>les services web de nouvelle génération doivent adopter une telle approche</strong> mais comme dans toute migration c'est un peu le serpent qui se mord la queue car personne ne souhaite faire ce pas tant qu'il n'y aura pas un nombre important d'utilisateurs qui sont prêts à le faire et les utilisateurs attendent d'avoir des applications prêtes pour adopter cette nouvelle architecture.</p>
  77. <p><strong>Le Web de demain est en marche et c'est motivant.</strong></p>
  78. <p><strong>[edit]</strong>&nbsp;: lien hautement intéressant à ce sujet <a href="http://bradfitz.com/social-graph-problem/">Thoughts on the Social Graph</a> et comme souvent <a href="http://django-psn.googlecode.com/svn/trunk/readme.html">ça bouge rapidement autour de Django</a> :-).</p>
  79. <p><strong>[edit du 9]</strong>&nbsp;: présentation de Simon Willison intitulée <a href="http://www.slideshare.net/simon/building-the-social-web-with-openid/">Building the Social Web with OpenID</a>, ça ne va pas aussi loin mais c'est intéressant.</p>
  80. <p><strong>[edit du 10]</strong>&nbsp;: une autre présentation <a href="http://www.slideshare.net/huw/open-social-networking">Open Social Networking</a> qui reprend exactement l'idée de ce billet (c'est assez hallucinant d'ailleurs !), trouvée sur la liste de diffusion de <a href="http://groups.google.com/group/social-network-portability">Social Network Portability</a> avec le sujet <a href="http://groups.google.com/group/social-network-portability/browse_thread/thread/73a63e318cff5097/b42af11616eb3291">A possible approach?</a> (les réponses sont intéressantes aussi).</p>
  81. <p><strong>[edit du 13]</strong>&nbsp;: <a href="http://danbri.org/words/2007/09/13/194">“The World is now closed”</a>, brillante réflexion sur la décentralisation des données, la notion d'amis et sur l'intérêt des applications web dans ces relations.</p>
  82. <p><strong>[edit du 21]</strong>&nbsp;: ça bouge du côté de Six Apart qui propose d'<a href="http://www.sixapart.com/about/news/2007/09/were_opening_th.html">ouvrir le graphe social</a>. À noter aussi l'initiative <a href="http://openfriendformat.com/">OpenFriend</a> qui planche là-dessus.</p>
  83. </div>
  84. </article>
  85. <footer>
  86. <h6 property="schema:datePublished">— 06/09/2007</h6>
  87. </footer>
  88. </section>
  89. <section>
  90. <div>
  91. <h3>Articles peut-être en rapport</h3>
  92. <ul>
  93. <li><a href="/david/biologeek/archives/20110328-les-outils-manquants-opendata/" title="Accès à Les outils manquants de l&#39;OpenData">Les outils manquants de l&#39;OpenData</a></li>
  94. <li><a href="/david/biologeek/archives/20080604-architecture-web-moderne-et-agile/" title="Accès à ★ Architecture web moderne et agile">★ Architecture web moderne et agile</a></li>
  95. <li><a href="/david/biologeek/archives/20070415-perennite-et-stockage-des-liens/" title="Accès à Pérennité et stockage des liens">Pérennité et stockage des liens</a></li>
  96. </ul>
  97. </div>
  98. </section>
  99. <section>
  100. <div id="comments">
  101. <h3>Commentaires</h3>
  102. <div class="comment" typeof="schema:UserComments">
  103. <p class="comment-meta">
  104. <span class="comment-author" property="schema:creator">NiCoS</span> le <span class="comment-date" property="schema:commentTime">06/09/2007</span> :
  105. </p>
  106. <div class="comment-content" property="schema:commentText">
  107. <p>Marrant, j'étais en train d'avoir la même réflexion depuis qqs jours dans le train en partant du constat que ça me génait pas trop de mettre mes données sur Flickr/Dailymotion dans la mesure où c'est une copie de mes données perso, alors que pour del.icio.us, si le service meurt, mes bookmarks aussi et ça ça me plait pas/plus (je fais des exports mais pas très régulièrement).<br />
  108. <br />
  109. Maintenant reste à voir comment tout ça va être implémenté mais c'est clair que ça va dans le bon sens !</p>
  110. </div>
  111. </div>
  112. <div class="comment" typeof="schema:UserComments">
  113. <p class="comment-meta">
  114. <span class="comment-author" property="schema:creator">Nicofrand</span> le <span class="comment-date" property="schema:commentTime">06/09/2007</span> :
  115. </p>
  116. <div class="comment-content" property="schema:commentText">
  117. <p>Pour les listes d'amis &quot;universelles&quot; ( pour simplifier ), j'avoue avoir peur quelque peu du résultat auquel ca pourrait nous mener ( spam de leurs adresses etc ). Cependant, pour les adeptes de ces services ( ex: hi5 ) fouillant vos comptes de messagerie instantanée, il faut en effet trouver une solution fiable, qui permette de sentir que l'on est en sécurité, que nos comptes ne seront pas fouillés, ou pire que nous ne risquons aucune perte ( ex: certaines copies de ces sites qui vous demandent également votre mot de passe ).<br />
  118. OpenID a encore du chemin à parcourir mais je pense également qu'il est en bonne voie, notamment grâce aux blogs je pense ( les articles concernant le sujet pullulent sur la blogosphère ) mais son expansion se trouve encore limité, d'une part par le risque de phishing, et d'autre part par la difficulté de le mettre en place ( ex: sur les blogs dotclear il n'est pas évident de trouver une authentification via OpenID pour les commentaires ) .</p>
  119. </div>
  120. </div>
  121. <div class="comment" typeof="schema:UserComments">
  122. <p class="comment-meta">
  123. <span class="comment-author" property="schema:creator">Olivier G.</span> le <span class="comment-date" property="schema:commentTime">06/09/2007</span> :
  124. </p>
  125. <div class="comment-content" property="schema:commentText">
  126. <p>&quot;(spam de leurs adresses etc )&quot; : mais pourquoi publier leur adresse ? Tu n'a besoin à la limite que d'un lien vers leur propre description RDF (par exemple). De plus, FOAF a une proriété MBoxSha1 (de mémoire), qui permet d'associer le hash d'une adresse email à une personne, ce qui permet de l'identifier de manière unique tout en ne publiant pas son adresse mail...</p>
  127. </div>
  128. </div>
  129. <div class="comment" typeof="schema:UserComments">
  130. <p class="comment-meta">
  131. <span class="comment-author" property="schema:creator">Neovov</span> le <span class="comment-date" property="schema:commentTime">07/09/2007</span> :
  132. </p>
  133. <div class="comment-content" property="schema:commentText">
  134. <p>Marrant, j'en parlais il y a quelque jours avec un ami.<br />
  135. <br />
  136. C'est un sujet très délicat, car la centralisation des données crée toujours un plus gros risque de perte. Qu'on perde son compte Flickr c'est pas trop grave, mais perdre d'un seul coup Flickr, del.icio.us, Facebook, Ziki, les commentaires qu'on a pu mettre sur des blogs... Ca serait dramatique.<br />
  137. <br />
  138. En plus en ce qui concerne les commentaires des blogs, ça ferait des requêtes externes en plus des tonnes de widgets que l'on peut trouver et qui ralentissent l'affichage des pages (je le sais, j'ai une connexion pourrie).<br />
  139. <br />
  140. Même avec ça je sais que c'est très très prometteur, et j'ai vraiment hâte d'avoir un système fiable de centralisation de mon contenu personnel.<br />
  141. <br />
  142. (note de dernière minute : on sera peut-être plus sujet à la censure, si les autorités de OpenID ou autre décident de couper notre compte pour X raisons...)</p>
  143. </div>
  144. </div>
  145. <div class="comment" typeof="schema:UserComments">
  146. <p class="comment-meta">
  147. <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">07/09/2007</span> :
  148. </p>
  149. <div class="comment-content" property="schema:commentText">
  150. <p>@Nicofrand : Olivier G. t'as bien répondu (merci ;-))<br />
  151. <br />
  152. @Neovov : <br />
  153. <br />
  154. &gt; C'est un sujet très délicat, car la centralisation des données crée toujours un plus gros risque de perte.<br />
  155. <br />
  156. Ok, mais tu c'est marrant car tu fais davantage confiance à un service tiers qu'à ton propre choix sur la question. Il ne faut pas croire que les grosses applis super connues ont davantage de redondance et donc que l'on est certain de ne rien perdre (tu serais surpris de voir ce qu'il se trame parfois en coulisses...).<br />
  157. <br />
  158. &gt; Qu'on perde son compte Flickr c'est pas trop grave, mais perdre d'un seul coup Flickr, del.icio.us, Facebook, Ziki, les commentaires qu'on a pu mettre sur des blogs... Ca serait dramatique.<br />
  159. <br />
  160. Euh, à partir du moment où tu perds des données c'est grave. Et ceux qui mettent toutes leurs photos sur FlickR ou autre sans sauvegarde sont des inconscients.<br />
  161. <br />
  162. &gt; En plus en ce qui concerne les commentaires des blogs, ça ferait des requêtes externes<br />
  163. <br />
  164. Il y a des choses à creuser à ce niveau là, mais avec des crawlers et du cache déjà ça serait suffisant à mon avis.<br />
  165. <br />
  166. &gt; on sera peut-être plus sujet à la censure, si les autorités de OpenID ou autre décident de couper notre compte pour X raisons...<br />
  167. <br />
  168. OpenID est un système décentralisé et tu peux même créer ton propre serveur donc la censure n'est pas possible, sans compter qu'il n'y aurait rien à censurer, OpenID ne servirait ici que de porte d'entrée.</p>
  169. </div>
  170. </div>
  171. <div class="comment" typeof="schema:UserComments">
  172. <p class="comment-meta">
  173. <span class="comment-author" property="schema:creator">Nicofrand</span> le <span class="comment-date" property="schema:commentTime">09/09/2007</span> :
  174. </p>
  175. <div class="comment-content" property="schema:commentText">
  176. <p>@Olivier G.<br />
  177. &gt;Merci de ta réponse ! Oui c'est vrai en effet... Quand à la propriété de FOAF, je ne connaissais pas intéressant !</p>
  178. </div>
  179. </div>
  180. <div class="comment" typeof="schema:UserComments">
  181. <p class="comment-meta">
  182. <span class="comment-author" property="schema:creator">Xethorn</span> le <span class="comment-date" property="schema:commentTime">12/09/2007</span> :
  183. </p>
  184. <div class="comment-content" property="schema:commentText">
  185. <p>Il serait pratique que ce genre de système ne s'applique, par base de principe, pas qu'au web mais également dans la vie courante. Si la base réelle était déjà existante, elle s'appliquerait partout à commencer par le web.<br />
  186. <br />
  187. <a href="http://silent-strength.com/?carnet/billet/138-Papiers-perdus" title="http://silent-strength.com/?carnet/billet/138-Papiers-perdus" rel="nofollow">silent-strength.com/?carn...</a></p>
  188. </div>
  189. </div>
  190. <div class="comment" typeof="schema:UserComments">
  191. <p class="comment-meta">
  192. <span class="comment-author" property="schema:creator">giz404</span> le <span class="comment-date" property="schema:commentTime">13/09/2007</span> :
  193. </p>
  194. <div class="comment-content" property="schema:commentText">
  195. <p>J'avais déjà pensé de mon côté me créer une sorte de page &quot;méta-profil&quot; en utilisant comme source de données des flux RSS ou des API de tous services &quot;Web2.0&quot; que j'utilise... Mais ça n'a jamais vu le jour, et c'était plus du bricolage qu'autre chose. <br />
  196. C'est agréable de voir que des personnes se soucient de ce problème à plus grande échelle.</p>
  197. </div>
  198. </div>
  199. <div class="comment" typeof="schema:UserComments">
  200. <p class="comment-meta">
  201. <span class="comment-author" property="schema:creator">Julien</span> le <span class="comment-date" property="schema:commentTime">18/09/2007</span> :
  202. </p>
  203. <div class="comment-content" property="schema:commentText">
  204. <p>Vaste débat que l'Open ID. Mais je ne crois pas que cela pourra aller bien loin à l'heure actuelle. Il faut en effet prendre en compte les problématiques de vie privée et légaux liés à chaque pays (il est clair qu'un site de confiance chinois ce n'est pas la même chose qu'un site de confiance québécois.</p>
  205. </div>
  206. </div>
  207. <div class="comment" typeof="schema:UserComments">
  208. <p class="comment-meta">
  209. <span class="comment-author" property="schema:creator">speedyop</span> le <span class="comment-date" property="schema:commentTime">19/09/2007</span> :
  210. </p>
  211. <div class="comment-content" property="schema:commentText">
  212. <p>une question que je me pose est comment contrôler ses données éparpillées sur la toile sans une centralisation? <br />
  213. <br />
  214. l'agrégation et les API nous permettent de lire et parfois contrôler le contenu hébergé a distance, mais je n'arrive pas encore a concevoir la structure que prendrais un regroupement décentralisé...</p>
  215. </div>
  216. </div>
  217. <div class="comment" typeof="schema:UserComments">
  218. <p class="comment-meta">
  219. <span class="comment-author" property="schema:creator">Un Electron Libre...</span> le <span class="comment-date" property="schema:commentTime">12/10/2007</span> :
  220. </p>
  221. <div class="comment-content" property="schema:commentText">
  222. <!-- TB -->
  223. <p><strong>Ces données que l'on aime tant...</strong></p>
  224. <p>Une des facettes du Web 2.0 est la capacité pour tout utilisateur de partager des données et en retour de profiter des données partagées par les autres. Pour autant, un point me gène particulièrement, c'est le contrôle que je peux avoir sur les...</p>
  225. </div>
  226. </div>
  227. <div class="comment" typeof="schema:UserComments">
  228. <p class="comment-meta">
  229. <span class="comment-author" property="schema:creator">Mitch</span> le <span class="comment-date" property="schema:commentTime">13/11/2007</span> :
  230. </p>
  231. <div class="comment-content" property="schema:commentText">
  232. <p>Ce sujet est on ne peut plus d'actualité, avec pour illustre exemple, l'ouverture de facebook aux entreprises. 50 millions de comptes ouverts, voilà un véritable mine d'informations personnelles au profit des publicités ciblées.<br />
  233. Pourvu que la réflexion perdure, et puissions nous trouver, nous, utilisateurs du web 2.0 un équilibre entre la valeur ajoutée de ces services, les modèles économiques proposés et l'intégrité de nos données.</p>
  234. </div>
  235. </div>
  236. <div class="comment" typeof="schema:UserComments">
  237. <p class="comment-meta">
  238. <span class="comment-author" property="schema:creator">Philippe</span> le <span class="comment-date" property="schema:commentTime">23/11/2007</span> :
  239. </p>
  240. <div class="comment-content" property="schema:commentText">
  241. <p>Superbe !<br />
  242. <br />
  243. Je viens de découvrir ce blog et j'y retrouve parfaitement exprimée ce que je commencais à entrevoir.<br />
  244. <br />
  245. En tant que nouveau sur la blogosphère (moins d'un an) j'en suis donc au niveau 0 de la réflexion et ce billet me renforce dans mon idée que l'avenir est à la décentralisation.<br />
  246. <br />
  247. Facebook, Google maintenant sont désormais les portes drapeaux du libéralisme débridé qui sévit dans le monde réel. <br />
  248. <br />
  249. A l'instat de l'open source qui a mis à bas les monopoles logiciels, il est temps de concevoir une réelle alternative et sourtout à la rendre accessible à tous le monde. Car c'est la grande force des solutions actuellement &quot;offertes&quot; par Google facebook et consors.</p>
  250. </div>
  251. </div>
  252. <div class="comment" typeof="schema:UserComments">
  253. <p class="comment-meta">
  254. <span class="comment-author" property="schema:creator">Lise</span> le <span class="comment-date" property="schema:commentTime">14/01/2008</span> :
  255. </p>
  256. <div class="comment-content" property="schema:commentText">
  257. <p>bonjour, je suis étudiante et travaille actuellement sur un sujet dont le thème est le web social. J'aurais aimé savoir si quelqu'un pouvait me dire quels sont les enjeux et les dangers du web social.<br />
  258. <br />
  259. Merci d'avance</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">Papa</span> le <span class="comment-date" property="schema:commentTime">24/01/2008</span> :
  265. </p>
  266. <div class="comment-content" property="schema:commentText">
  267. <p>&quot;ce qui n'est pas forcement dans l'interet de tous&quot; ... point de détail très ilmportant ;) merci pour ce illet ! continue !</p>
  268. </div>
  269. </div>
  270. <div class="comment" typeof="schema:UserComments">
  271. <p class="comment-meta">
  272. <span class="comment-author" property="schema:creator">Rumeurs du Net</span> le <span class="comment-date" property="schema:commentTime">15/02/2008</span> :
  273. </p>
  274. <div class="comment-content" property="schema:commentText">
  275. <p>hello ! &quot;ce qui n'est pas forcement dans l'interet de tous&quot; : c ertaines parenthèses en disent + quetout le reste :) mercci pour ton billet ! toujours un plaisi de te lire.</p>
  276. </div>
  277. </div>
  278. <div class="comment" typeof="schema:UserComments">
  279. <p class="comment-meta">
  280. <span class="comment-author" property="schema:creator">esion</span> le <span class="comment-date" property="schema:commentTime">30/05/2008</span> :
  281. </p>
  282. <div class="comment-content" property="schema:commentText">
  283. <p>Ce qui me gène dans tout cela c&#39;est l&#39;organisation que l&#39;on fait de nos données (les personnes auxquelles nous sommes liés via les réseaux sociaux).</p>
  284. <p>On prend prendre cet exemple (simpliste je l&#39;accorde) : J&#39;organise mes contacts en divisant groupe de travail et groupe d&#39;amis. Je ne désire pas que mes contacts de travail sachent qui sont mes amis. Avec Facebook seul on pourrait imaginer une fonctionnalité qui permette cette restriction. <br />En utilisant openID et un fichier FOAF, comment pourrait-on indiquer à Facebook l&#39;organisation de mes contacts et comment les traiter?</p>
  285. <p>Imaginons ensuite que je ne me serve de Facebook que pour le travail et Myspace (hahahaha) pour les potes. À quel niveau se ferait les restrictions escomptées? Au niveau du service incriminé, au niveau de openID ou encore sur le FOAF?</p>
  286. <p>Ce qui est dérangeant (aujourd&#39;hui déjà) c&#39;est que ces services aient accès à toutes les données. Et le seul moyen qui fonctionne et fonctionnera serait d&#39;avoir deux identités distincts (deux identifiants, deux adresses email etc.) chose que l&#39;on tend à éviter par soucis simplicité et de cohérence.</p>
  287. </div>
  288. </div>
  289. <div class="comment" typeof="schema:UserComments">
  290. <p class="comment-meta">
  291. <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">31/05/2008</span> :
  292. </p>
  293. <div class="comment-content" property="schema:commentText">
  294. <p>@esion : comme je l&#39;expliquais dans le billet sur RDF et RDFa, la confidentialité des données sémantisées est encore un point assez critique. Néanmoins des protocoles comme OAuth sont faits pour ça (même s&#39;ils sont encore un peu complexes) et permettraient par exemple de limiter l&#39;accès de certaines données à certains utilisateurs/amis/famille/etc.</p>
  295. <p>Le but final n&#39;est pas du tout d&#39;avoir toutes les informations publiques mais bien de pouvoir gérer finement ces accès. Il y a encore du travail mais les personas d&#39;OpenID en sont un bon exemple.</p>
  296. </div>
  297. </div>
  298. </div>
  299. </section>
  300. <footer>
  301. <nav>
  302. <p>
  303. <small>
  304. 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>
  305. </small>
  306. </p>
  307. </nav>
  308. </footer>
  309. </div>
  310. <script src="/static/david/js/larlet-david-3ee43f.js" data-no-instant></script>
  311. <script data-no-instant>InstantClick.init()</script>
  312. </body>
  313. </html>