les données des logs Web peuvent identifier l’activité des machines individuelles

Effectivement, on est obliger de bâtir sur l'existant en conservant une compatibilité descendante. C'est pour cela que les (ce qui apparait aujourd'hui comme des) erreurs d'autrefois existent toujours et il n'est pas possible de s'en débarrasser instantanément en claquant des doigts.

On pourrait imaginer une nouvelle technique en parallèle de l'ancienne avec une cohabitation durant quelques temps.
On a une bonne idée de ce que ça pourrait donner avec actuellement une autre technologie du net qu'est IPv4. l'IPv6 a été inventé pour palier aux soucis de l'IPv4, mais 15 ans il n'est toujours quasiment pas utilisé et on parle à peine de commencer à le mettre en place et annonce une cohabitation probablement pour au moins 10 ans.

Donc le http actuel et ses problèmes, on l'a encore pour un bon nombre d'années

juste pour dire :

Citation:

---

Envoyé par Marco46

Ce qu'on t'explique c'est que par dessus ça on est passé au web 2.0 qui lui passe "d'afficher des données" à "permettre à l'utilisateur d'interagir avec ces données" et y compris d'en publier.

---

oui, c'était en 1995, et il y avait en particulier le mot-clé FORM pour exactement ce but-là :P

Prévu dans HTML 2.0, sans avoir besoin de quoi que ce soit d'autre, en particulier rien de local..

ouais, et puis web 2.0, c'est juste l'utilisation de javascript et de CSS pour avoir des effets funky.

A la rigueur, avec HTML 5 on peut parler d'évolution(encore que... ca n'apporte pas grand chose de plus aux sites web classiques). Mais web 2.0 ou 1.0, c'est du marketing.

Citation:

---

Envoyé par souviron34

PS: c'est quand même assez dingue de se prendre plus de 10 votes négatifs simplement pour oser critiquer la politique des cookies :)

---

Pour le coup je t'en ai rajouté un...
En fait c'est normal il y a plein de vrai dev web ici qui on compris que le cookie est la seule manière correcte d'identifier l'utilisateur.
Pour ton histoire de form c'est irréaliste, tu veux faire comment? remplacer chaque lien interne par un form? Boujour la lourdeur des pages, adieu le référencement, et les handicapés ils ont qu'à aller se faire foutre? tu y pense pas à l'accessibilité, mais navigue avec lynx et tu te rendra compte de l'horreur de ta proposition.

Microsoft, se préoccupant des violations de la vie privée, c'est vraiment l'hôpital qui se moque de la charité.

Citation:

---

Envoyé par abgech

Microsoft, se préoccupant des violations de la vie privée, c'est vraiment l'hôpital qui se moque de la charité.

---

Je pense qu'ils ont commencé à vachement se calmer avec l'arrivée de tout plein de services concurrents. Tout le monde se prétend espionné par "microsoft", il y a des choses vraies qu'ils ont faites qui sont moins que limite mais il y a aussi beaucoup de mythes et de légendes urbaines sur le gros méchant monopoleur qui mange les enfants.

Microsoft n'a peut être pas toujours été exemplaire sur la protection de la vie privée par le passé. Cependant, à l'heure qu'il est, si tu regardes google, facebook, apple ce n'est de loin pas le plus mauvais élève en la matière.

Enfin... c'est mon avis.

Citation:

---

Envoyé par _skip

Je pense qu'ils ont commencé à vachement se calmer avec l'arrivée de tout plein de services concurrents. Tout le monde se prétend espionné par "microsoft", il y a des choses vraies qu'ils ont faites qui sont moins que limite mais il y a aussi beaucoup de mythes et de légendes urbaines sur le gros méchant monopoleur qui mange les enfants.

Microsoft n'a peut être pas toujours été exemplaire sur la protection de la vie privée par le passé. Cependant, à l'heure qu'il est, si tu regardes google, facebook, apple ce n'est de loin pas le plus mauvais élève en la matière.

Enfin... c'est mon avis.

---

Je le partage aussi. Microsoft a longtemps souffert d'une mauvaise image mais il en train de renverser la tendance. Notamment par la qualité de son dernier système d'exploitation seven.

Au contraire de Facebook ou d'Apple qui voit leur image se corner ces derniers temps. :mouarf:

Aaaa je me souviens du bon temps ou osé dire qu'on aimé Microsoft revenait à dire "tapé moi tapé moi" :aie:

Citation:

---

Envoyé par BPiero

Pour le coup je t'en ai rajouté un...
En fait c'est normal il y a plein de vrai dev web ici qui on compris que le cookie est la seule manière correcte d'identifier l'utilisateur.

---

Je pense que personne ne niera que le cookie est malheureusement actuellement la méthode d'identification la plus pratique, c'est difficile de s'en passer en ce moment.

Il n’empêche que si au lieu de partir sur une idée trop simple, visiblement sans avoir pensé a toutes les conséquences possibles, les inventeurs du protocole HTTP avaient pensé à un vrai système des session bien pensé, ça aurait rendu les choses bien plus propres et aurait permis de se passer des cookies, qui sont tout de même une aberration dans leur principe même et une plaie dans le traçage des utilisateurs...

Je m'y connais pas trop mais apres lecture des 3 precedentes pages, j'ai tester la desactivation des cookies et resultat, la navigation etait devenu diffile pour certains sites notement ici.
puis je me suis mis a reflechir et je vais pondre une idee pour remplacer les cookies.
dites moi juste si l'idee est faisable et si vous penser vraiment que c'est possible ou pas

voila:
le client se connect au serveur, le serveur lui repond et enregistre certaines info que le client lui donne( ca implique qu'il faut changer des choses dans le protocol HTTP) genre ip,heure de lancement de la requette HLR(important pour la suite), indentification et seulement autre info necessaire (a definir et surtout hors vie prive).
puis le serveur stock les infos et renvois une un message qui est une cle de NEXT connection. cette cle contient un nombre aleatoire qui sera calcule et renvoye par le client lors de la prochaine requette pour l'identifier.
la cle en question est calcule chez le client et le serveur en utilisant le dit message aleatoire (ca peut etre un hash) combiner a l' HLR.donc le serveur sait a qui il a affaire et repond a la requente en envoyant le mot aleatoire pour le calcule de la cle de la prochaine requette.

l'algorithme pour trouver la cle est dans le navigateur et sur le serveur.
le mot aleatoire peut se trouver par exemple dans le header de la reponse.

problemes:
-HLR doit etre stocke quelque par chez le client ainsi que le mot aleatoire en attendant le prochain mot.
- HLR permet d'empecher l'utilisabilite du mot aleatoire en cas d'interception de ce mot si et seulement si l'interception est faite dans la connection server->client. mais pas dans l'autre sens. cependant en cas d'interception une seule requette pourra etre faite par l'intercepteur car il echouera a la prochaine requette car n'ayant pas HLR il ne donnera pas de cle valide sauf si il a intercepter le premier message client donnant HLR au serveur.

les info dont ont besoin les serveurs pour maintenir une session sont et devrait etre juste une cle le reste user/pass etant deja sur le serveur(crypter ou non).

bon je pense que ce systeme devrait permettre aux parano de la vie privee (comme moi) d'etre un peu plus a l'aise. mais techniquement est-ce faisable?

Citation:

---

Envoyé par lilington

Je m'y connais pas trop mais apres lecture des 3 precedentes pages, j'ai tester la desactivation des cookies et resultat, la navigation etait devenu diffile pour certains sites notement ici.
puis je me suis mis a reflechir et je vais pondre une idee pour remplacer les cookies.
dites moi juste si l'idee est faisable et si vous penser vraiment que c'est possible ou pas

voila:
le client se connect au serveur, le serveur lui repond et enregistre certaines info que le client lui donne( ca implique qu'il faut changer des choses dans le protocol HTTP) genre ip,heure de lancement de la requette HLR(important pour la suite), indentification et seulement autre info necessaire (a definir et surtout hors vie prive).
puis le serveur stock les infos et renvois une un message qui est une cle de NEXT connection. cette cle contient un nombre aleatoire qui sera calcule et renvoye par le client lors de la prochaine requette pour l'identifier.
la cle en question est calcule chez le client et le serveur en utilisant le dit message aleatoire (ca peut etre un hash) combiner a l' HLR.donc le serveur sait a qui il a affaire et repond a la requente en envoyant le mot aleatoire pour le calcule de la cle de la prochaine requette.

l'algorithme pour trouver la cle est dans le navigateur et sur le serveur.
le mot aleatoire peut se trouver par exemple dans le header de la reponse.

problemes:
-HLR doit etre stocke quelque par chez le client ainsi que le mot aleatoire en attendant le prochain mot.
- HLR permet d'empecher l'utilisabilite du mot aleatoire en cas d'interception de ce mot si et seulement si l'interception est faite dans la connection server->client. mais pas dans l'autre sens. cependant en cas d'interception une seule requette pourra etre faite par l'intercepteur car il echouera a la prochaine requette car n'ayant pas HLR il ne donnera pas de cle valide sauf si il a intercepter le premier message client donnant HLR au serveur.

les info dont ont besoin les serveurs pour maintenir une session sont et devrait etre juste une cle le reste user/pass etant deja sur le serveur(crypter ou non).

bon je pense que ce systeme devrait permettre aux parano de la vie privee (comme moi) d'etre un peu plus a l'aise. mais techniquement est-ce faisable?

---

Déjà dit à plusieurs reprises, ça existe déjà. C'est, entre autre, le fameux coup de l'ID de session dans l'url.

Le problème qui se pose c'est qu'il faut, coté serveur, du stockage, un système de gestion des sessions. Il faut savoir quand détruire les sessions qui n'ont plus lieu d'être (quand l'utilisateur est parti sur un autre site, le serveur n'a aucun moyen de le savoir), etc.
Ca fait une charge non négligeable de travail et d'espace de stockage coté serveur.

Multiplie ça par des millions d'utilisateurs à la minute comme sur Google ou Facebook par exemple, c'est quand même un système lourd à mettre en place.

Ça marche très bien sur de petits sites, ou des Intranets, mais sur des sites à forte popularité c'est plus délicat à gérer.

effectivement j'avais pas pris on compte la charge, le stockage.
bref visiblement je vais me contenter de suivre la discussion ca vaudrait mieux.

<reve>si seulement les gros sites pouvaient se contenter de reconnaitre les clients sans rien faire d'autre la vie serait telllllllllllllllllllllllllement plus simple </reve>

Il n'y a rien qui empeche d'imaginer que le serveur envoie un token à la création de la session, et que les navigateurs inclus dans leur spécification de renvoyer un message quand ils quittent le site web pour fermer cette session.

Associé a l'actuelle gestion de time out, ca devrait être au moins aussi stable qu'un cookies.

Sans être en connections persistantes, on peut imaginer d'avoir des connections entre les deux.

Le cookies est de plus un fichier, pourquoi un fichier ? On ne pourrait pas dire que le contenu est avant tout stocké dans la mémoire, avec conservation des données d'une page à l'autre(de la mémoire quoi) sans passer par un accès disque ? Après, si l'utilisateur le demande, il pourrait, ou pas, conserver une sauvegarde de ces données(id de session) dans un système interne au navigateur.

Citation:

---

Envoyé par pmithrandir

Il n'y a rien qui empeche d'imaginer que le serveur envoie un token à la création de la session, et que les navigateurs inclus dans leur spécification de renvoyer un message quand ils quittent le site web pour fermer cette session.

---

Encore faut-il que le navigateur lui-même sache quand le site est quitté. Ils sont nombreux, les sites qui font appel à des pages d'autres sites. De plus il y a plusieurs façon de quitter un site, taper une nouvelle adresse, cliquer sur un lien du site actuel avec les différents systèmes de redirection qui existe, avec la possibilité de ne pas quitter le site actuel mais ouvrir le nouveau dans une autre fenêtre, fermer le navigateur, arrêter le système sans rien fermer, etc.
C'est certainement pas impossible à gérer, mais relativement complexe, sans compter les milliards de sites à mettre à jour pour tenir compte de cela, ainsi que les navigateurs. A l'heure actuelle je ne vois pas les éditeurs de navigateurs se lancer là dedant, sauf à ce que ça apparaisse dans une nouvelle norme. Je ne pense pas que la norme HTTP soit prête d'être changer de sitot.

Citation:

---

Le cookies est de plus un fichier, pourquoi un fichier ? On ne pourrait pas dire que le contenu est avant tout stocké dans la mémoire, avec conservation des données d'une page à l'autre(de la mémoire quoi) sans passer par un accès disque ? Après, si l'utilisateur le demande, il pourrait, ou pas, conserver une sauvegarde de ces données(id de session) dans un système interne au navigateur.

---

Depuis plusieurs pages, la discussion s'est focalisée sur l'aspect session et identité du cookie, mais ce n'est qu'une infime partie de ce qu'il peut stocker, certes probablement la plus utilisée. Le cookie peut stocker bon nombres d'informations diverses et variées, comme des préférences, thèmes, etc d'un site, et ce au delà de plusieurs jours, si nécessaire. Sachant qu'entre temps, le navigateur peut être fermé, le système peut être arrête, non le cookie ne peut pas être stocké uniquement en mémoire.
De plus le cookie est utilisé par le serveur, pas par le navigateur client. C'est un simple fichier qui est transmis au serveur sur simple demande, il n'y a aucune raison que ce fichier consomme de la mémoire pour rien.

Citation:

---

Envoyé par sevyc64

Depuis plusieurs pages, la discussion s'est focalisée sur l'aspect session et identité du cookie, mais ce n'est qu'une infime partie de ce qu'il peut stocker, certes probablement la plus utilisée. Le cookie peut stocker bon nombres d'informations diverses et variées, comme des préférences, thèmes, etc d'un site, et ce au delà de plusieurs jours, si nécessaire. Sachant qu'entre temps, le navigateur peut être fermé, le système peut être arrête, non le cookie ne peut pas être stocké uniquement en mémoire.
De plus le cookie est utilisé par le serveur, pas par le navigateur client. C'est un simple fichier qui est transmis au serveur sur simple demande, il n'y a aucune raison que ce fichier consomme de la mémoire pour rien.

---

En fait, tout dépend de ce que l'on admet de stocker sur le pc client et dans quelles circonstances.

garder des infos sur un client enregistré sur le serveur, peut être fait par le serveur.
garder des infos sur un visiteurs non connu du serveur ne peut être fait qu'avec un système comme les cookies... mais est ce légitime ?

Après, on peut aussi se demander si tout betement on ne pourrait pas renforcer encore les barrières des cookies, pour faire par exemple en sorte que seule la partie embarquée depuis un autre site ait accés au cookies, et non la page contenante egalement.(et vice versa)

Si l'on arrive a avoir une liste de donnée sur un ordi suffisante pour l'indetifier de façon unique, c'est qu'a un moment on en donne trop.

Citation:

---

Envoyé par pmithrandir

Si l'on arrive a avoir une liste de donnée sur un ordi suffisante pour l'indetifier de façon unique, c'est qu'a un moment on en donne trop.

---

Attention, tu place pas le problème au bon endroit, là.

Ce n'est pas le cookie qui fourni les données, il ne fait que sauvegarder et restitué des données qui ont déjà été fournies au serveur auparavant.

Donc si le cookie contient "trop" de données, la question a se poser n'est pas au niveau du cookie, mais bien comment ces données ont pu être obtenues avant d'être stockées dans les cookies. Et là, on aborde un autre pan des sites web qui est la partie script des pages, que ce soit du javascript, du flash et bien d'autres choses et qui peuvent obtenir quantités d'informations sur l'utilisateur et la machine

Citation:

---

Envoyé par pmithrandir

Si l'on arrive a avoir une liste de donnée sur un ordi suffisante pour l'indetifier de façon unique, c'est qu'a un moment on en donne trop.

---

En soi, ce n'est pas ce qui me pose un problème. Les utilisateurs ne sont pas plus des bisounours que les sites et pouvoir identifier un "script kiddy" qui fait tomber des sites "4 teh lulz", la personne qui a mis en ligne une vidéo d'aggression ou encore un pédophile, c'est bien.

Là où ça pose problème c'est quand n'importe qui peut t'identifier et te suivre, sans te demander ton avis ou même te prévenir. Que e.g. Facebook peut suivre l'activité de ses utilisateur, grâce à ses widgets présents un peu partout, et récolter une foule d'informations qu'il n'a pas à avoir avec ses scripts pour les stocker dans des cookies qu'il récupère ensuite, c'est inquiétant. Bref, ce qui me gêne c'est la facilité avec laquelle des entreprises peuvent collecter ces informations.

Citation:

---

Envoyé par sevyc64

Depuis plusieurs pages, la discussion s'est focalisée sur l'aspect session et identité du cookie, mais ce n'est qu'une infime partie de ce qu'il peut stocker, certes probablement la plus utilisée. Le cookie peut stocker bon nombres d'informations diverses et variées, comme des préférences, thèmes, etc d'un site, et ce au delà de plusieurs jours, si nécessaire. Sachant qu'entre temps, le navigateur peut être fermé, le système peut être arrête, non le cookie ne peut pas être stocké uniquement en mémoire.
De plus le cookie est utilisé par le serveur, pas par le navigateur client. C'est un simple fichier qui est transmis au serveur sur simple demande, il n'y a aucune raison que ce fichier consomme de la mémoire pour rien.

---

Citation:

---

Envoyé par sevyc64

Ce n'est pas le cookie qui fourni les données, il ne fait que sauvegarder et restitué des données qui ont déjà été fournies au serveur auparavant.

Donc si le cookie contient "trop" de données, la question a se poser n'est pas au niveau du cookie, mais bien comment ces données ont pu être obtenues avant d'être stockées dans les cookies. Et là, on aborde un autre pan des sites web qui est la partie script des pages, que ce soit du javascript, du flash et bien d'autres choses et qui peuvent obtenir quantités d'informations sur l'utilisateur et la machine

---

C'est ce que je disais depuis le départ.

Même si les cookies sont un épi-phénomène, ils stockent comme tu le dis si bien "pour le serveur", et donc la partie "multi-langages" - plugins -javascript/flash/...

Bref, toute la costruction actuelle du web dynamique est très hautement "mal conçue" du point de vue de l'utilisateur.. Super-bien conçue du point de vue des "ramaseurs d'info", par contre...

Et c'est là que je trouve vos réactions étranges.. Plutôt que de chercher à comprendre pourquoi (et éventuellement à corriger ou à éviter/prohiber) des trucs comme Javascript ou flash ou tout ce genre de choses puissent stocker et récolter des informations, vous trouvez ça formidable et vous me critiquez..

Alors que je ne suis que le messager... Pas le problème..

Mais penser à résoudre le problème ne faciliterait pas la vie des dev Web, qui dans notre monde depuis 10 ans se pensent les rois du monde..

Citation:

---

Envoyé par souviron34

Mais penser à résoudre le problème ne faciliterait pas la vie des dev Web, qui dans notre monde depuis 10 ans se pensent les rois du monde..

---

Si le reste de ton message est ouvert à la discussion, cette remarque en revanche est de trop :ccool:

Citation:

---

Envoyé par deathness

Si le reste de ton message est ouvert à la discussion, cette remarque en revanche est de trop :ccool:

---

bah.. Vu les remarques et points négatifs que j'ai eu au dessus, et a contrario les messages relativement réfléchis de la dernière page et de celle-ci, dont le tien, ça prouve un peu mon point ;)

Citation:

---

Envoyé par souviron34

Et c'est là que je trouve vos réactions étranges.. Plutôt que de chercher à comprendre pourquoi (et éventuellement à corriger ou à éviter/prohiber) des trucs comme Javascript ou flash ou tout ce genre de choses puissent stocker et récolter des informations, vous trouvez ça formidable et vous me critiquez..

---

Personnellement, je pense que le web et les outils du web (html/javascript/css) peinent de plus en plus à correspondre aux besoins actuels. Aujourd'hui où la mouvance RIA prédomine et qu'on veut de plus en plus de choses dynamiques et d'interactions et certaines passent obligatoirement par le maintien d'un état comme ceci est possible dans un client lourd, on peut se poser la question si la bonne solution est toujours de pondre 4-5 nouvelles spécifications JS ou si l'on est pas en train de pousser des technos à faire ce pourquoi elles ne sont pas faites.

Si on devait revoir complètement ces choses avec une bonne conception tu dis, on ferait certainement pas ça de la même manière. Mais pour l'instant, l'énormité de l'existant nous oblige à continuer avec du http/html/js/css et à perpétuer des problèmes qui existent depuis 10 ans.

On ne peut même pas reprocher aux développeurs webs cette situation puisque finalement leur boulot est de bosser avec ce qui existe. Il aurait plutôt fallu que les commités de standardisation aient plus le courage de sacrifier de la compatibilité à court terme pour du bénéfice à long terme.
Enfin c'est tout un autre débat ça.
En gros le web c'est un peu comme l'euro, tout le monde sait que c'est pas optimal, que ça aurait pu être fait autrement, mais tout le monde dit qu'on est trop mouillé dedans pour en sortir sans casse. :mouarf: