Discussion :

[_skip]

euhh... même HTML 1.0 prévoit l'envoi de texte...

Sans parler de HTML 2.0 qui a le mot clé FORM ...

Je sais pas, moi je verrais un truc comme :

il y a un flag général keep_alive/déconneion manuelle ou reconnect_each_time

• accèder URL developpez
• afficher page avec champ username pass
• envoyer username pass
• le SERVEUR sait que ce username/pass a le droit de modifier ses messages et quand il en ajoute, cela sera avec son username
• le client envoie un texte (méthode POST avec lien HTML si édition)
• le SERVEUR vérifie si le lien est un lien existant (modification) ou vide (création)
• le SERVEUR vérifie si on a la droit ou non (soit avec session ouverte soit avec le nouveau couple username/pass)

A part l'envoi initial et/ou répété suivant le choix initial, rien n'est sauvegardé localement (le navigateur a
Franchement je ne vois pas très bien ce qu'on ne pourrait pas faire..

Le processus que tu décris n'est pas très différent de celui qui a lieu avec les cookies. Les informations de ton cookie sont lues et transmises en headers à chaque requête, ce n'est pas extrêmement différent d'un envoi "post" faisant suite à un clic sur un bouton "submit" avec des champs cachés.

Quelle différence finalement entre des infos transmises par champs hidden sur formulaire de façon transparente ou balancées cash dans un cookie si de toutes façons on accepte que le navigateur transmette ces données ?

Est-ce qu'en fait, ce qui te dérange vraiment dans les cookie ce n'est pas à proprement parler son utilisation mais le fait qu'il puisse être physiquement écrit sur disque et persistent?

[souviron34]

Si on veut gérer une connection en utilisant HTTP, il faut déléguer cette tâche à une couche au-dessus, c'est à dire que ce sera un concept "hors-protocole" basé sur un agrément entre le client et le serveur.

ça s'appelle pas HTML ce genre de concept ??

Ce qui est visiblement difficilement compréhensible pour certain c'est qu'en http la "session" de la connexion au serveur est extrêmement courte et ne correspond pas à la "session" de l'utilisateur, elle ne correspond seulement au chargement d'une page voire d'une partie d'une page web.

Ce qui est visiblement difficile à comprendre par certains, c'est que le protocole d'une page Web est HTML..

HTTP est un protocole de TRANSPORT, assoicé en partie à HTML qui prévoit des "méthodes" assez de base.

La gestion d'une "session" ne devrait pas à avoir lieu côté client : n'importe quel admin de BDD te dira ça..

Qu'il y ait des timeout si aucune nouvelle requête est transmise, OK. Qu'il y ait une déconnexion manuelle, OK. Que les navigateurs fournissent une "déconneion automatique" quand on cgange de page ou de site, OK. Mais je trouve qu'il y a une erreur fondamentale de conception dans cette gestion "locale".

Quelle différence finalement entre des infos transmises par champs hidden sur formulaire de façon transparente ou balancées cash dans un cookie si de toutes façons on accepte que le navigateur transmette ces données ?

Est-ce qu'en fait, ce qui te dérange vraiment dans les cookie ce n'est pas à proprement parler son utilisation mais le fait qu'il puisse être physiquement écrit sur disque et persistent?

ce qui me dérange, c'est que en "hidden", il n'y a pas grand chose : l'adresse IP. Il peut y avoir (et encore, c'est pas vraiment "hidden" puisque c'est dans les liens de la page) les sous-liens des parties de la page "cachée" (en fait le code-source de la page)

Les champs de la page sont en clair. Leur remplissage aussi.


Ce qui me dérange, c'est que non seulement cela vient polluer mon disque, non seulement cela peut être persistent, mais en plus je ne sais pas si ils ne "ramassent" pas des infos sur mon PC...

Et justement, comme tu le dis, ce n'est pas si différent en principe: c'est e lieu où ça se passe et la manière dont ça se passe qui est différent..

[tontonnux]

Ce qui est visiblement difficile à comprendre par certains, c'est que le protocole d'une page Web est HTML...

On peut pas attendre vendredi pour des vannes comme celle-là ? Nan, sérieux ?

(...) si ils ne "ramassent" pas des infos sur mon PC...

Non, un cookie ne peut rien "ramasser".

[_skip]

Qu'il y ait des timeout si aucune nouvelle requête est transmise, OK. Qu'il y ait une déconnexion manuelle, OK. Que les navigateurs fournissent une "déconneion automatique" quand on cgange de page ou de site, OK. Mais je trouve qu'il y a une erreur fondamentale de conception dans cette gestion "locale".

Cela signifierait donc que la connexion serait persistante et cela poserait sans doute quelques autres problèmes (garder 1000 sockets ouverts simultanément plutôt que le mode "repy-and-forget" actuel).

Cependant la nature déconnecté était là en premier à l'époque ou le web était majoritairement utilisé pour la consultation de contenu, puis ensuite est venue la nécessité de conserver un état à cause des interactions individuelles toujours plus poussées. Donc le système du cookie qu'on présente tel un ticket reste plus ou moins la seule solution en attendant un changement de nature du web.

La seule alternative, serait celle de MiaouZdong où le client sur requête annonce au serveur "Je te donne cet identifiant : ##<insérez gros hash tout moche ici>## et c'est là TOUT ce que tu auras de moi pour maintenir mon état.

[tontonnux]

La seule alternative, serait celle de MiaouZdong où le client sur requête annonce au serveur "Je te donne cet identifiant : ##<insérez gros hash tout moche ici>## et c'est là TOUT ce que tu auras de moi pour maintenir mon état.

Le problème, c'est comment garantir que l'identifiant est bien unique pour le serveur si ce n'est pas lui qui le défini ?
Ensuite, on est bien d'accord pour dire que dans ce cas, le client est bien obligé de conserver l'identifiant quelque part pour l'envoyer à nouveau au serveur ?
Et donc en quoi est-ce différent... d'un cookie ?

[sevyc64]

[*]Tu generes un cookie, que le serveur vérifie comme unique

Et tu le génère avec quoi ton cookie ?
Seul le serveur sait ce que veux avoir dans le fichier. Que tu crée toi-même un fichier avec des données que t'envoie le serveur et dont tu ne comprend rien, ou que tu enregistre un fichier reçu, ça revient exactement à la même chose.

Ce que tu n'as pas compris, c'est que tu veux gérer coté client des informations que tu n'as pas, dont tu n'en connais pas le contenu, que tu n'es pas capable de deviner.
Un cookie ne stocke pas que (et pas forcément) des informations d'identification. Il peut stocker tout et n'importe quoi à partir du moment ou c'est utile au serveur. Comment serais-tu capable de deviner à la place du serveur ce qu'il a besoin?

Ce qui est visiblement difficile à comprendre par certains, c'est que le protocole d'une page Web est HTML..

HTTP est un protocole de TRANSPORT, assoicé en partie à HTML qui prévoit des "méthodes" assez de base.

Le HTML n'est pas un protocole. Le HTML est un langage. Techniquement c'est juste un fichier texte que ton navigateur sait interprété. Ça pourrait être du Word, du xml, du texte, du Russe, ... c'est exactement pareil.

Le HTML n'a absolument rien à voir ici. Le problème est bien sur le protocole de communication HTTP qui est, comme dit plus haut, un protocole qui ne conserve ni connexion, ni état et paramètres de la connexion.

[Freem]

La différence entre le ftp et le http amha, c'est que le client ftp est fait pour ce genre de manip'.
Le client http a pour seul role d'envoyer une requête et afficher un résultat !
Et stocker des informations chez le client pour le reconnaître quand il recontactera le serveur ne me choque pas.

Selon wikipedia, http a été créé pour pallier au problème d'identifier le type d'un fichier: texte normal, html, source php, gif, exe, ...
FTP ne peut pas. HTTP peut.
Pourquoi FTP ne demande pas le couple login/pass à chaque fichier? Parce qu'il a une session. Comment a t'il une session? Parce qu'il repose sur TCP.

HTTP est utilisé sur TCP, c'est vrai. Mais je vois pas trop pourquoi, il pourrait aussi bien être utilisé sur UDP (quote wiki: "However, HTTP has found application even with unreliable protocols, such as the User Datagram Protocol (UDP) in methods such as the Simple Service Discovery Protocol (SSDP).")

Si HTTP peut être utilisé sur UDP, c'est parce qu'il n'a pas besoin de/n'est pas fait pour stocker de session. Si les sites utilisent ce protocole pour établir une connexion fiable, parce qu'ils se transforment en application, alors qu'ils assument leur statut d'application client/serveur et utilisent des outils adaptés. (On nous répète régulièrement le fait que les langages et les framework ont une "zone d'efficacité maximale", c'est pareil avec les protocoles réseau.)

Mais passons.
L'intérêt du cookie, si c'était juste d'identifier une personne, ne poserait pas de souci. Mais je ne pense pas qu'il soit fait pour la session.
L'habituelle excuse des infos relatives aux préférences d'un utilisateur est ridicule, elles pourraient très bien être stockées dans une BDD, et les virer au bout de tant de temps.

Le seul type de cookie qui puisse trouver grâce à mes yeux, c'est celui qui me reconnecte automatiquement quand je vais sur un site que je fréquente souvent. (Encore que je pourrais utiliser les "porte-clés" qui stockent une foultitude de code sur le disque en permettant de ne se rappeler que d'un, du coup même pour ça le cookie est discutable)
Les autres n'ont aucune raison d'être.

A noter tout de même que le fait qu'une info soit stockée dans un cookie ou une bdd, ne change pas qu'elle est stockée, et que celui qui y a accès (le site web) peut la recouper, la revendre, etc... autant qu'il le veut, puisqu'on a de contrôle que sur notre machine.
Par contre, stockée dans une BDD, elle ne permet pas d'identifier un anonyme.

Si les sites ne font pas ça, c'est probablement que stocker des informations sur des millions d'utilisateur leur coûterait cher. Quitte a recouper des informations qu'ils n'auraient pas dû stocker, autant le faire aux frais des utilisateurs. L'espace disque coûte cher après tout... Ah, et autant que ça dure d'une connexion à l'autre, histoire de récupérer d'autres informations qui ne les concernent pas.
Une application en mode IRL pour le fun:
Je vais chez un boulanger (en voiture, j'habite à la campagne). Je n'y vais pas souvent, il n'est que sur la route qui me permet d'aller chez un copain, et j'achète rarement du pain en allant chez cette personne. Du coup, je suis anonyme.
Celui-ci écrit l'heure, la date et ce que j'ai acheté sur un papier, et le met dans ma voiture, à un endroit auquel lui-seul a accès.
En quoi ça me gêne? A priori, en rien, si ce n'est que j'ai déjà du mal a gérer le bordel que je met dans ma voiture, sans avoir a m'occuper de celui des autres. Passons.
Sauf que si je vais chez ce boulanger une fois tous les 36 du mois, pourquoi devrait-il avoir besoin de savoir que moi, et personne d'autre, a acheté le 10 janvier 2005 une baguette à 5H45, et ai récidivé le 7 août 2011, à 17H17, avec un pain au chocolat supplémentaire?
Avec ce petit papier, ce charmant monsieur peut connaître mes envies et sujets de discussions (tout ce qu'il aura voulu noter en fait) triés par jour et heure.
Si ce monsieur travaillait pour un grand groupe nommé MicroLevure, alors le groupe entier aurait ces informations sur moi, et pourrait les recouper avec celles des autres commerces de ce groupe.
Ce qui permet donc un début de cartographie de mes actions, pour peu que le groupe soit assez important et aie suffisamment de services différents.

Dans cet exemple, ils auraient pu stocker ces infos dans un BDD : "un type qui a la 20aine, habillé d'un jean, de chaussures et de manteau de cuir, aux yeux bleus, qui a parlé de l'augmentation récente du prix de l'essence, à acheté une baguette le 10/01/2005, 5H45." mais il n'aurait pas pu recouper ces informations avec celles des autres commerces du groupes, et encore moins avec l'achat d'un pain au chocolat fait 6 ans plus tard.
Ce qui me pose problème, dans cette histoire, c'est que parce que le type bosse pour le même groupe que l'épicier de mon village, et le coiffeur de la ville voisine, il peut devenir capable, à mon insu, de connaître plus d'informations qu'il n'en a besoin sur mon compte.
Le meilleur, c'est que cette information a un coût moindre, puisqu'il stocke sa cochonnerie chez moi! Il ne pourrait assurément pas stocker suffisamment d'infos pour identifier aisément tous les anonymes qui rentrent chez lui, son classeur n'est pas assez grand. Donc, il utilise la place qui est chez moi, pour pouvoir m'identifier d'un passage à l'autre chez lui ou ses collègues.
En plus, outre le problème du profilage, comment je fais pour savoir qu'il n'y a pas un type dans ce groupe qui souhaite attaquer la société pour laquelle je bosse, a cause d'un prototype qui ferait de l'ombre à son commerce?
En recoupant les informations sur plusieurs milliers d'utilisateurs, on peut sûrement récupérer des informations qui permettent d'avoir une vue générale de la cible. Vue qui permet potentiellement d'identifier des failles. Hé oui, un collègue que je vois rarement bosse sur ce prototype. Il y a peut-être moyen de se faire passer pour moi, et de lui faire croire que j'ai été affecté à son équipe mais que tout ne s'est pas passé correctement, et que pour me dépanner il faudrait qu'il me file des infos critiques.
Il se peut aussi que ce ne soit pas quelqu'un du groupe en question qui souhaite faire cette attaque, mais quelqu'un qui a pu leur voler leur BDD, avec ces précieux recoupements.
Parano? Sûrement un peu. Mais ce scénario est-il hautement improbable? Je me rappelle un récit d'une infiltration d'un hacker célèbre dans une structure sécurisée avec un mot de passe généré tous les jours pour chaque personne, et le hacker n'a utilisé aucune compétence technique, il a juste demandé le code à un type en se faisant passer pour un de ses collègues, qui était bloqué par une tempête de neige.

A ceux qui disent que le cookie, c'est comme se présenter quand on arrive chez quelqu'un, c'est faux.
Dans le protocole, se présenter quand on arrive chez quelqu'un, c'est l'équivalent de la connexion TCP, qui n'est même pas obligatoire avec HTTP.
Le cookie, c'est quand la personne écrit votre nom sur un papier, qu'elle vous colle discrètement dans le dos.


PS: quelle est la différence de sécurité entre un truc style PHPSESSID et un cookie? Parce que pour le coup, c'est bien le but de PHPSESSID de gérer la session d'un utilisateur, non?

[sevyc64]

La seule alternative, serait celle de MiaouZdong où le client sur requête annonce au serveur "Je te donne cet identifiant : ##<insérez gros hash tout moche ici>## et c'est là TOUT ce que tu auras de moi pour maintenir mon état.

Le problème, c'est comment garantir que l'identifiant est bien unique pour le serveur si ce n'est pas lui qui le défini ?
Ensuite, on est bien d'accord pour dire que dans ce cas, le client est bien obligé de conserver l'identifiant quelque part pour l'envoyer à nouveau au serveur ?
Et donc en quoi est-ce différent... d'un cookie ?

Ça existe déjà, c'est le principe de la session coté serveur avec l'ID de session dans l'adresse URL, déjà évoquer plus tôt.

Vous êtes en train de réinventer l'eau chaude

[tontonnux]

Ça existe déjà, c'est le principe de la session coté serveur avec l'ID de session dans l'adresse URL, déjà évoquer plus tôt.

Vous êtes en train de réinventer l'eau chaude

Bah, moi je ne réinvente pas grand chose... j'essayais juste de lui faire comprendre par l'absurde que son idée n'en était pas une justement.

Je n'arrive toujours pas à comprendre la parano sur le cookie. Ca me parait complétement surréaliste.

Edit :
Par exemple, comment on peut dire que le seul COOKIE acceptable est un COOKIE qui permet de reconnecter automatiquement... alors que ce type de COOKIE est pour le coup réellement à bannir ?!

Pour info, le fameux COOKIE Facebook... sa principale fonction c'est ça justement... pouvoir identifier une personne directement sans formulaire de connexion.
Ensuite, toutes les données qui intéressent Facebook sont effectivement stockées en base de données.

Supprimons le REFERER, là au moins on avancera... mais le COOKIE sérieusement, c'est tellement rien (ce n'est qu'un fichier texte quoi).

[_skip]

Ça existe déjà, c'est le principe de la session coté serveur avec l'ID de session dans l'adresse URL, déjà évoquer plus tôt.

Vous êtes en train de réinventer l'eau chaude

Exactement, le seul avantage serait de forcer le serveur à travailler avec ce système-là et à ne pas stocker 36000 merdes dans un cookie persistent côté client.
On est à l'abri de rien, ça n'ajoute que peu à la sécurité dans le sens ou le plus gros risque est que la session soit interceptée et "rejouée", ça limite juste les possibilités de stockage d'informations en clair sur le client.

Ca ne veut bien entendu pas dire que le service dispose soudainement de moins d'éléments de traçabilité puisque le résultat est le même, la personne et reconnue et son profil/session peut être activé ou consulté.

[Freem]

Simple.
Le cookie permet d'identifier une personne contre son gré.

Ensuite, il y a le fait que, basiquement, un site sur lequel on ne va qu'une fois tous les 36 du mois, ou sur lequel on va involontairement (style les publicités incluses.) n'a pas a stocker d'infos sur une machine qui n'appartiens pas a ce site.

En fait, quel est l'intérêt du cookie?
_ session => PHPSESSID (par exemple)
_ réglages personnels => BDD

Quel est le souci?
_ offre une solution supplémentaire pour traquer une personne => effacer les cookies après chaque visite de site.
_ fragmentation de l'espace disque. (quelques milliers de fichiers totalement inutiles quand même)
_ stockage de données non utiles a l'utilisateur sur sa machine.
_ avec le ssd, on peut ajouter que ça bouffe des cycles, même si c'est pas énorme.

[edit]
Oui, en effet, la seule utilisation que je fais des cookies est la plus dangereuse
Je m'en rend parfaitement compte, mais j'ai moyennement envie de stocker les mots de passe sur disque, même chiffrés. Je préfère qu'on me vole une session plutôt qu'un mot de passe.

[deathness]

Je pense qu'il doit y avoir un blocage sur le fait que le serveur enregistre des choses sur notre pc.
A partir de là on peut vite imaginer qu'il peut donc faire n'importe quoi sur le pc sans que l'on ne sache rien.

[tontonnux]

Le cookie permet d'identifier une personne contre son gré.

Oui, d'accord et il faut encadrer tout ça. Tout comme une voiture permet de tuer des gens... mais la législation doit cadrer tout ça.

Ensuite, il y a le fait que, basiquement, un site sur lequel on ne va qu'une fois tous les 36 du mois, ou sur lequel on va involontairement (style les publicités incluses.) n'a pas a stocker d'infos sur une machine qui n'appartiens pas a ce site.

Entièrement d'accord, la prise en compte de DoNotTrackMe devrait être obligatoire.

_ session => PHPSESSID (par exemple)

J'imagine que tu parle de passer la session dans l'URL.
Tu créé alors ce que j'appelle des URL d'autolog, ce que je m'interdirais TOUJOURS de faire en temps que développeur Web. Par souci de protection de la vie privée de mes utilisateurs, je ne mettrais JAMAIS en place quoique ce soit qui permette l' "autolog" !

_ réglages personnels => BDD

Euh... oui, et en fait, ça change quoi que ces données soient stockées sur ta machine ou sur le serveur ? Puisque seul le serveur qui a demandé à ton client de les y placer peut y avoir accès ?

_ offre une solution supplémentaire pour traquer une personne => effacer les cookies après chaque visite de site.

Faux. Tracker une personne se fait via le REFERER, pas les COOKIES.

_ fragmentation de l'espace disque. (quelques milliers de fichiers totalement inutiles quand même)

Je ne répond pas...

_ stockage de données non utiles a l'utilisateur sur sa machine.

Là non plus...

_ avec le ssd, on peut ajouter que ça bouffe des cycles, même si c'est pas énorme.

Ben euh...

Oui, en effet, la seule utilisation que je fais des cookies est la plus dangereuse
Je m'en rend parfaitement compte, mais j'ai moyennement envie de stocker les mots de passe sur disque, même chiffrés. Je préfère qu'on me vole une session plutôt qu'un mot de passe.

Qui a accès à ta session n'a pas besoin de ton mot de passe... il perd un peu toute sa valeur là...

[tontonnux]

Je pense qu'il doit y avoir un blocage sur le fait que le serveur enregistre des choses sur notre pc.
A partir de là on peut vite imaginer qu'il peut donc faire n'importe quoi sur le pc sans que l'on ne sache rien.

Ben le serveur ne peut rien enregistrer sur ton PC. Il peut juste demander à ton navigateur (qui autorise ou pas) d'écrire un cookie. Qu'il sera ensuite le seul à pouvoir lire.

[Uther]

Oui, d'accord et il faut encadrer tout ça. Tout comme une voiture permet de tuer des gens... mais la législation doit cadrer tout ça.

Entièrement d'accord, la prise en compte de DoNotTrackMe devrait être obligatoire.

C'est beau de rêver.
Je ne dis pas que l'initiative de Mozilla est mauvaise, c'est mieux que rien. Mais il faudrait être vraiment naïf pour croire qu'il suffit de demander gentiment aux gens de ne pas traquer pour te mettre à l'abri.
Même si tout les pays s'accordaient à faire des lois obligeant son respect, je serait très curieux de savoir comment ils réussiraient à les faire respecter.

Qui a accès à ta session n'a pas besoin de ton mot de passe... il perd un peu toute sa valeur là...

Si tu utilises un mot de passe différent sur chaque site que tu visites, oui. Je ne connais pas grand monde qui soit dans ce cas

[tontonnux]

C'est beau de rêver.
Je ne dis pas que l'initiative de Mozilla est mauvaise, c'est mieux que rien. Mais il faudrait être vraiment naïf pour croire qu'il suffit de demander gentiment aux gens de ne pas traquer pour te mettre à l'abri.

Il ne s'agit pas de se mettre à l'abri (aucune solution, que ce soit technique ou juridique ne le pourra jamais), mais d'encadrer les choses afin d'avoir la possibilité de sanctionner.
Par ce que si on cherche une solution technique en partant du principe que le cookie, c'est le mal... on va pas aller loin.

[MiaowZedong]

Et tu le génère avec quoi ton cookie ?
Seul le serveur sait ce que veux avoir dans le fichier. Que tu crée toi-même un fichier avec des données que t'envoie le serveur et dont tu ne comprend rien, ou que tu enregistre un fichier reçu, ça revient exactement à la même chose.

Ce que tu n'as pas compris, c'est que tu veux gérer coté client des informations que tu n'as pas, dont tu n'en connais pas le contenu, que tu n'es pas capable de deviner.
Un cookie ne stocke pas que (et pas forcément) des informations d'identification. Il peut stocker tout et n'importe quoi à partir du moment ou c'est utile au serveur. Comment serais-tu capable de deviner à la place du serveur ce qu'il a besoin?

Justement, c'est là l'intérêt: le serveur est obligé de communiquer ce qu'il veut que tu stockes en clair. On peut imaginer un protocole standard pour les requêtes de création de cookies, a base de XML, JSON, Foobar Data Model, ou à peu près n'importe quoi du moment que c'est standard. Après tout ce ferait par hash, mais l'utilisateur saurait exactement à quoi correspond son hash.

Pour les ID uniques, on pourrait mettre plein de données style IP, compte utilisateur, nom du système (celui que tu choisis quand t'installes l'OS), avec un nombre pseudo-aléatoire dans une fonction de hash pointue. Ensuite le serveur vérifierait l'unicité, mais il y aurait peu de doublons.

Bon, après on n'est pas dans le pays des bisounours et rien n'empêche le serveur de stocker sur sa BDD des données correspondant à ton hash: mais au moins ce ne serait pas sur ton PC. Pour les méfiants, il y aurait aussi possibilité de changer son "identité" pour le serveur sans forcement perdre ses options (ex:options de langue) si le browser sait comment générer le cookie.

Je rêve peut-être mais ça me parait quand même comme un système qui pourrait marcher, s'il était adopté (et c'est là le plus dur).

[Marco46]

Justement: le problème c'est non seulement qu'ils peuvent le faire, mais--dans la mesure que le cookie est crypté--qu'ils peuvent le faire à l'insu de l'utilisateur, même averti.

Chiffré et pas crypté. Et ya rien de chiffré dans un cookie, il y a au mieux un codage, au pire un hash.

[souviron34]

Enfin, ce que je voulais dire, c'est que entre les cookies et les procédures .js stockées, il y a pléthore de "cochonneries" qui passent, éventuellement restent, et que tout ceci non seulement n'est pas propre, est dangereux, et est une faute de conception de fond (sans parler d'une erreur de fond par rapport à la philosophie du Web : afficher de manière "similaire" et formalisée un contenu).

C'est de la "facilité" de programmation, qui cache une mauvaise conception, et/ou éventuellement un manque dans le protocole.

Mais de tout ce que je vois je pense simplement très nettement plus à une mauvaise conception de base...

Qui entraîne des dérives très perturbantes sur des utilisations non souhaitées(pub), voire dangereuses (profilage).

[Marco46]

Enfin, ce que je voulais dire, c'est que entre les cookies et les procédures .js stockées, il y a pléthore de "cochonneries" qui passent, éventuellement restent, et que tout ceci non seulement n'est pas propre, est dangereux, et est une faute de conception de fond (sans parler d'une erreur de fond par rapport à la philosophie du Web : afficher de manière "similaire" et formalisée un contenu).

Ta définition du web c'est la définition du web 1.0

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.

Après que cette évolution aurait peut être du se faire en revoyant l'ensemble c'est possible, personnellement j'en sais rien, mais parler d'erreur de conception alors que tu te trompes de cible je trouve ça un peu fort quand même.

Ceci dit, compte tenu du fonctionnement de la publication des normes du net, c'est à dire une série d'organismes publiant des recommandations que chacun est libre de suivre ou pas, il est difficile d'envisager une refonte de la conception générale. On est bien obligé de bâtir sur l'existant. Et comme il n'y a pas d'autorité centrale ...