@Caletlog Ça donne quand même l'impression d'un système de tracking, de surveillance. Alors okay, ma grand mère tient un journal dans lequel elle note tout sur tout, mais c'est pas **fiché** par personne, et c'est trop exhaustif pour y retrouver rapidement des détails.

Alors okay, rien n'empêche (et n'empêchera) quiconque de tenir une liste de ce type, mais ça reste peut-être une « atteinte » au droit à l'oubli. Comme tu le souligne, y'a un certain nombre de faits qu'on oublie, et c'est aussi ça qui permet aux individus de ne pas être fichés définitivement. L'oubli, ça peut être vu comme une forme naturelle de tolérance sur des erreurs passées.

Malgré ces belles paroles, ce serait stupide de chercher à encadrer ça (typiquement les lois ridicules sur le droit à l'oubli). L'évolution humaine n'a que faire des lois, et c'est tant mieux comme ça.

C'est juste des notions à prendre en compte dans la conception, par exemple en datant les « événements » et en mettant en évidence uniquement les plus récents (ce qui même en dehors de ces considérations semble plutôt logique après tout).

Et puis moi, tu sais, n'y connaissant pas grand chose, je ferais un report de bug quoi... Je suis le Windows user de Linux ici (faut pas trop m'en demander non plus, je suis débrouillard mais pas beaucoup)

Dans le cas de Runny, j'aurai fait plus ou moins la même chose que lui sur ce coup et j'ai pas honte de le dire

« Le kernel Linux a cessé de fonctionner — Envoyer unrapport d'erreur à Linus Torvalds — Ne pas envoyer. »

M'enfin bon dans tout ce que j'ai dis tu n'as répondu qu'aux semblants de provocations quand même

Moi je veux juste que tu me donnes de quoi justifier ton comportement autre que je fé cke jveu lol histoire que tu remarques quand même à quel point c'est absurde

D'ailleurs tu n'as pas répondu à G_B qui lui n'a rien posté de quoi pouvant heurter ta sensibilité

Mais clairement, vava, ça ressemble à ça
Bah de toute façon, on le sait maintenant, ça fait très longtemps que je suis ici... Mais j'avance pas vite quoi

dmesg | mail -s 'Bug' "$(echo 'torvalds AT linux-foundation.org' | sed 's/ AT /@/')"

(dmesg; echo 'Deal with it.') | mail ...

En attendant je me trimballe un Firefox 24 ( fork de Palemoon ) et pourtant je suis sous Archlinux

liquidus Souhaiter un anniversaire sur facebook c'est assez pathétique - à moins de pas trop avoir le choix mais généralement c'est pas le cas -, chose que je ne fais jamais . Je n'affiche pas mon anniversaire non plus, d'ailleurs, histoire qu'on me fasse pas chier et qu'on me demande pas de le souhaiter aux autres. Et que j'ai pas à remercier vingt mille personnes qui m'offrent pas de cadeaux .

@vava > oui, j'avais ces considérations en tête. Par contre, je pars du principe que je fournis une 'interface' moderne et efficiente à une pratique que les gens font (ou ne font pas) déjà. Pas de notion de connexions entre les comptes, de surveillance, etc...
Ce qui m'embêtait plus, même dans le cas d'un environnement totalement fermé (comprendre, un 'carnet' de ce style appartient et n'est accessible qu'à son propriétaire, pas de partage proposé) et d'une garantie de non-utilisation des données (code source libre (plus ou moins obligé si je le présente à un jury en plus)), c'est le problème de sécurité inhérent. Le fait de stocker des informations nominatives de ce genre ferait plutôt froid dans le dos : que se passe-t-il si la base est volée ou un compte piraté ? Non seulement on a des infos sur les personnes enregistrées, mais aussi de ce que chaque membre pense de ses contacts.

Alors que, parallèlement, avoir des infos sur les relations qu'on entretient avec '$kkdaédnja$dfke' ou 'Bambi' ne poserait plus aucun problème : avoir des infos sur quelqu'un ne présente aucun risque (et n'a aucune valeur) si on ne peut pas reconnaître formellement ce quelqu'un.
Du coup, j'implémente une dissociation des données qui permettent d'identifier un contact de celles qui ne le permettent pas, sans stocker tous les outils qui permettent d'y accéder. Seul le propriétaire d'un compte peut mettre un nom sur ses contacts, et pas quelqu'un qui posséderait la base de données ou un compte volé.

Petit aparté, pour moi la notion de droit à l'oubli ne doit s'appliquer qu'à des entités ou des institutions (dans sa partie 'cible'). Stocker physiquement des informations nominatives, à partir du moment où elles restent accessibles seulement à leur propriétaire, est semblable à notre vraie mémoire. Que je retienne tous les incidents d'une personne pendant 60 ans ou les écrive dans un journal, c'est foncièrement la même chose. La seconde option a au moins l'avantage d'écarter les imperfections de la mémoire et, dans un autre registre, de nos jugements.

Caletlog :> Non, je ne fais pas de liste parce que j'ai une mémoire absolue (ment sélective, c'est à dire que je me souviens de tout ce qui me concerne et qui ne me fait pas trop chier).

+ Il est temps de songer à un nettoyage de début de vacances là.

Beh oui je réponds pas à ce qui est pertinant car j'estime qu'il n'y à rien à rajouter. Ce que j'essaie de faire comprendre c'est que c'est pas parce que je ne suis pas d'accord avec vous que je ne prend pas en compte votre avis, au contraire. Je sais très bien que Arch t'es pas obligé d'update souvent, mais je préfère. Si tu veux, je vais avancer un argument personnel valable :

J'ai une mauvaise connexion internet. Non seulement je ne télécharge pas vite, mais en plus, si je télécharge, une grosse partie de ma bande passante est monopolisée et je ne peux pas faire grand chose d'autre car la moindre page internet se charge très lentement en plus de ralentir les téléchargement en cours.

Je préfère donc doser par petites updates fréquentes de 15Mo qui durent deux minutes plutôt que des updates plus éspacées qui font 200Mo et qui mettront une demi-heure à télécharger.

De plus, il est plus facile de contrôler ce qui est mis a jour quand il y a 12 paquets à télécharger que 184, par éxemple.

Je ne souhaite pas downgrader car j'ai imprimé dans ma tête que plus un paquet est récent, mieux seront ses performances (et c'est apparemment le cas pour le kernel 3.16), et encore l'histoire du fait que je préfère régler concrètement un problème.

Je n'ai jamais prétendu que j'utilisais Arch mieux que les autres ni même que je l'utilisais de manière correcte. Et j'estime que si je n'ai pas à décider qu'une manière de penser/d'utiliser un soft/whatever est meilleure qu'une autre, ce n'est pas non plus ton rôle, et coller des étiquettes de "nobrain", "fragile", "hipster", "mal-pensant" ou "Jean-Linux" (ui ne veux strictement rien dire, soyons honnêtes) l'est encore moins. Et tu combines ça avec une attitude désagréable et hautaine, à la limite de l'irrespectueux, et c'est pas comme ça que tu vas convaincre ton interlocuteur de faire comme toi.

Donc, je le répète : j'utilise Arch de la façon qui me semble ADAPTÉE, et en aucun cas pour me la péter d'avoir tout le temps mes softs à jour.

Les autres, je suis vraiment désolé de la mauvaise ambiance que je suis en train de foutre. J'estime maintenant que je n'ai plus rien à ajouter donc je vais pas continuer là dessus.

Correction j'ai 1G à DL mais y a sage-mathematics qui fait ~500mo donc ça s'équivaut

@Caletlog https://www.jeuxvideo.com/forums/1-38-7665853-2082-0-1-0-0.htm#message_7818572

« et d'une garantie de non-utilisation des données »

Non. Pour tout service hébergé, t'as aucune garantie, t'as juste confiance. Même si le code est libre, si c'est pas toi qui l'héberges, ça n'a aucune valeur en terme de sécurité et de garanties.

Sauf que ça aujourd'hui y'a peu de gens à l'avoir compris. Autant, rien ne t'empêche de fournir une application centralisée qui contient des données confidentielles, mais une société un minimum éduquée sur le numérique refuserait majoritairement de l'utiliser pour les raisons évoquées plus haut. Actuellement, y'a une foule de gens qui pourraient utiliser inconsciemment ton application et qui te tiendront pour responsable (à juste titre) le jour où une faille permettant de dévoiler des données est trouvée sur ton site (et comme je sens que tu vas faire ça en Ruby, avec Rails, y'a de fortes chances qua la faille en question ne viennent même pas de ton code ).

À ta place je prendrais pas ce risque. Une application web qui manipule des données sensibles, ça peut t'anéantir si tes utilisateurs s'en prennent à toi en cas de problème (et ça arrivera, sois-en sûr). Au lieu de ça, tu fournis juste un logiciel libre que les gens installent chez-eux (ou sur leur serveur si besoin d'accéder à distance à la liste). « The software is provided "as is", without warranty of any kind. » Avec ça tu dors sur tes deux oreilles.

Si quelqu'un veut prendre la responsabilité de proposer d'utiliser cette application sur **son** serveur pour des raisons pratiques pour les utilisateurs (à savoir ne pas avoir à héberger le soft soi-même), tout en offrant des garanties techniquement intenables à ses utilisateurs, c'est **son** problème.

« Du coup, j'implémente une dissociation des données qui permettent d'identifier un contact de celles qui ne le permettent pas, sans stocker tous les outils qui permettent d'y accéder. Seul le propriétaire d'un compte peut mettre un nom sur ses contacts, et pas quelqu'un qui posséderait la base de données ou un compte volé. »

Tu m'expliques ça techniquement ?

La seule solution un peu moins trouée que les autres que je vois pour l'instant (dans le cas d'une application web), c'est de chiffrer les données avec une clé connue uniquement de l'utilisateur (générée côté client à la création du compte), qui est systématiquement passée en ancre dans l'URL (comme ça pas envoyée au serveur). Ton serveur proposerait alors juste une API pour lire/écrire des blobs, chiffrés et déchiffrés côté client grâce à la clé présente dans l'ancre. À partir du moment où tu rends l'utilisateur responsable de sa clé, si il se la fait piquer c'est son problème, et toi tu possèdes juste des données non exploitable. Une faille majeure de cette architecture reste l'exécution de JavaScript indésirable côté client (typiquement, si un attaquant gagne un accès à ton système de fichiers et modifie/ajoute des scripts), auquel cas tu serais également tenu responsable.

@vava > "Tu m'expliques ça techniquement ? "
C'est exactement ce que tu développe en dessous, j'avais en tête un chiffrement des données nominatives avec une clé par utilisateur, non stockée sur le serveur.

"et comme je sens que tu vas faire ça en Ruby, avec Rails, y'a de fortes chances qua la faille en question ne viennent même pas de ton code )"

Non pas forcément, si j'ai fini mon apprentissage de Node avant la reprise je peux tenter de le faire avec un MEAN stack

"À ta place je prendrais pas ce risque. Une application web qui manipule des données sensibles, ça peut t'anéantir si tes utilisateurs s'en prennent à toi en cas de problème"

Même dans le cas où les données qui servent à identifier les contacts sont chiffrées comme vu plus haut ? Je sais qu'un chiffrement c'est pas infaillible, mais quand même.

Enfin dans tous les cas c'est avant tout un 'prototype' sur une idée qui me plaisait bien, y'a pas vraiment de raisons que ça soit utilisé en dehors des cours si ça me sert de projet de fin de diplôme.

Mais du coup, je rebondis sur les points légaux que tu soulève. Comment les groupes qui stockent des données personnelles gèrent-ils ça ?
Premier exemple récent qui me vient en tête, Project Euler qui s'est fait volé ses bases, et les e-mails ont fuité. Le site est en faute et ça peut lui retomber dessus légalement ?

« Même dans le cas où les données qui servent à identifier les contacts sont chiffrées comme vu plus haut ? Je sais qu'un chiffrement c'est pas infaillible, mais quand même. »

C'est pas le chiffrement qui m'inquiète. C'est ce que j'évoquais déjà dans mon post précédent : l'attaquant acquiert un accès au serveur qui lui permet de modifier le JS envoyé au client, et toute ta sécurité est ruinée.

Ensuite, tu dis chiffrer uniquement le noms des contacts. Les données « en clair » même « anonymes » peuvent dévoiler assez de contexte pour identifier une personne. Ça dépend totalement de ce que l'utilisateur a rentré, rien ne l'empêche de donner des noms ou des informations qui permettent une identification facile dans les « notes » à propos d'une personne. Si t'as déjà une clé et du chiffrement côté client, autant tout chiffrer, ça coûte pas grand chose de plus (et ça ne change rien pour l'utilisateur).

Après faut prendre du recul, la vaste majorité des utilisateurs auxquels tu vas dire « Désolé, une faille a permis de dévoiler les memos à propos de vos contacts à un attaquant. » ne se retourneront pas contre toi, simplement parce qu'ils n'en ont rien à carrer, ou parce que c'est pas réaliste d'aller dans les tribunaux pour une atteinte du genre. Puis pour être vraiment réaliste, tu vas clairement spécifier que tu ne garantis que dalle à tes utilisateurs et qu'ils utilisent ton service à leurs risques et périls (voir Article 7 des CGU de JeuxVideo.com[0]).

[0] https://www.jeuxvideo.com/cgu.htm

Le cas où c'est tendu, c'est quand tu offres un service avec certaines garanties (souvent à des entreprises), par exemple Hegor Homakov qui avait trouvé un moyen d'accéder (et en read/write en plus) à des repos privés sur GitHub. Quand GitHub fait payer des boîtes pour héberger des repos privés, ça la fout mal. Alors le type est un white hat et a signalé la faille à GitHub dans le cadre de leur « bug bounty program », mais si cette faille était tombée entre de mauvaise mains, je pense que ça aurait eu le potentiel de faire couler GitHub en réputation et surtout en dommages et intérêts...

Source de mon dernier paragraphe (à propos de la faille de sécurité sur GitHub) : http://homakov.blogspot.ro/2014/02/how-i-hacked-github-again.html

Je suis en train de regarder les conditions d'utilisation de GitHub du coup, ils disent aussi explicitement qu'ils n'offrent aucune garantie, j'imagine que c'est pareil pour les comptes d'entreprises).

« Your use of the Service is at your sole risk. The service is provided on an "as is" and "as available" basis. »

« GitHub does not warrant that (i) the service will meet your specific requirements, (ii) the service will be uninterrupted, timely, secure, or error-free, (iii) the results that may be obtained from the use of the service will be accurate or reliable, (iv) the quality of any products, services, information, or other material purchased or obtained by you through the service will meet your expectations, and (v) any errors in the Service will be corrected. »

Bref, tu mets un truc comme ça dans tes conditions d'utilisations et je pense que t'es peinard.

(Je me rend compte au passage que je ne respecte pas les conditions d'utilisation de GitHub (A.7), mais chut. J'essaie de réduire mon utilisation de GitHub au même titre que mon utilisation de Google anyway.)

Dans la mesure ou tu peux héberger ton propre Git c'est pas trop un soucis de se débarasser de GitHub

Google un peu moins

Bon dieu...

As-tu oublier de te M + Z aujourd'hui Jamea ?

http://aboutthebsds.wordpress.com/2013/03/31/bsd-vs-linux/
Troll?

« So therefore, GNU/Linux is more free than the BSDs. »

J'arrête de lire ici.
Pour moi, un article qui commence par remettre sur le tapis cette putain de guerre débile des licences, c'est > /dev/null.
C'est pas pour contourner les arguments ni quoi que ce soit (btw je tourne sous Linux à l'heure actuelle), mais je ne peux plus voir en peinture les mecs qui passent plus de temps à casser les couilles à tout le monde pour des histoires de licences, qu'à écrire et partager du bon code.