racine uZine

Dans la même rubrique
Le coin des débutants
7 juillet 2002
28 mars 2002
20 février 2002
13 septembre 2001
15 septembre 2000
11 septembre 2000
 
dimanche 29 avril 2001

Les cookies (leur vie, leurs moeurs)

Version « tout va bien »
par Lefayot
 

Pour des raisons qui relèvent de la théorie du complot (je fais partie des initiés), il est de bon ton d’adopter un ton techno-paranoiaque vis à vis de l’internet et de ses technologies secrêtes. Ainsi des cookies qui ont été accusés d’à peu près n’importe quoi ; de fliquer les internautes, de fournir des informations ultra-confidentielles à des vilains sites marchands, etc …

Nous allons dans cet article essayer d’expliquer quelle la fonction d’un cookie, et chacun verra qu’il n’y a pas de quoi se faire des cheveux blancs, bien que des dérives soient toujours possibles, ce qui est de toute façon le cas de toutes les technologies.

Pour comprendre ce qu’est un cookie, il faut en revenir à la base, c’est à dire au HTTP [1]. Le HTTP est le protocole qui s’établit entre un navigateur et le serveur web en face.

Ainsi lorsque le navigateur désire afficher une page, il envoie une commande au serveur (commande GET + le nom de la page), commande qui est récupérée par le serveur, lequel renvoie la page toujours suivant le protocole HTTP.

Nous n’allons pas entrer dans le détail, mais il est important de comprendre une chose : lorsque le navigateur veut afficher une page il accomplit les tâches suivantes :

  • Il ouvre une connexion réseau (en pratique il ouvre une socket)
  • Il envoie la commande GET pour obtenir la page
  • Il récupère les données que lui envoie le serveur
  • Il ferme la connexion.

Ainsi à chaque page qu’il veut afficher, il est obligé d’effectuer cette même séquence. Cela à pour conséquence que s’il veut afficher une page 2 à la suite d’une page 1, le serveur n’a aucune chance de savoir que c’est le même navigateur qui veut faire cette opération. A chaque fois, on repart de zéro.

Le HTTP est dit stateless (sans état), car le serveur ne garde pas la mémoire des états précédents et est incapable d’associer une série d’opérations à un navigateur particulier, et donc à un utilisateur donné.

Prenons un exemple : vous utilisez une messagerie web type Hotmail. La page 1 est constituée par la page de login (avec le login et le mot de passe à rentrer), la page 2 par la liste des messages. D’après ce qui a été dit précédemment lorsque le serveur devra afficher la liste des messages, il ne saura pas que c’est l’utilisateur machin qui a entré ses coordonnées sur la page 1, et ne pourra donc pas afficher les dits messages.

C’est très gênant. Le HTTP est incapable de gérer la notion de session. Une session est l’intervalle de temps qui sépare une connexion d’une déconnexion. Lors d’une session, le navigateur (donc l’utilisateur) est reconnu par le serveur de manière unique. Ainsi dans le cas de la messagerie web, si machin se connecte, il ouvre une session : quand il parcourt les pages suivantes, il est reconnu comme étant machin, et le serveur peut lui afficher les messages qui lui sont associés, ses paramètres, bref ses données en général.

D’une manière générale, tous les sites qui demandent une identification au démarrage doivent gérer la notion de session. Or le HTTP ne la gère pas. Il faut donc ajouter un truc au HTTP. Ce truc, c’est le cookie.

Le principe est le suivant : les données de session (typiquement, le login et le mot de passe) sont stockées quelque part sur le serveur, et sont repérées par un identifiant unique. Cet identifiant est codé dans le cookie. Lequel cookie est renvoyé avec la page qui suit celle d’identification. Jusqu’à ce moment là, le cookie n’est qu’un bout de code dans le flux HTTP de retour. Lorsqu’il reçoit le cookie, le navigateur le stocke sur disque. Et c’est tout.

Ensuite, à chaque demande de page par la suite (avec une commande GET, donc), le navigateur enverra en plus le continu du cookie vers le serveur. Oh miracle ! Le contenu du cookie est l’identifiant unique, associé à l’utilisateur. On peut donc le reconnaître, et donc afficher les données qui lui sont associées ; dans le cas de la messagerie web, c’est la liste de ses messages, par exemple.

Ainsi, bien démystifié, le cookie apparaît pour ce qu’il est tout banalement dans 95% des cas : un simple outil technique pour assurer une session.

Mais va-t’on me demander : un cookie est-il bien nécessaire pour identifier l’utilisateur ? Son adresse IP n’est-elle pas suffisante ?
Non, et ce pour au moins 2 raisons :

  1. D’abord la majorité des utilisateurs passent par le RTC (téléphone) et donc ont des adresses IP dynamiques. La session pouvant être maintenue entre deux appels téléphoniques, les adresses IP peuvent changer, et tout est perdu. Une déconnexion au niveau de la session n’est pas la même chose qu’une déconnexion téléphonique, ne confondons pas !
  2. Ensuite les gens qui se connectent depuis leur boulot sont souvent derrière des proxy et du point de vue du serveur ont tous la même adresse IP (du moins ceux qui bossent au même endroit).

Il y a donc nécessité de véhiculer entre le serveur et le navigateur, l’identifiant unique de la session.

Il est vrai que l’on n’est pas obligé d’utiliser la technique du cookie pour faire cela. On pourrait au moins soit passer cet identifiant par codage d’URL, soit le passer dans un champ caché de chaque page. Je ne vais pas rentrer dans le détail, mais disons que ces techniques sont assez contraignantes, et laborieuses. Elles présentent aussi des inconvénients au niveau de la sécurité.

Car il ne faut pas oublier une chose : les programmes sont écrits par des programmeurs, c.a.d, majoritairement des gens paresseux et pas toujours très bons techniquement [2]. Ils n’ont pas envie de se casser la tête, d’autant que les langages de programmation et/ou les outils pour développer des sites web gèrent la session par cookie de manière complètement transparente.

Ceci explique la profusion de cookies, et pourquoi certains sites ne fonctionnent carrément pas si vous choisissez de refuser les cookies sur votre navigateur.

Vous voyez donc qu’il n’y a pas vraiment pas de quoi en faire un fromage. La police de la pensée, elle ne passera donc pas par-là.

A une prochaine pour les séances didactiques du professeur Lefayot.


Notes

- [1] Avis aux gardiens du temple qui lisent les RFC dans le texte : ce qui suit est evidemment un modèle plutôt simplifié de la réalité. Le présent article se vise qu’à une vulgarisation bon enfant.

- [2] Ce qui explique les failles de sécurité dont certains sites font leur fond de commerce. Il ne s’agit pas d’un complot, mais d’un manque de professionnalisme et/ou de talent, un peu comme lorsque le garagiste oublie de changer les plaquettes de frein lors d’une révision générale.
 
 
Lefayot
Imprimer
format impression

tueur en scierie

20 février 2002
 
SPIP
Web indépendant


> Les cookies , trojan
17 janvier 2002, message de Dr_Brown
 

y a t’il un risque pour qu’un cookie se transforme en trojan ?
de +
si vous pouvez m’aider, pouvez vous me donner de info sur RUN.EXE dans c:windows , presque tout les programme semble l’utiliser pour fonctionner cependant personne n’a ce fichier !! je voulais savoir si s’était un troyen

merci

Répondre


Gentil, pas faux techniquement, mais un peu court
2 mai 2001, message de Yann Schwartz
 

Les cookies sont théoriquement liés à un serveur donné. Le serveur ne peut lire que les cookies qu’il a posé. A priori, donc, on ne peut tirer partie des informations posées par d’autres sites.

Sauf que.

Les régies publicitaires et les marketeux fous utilisent parfois une technique simple pour tracer un profil d’un internaute X.

Supposons que sur la page d’accueil de www.grossesnaines.com il y ait référence à un petit truc, une image de 1pixel par 1 pixel par exemple, qui se trouve sur www.bigbrother.com.

Quand l’internaute X charge la page de www.grossesnaines.com, son navigateur appelle l’image sur www.bigbrother.com. Suffit que cette image soit un script, ou que le serveur soit configuré pour poser un cookie (provenant de bigbrother) sur le navigateur comportant un identifiant unique, attribué à X et à lui seul - ou pour lire un cookie précédemment posé. Si l’adresse de l’image est paramétrée (src="www.bigbrother.com/fuck.jpg?source=grossesnaines" par exemple) le site de bigbrother sait où est passé l’internaute.

Supposons maintenant que X se rende ensuite sur www.beauxbruns.com qui fait référence à la même image, paramétrée différemment, bigbrother sait alors que X (identifié uniquement) est un(e) internaute appréciant les grosses naines et les beaux bruns.

Si X a en plus donné son adresse mail, ou plus, à www.beauxbruns.Com, un gentil échange de bons procédés entre beauxbruns et bigbrother permet de "profiler" nominalement un internaute.

Pour que ça marche, il faut évidemment un accord entre bigbrother et les sites. Mais ces derniers sont tellement désespérés pour gagner de l’argent qu’ils pourraient hésiter à cracher sur une des seules choses qui rapportent de l’argent sur Internet (et encore) les fichiers nominatifs de marketing.

Répondre


> cher TTdearteacher
30 avril 2001
 

Quid des mystérieux dossiers, inaccessibles (virtuels ?) dans "windows\temporary internet files" ?

Répondre
> cher TTdearteacher, lefayot, 30 avril 2001

A vrai dire c’est au choix :

- Un signe patent que les Atlantes sont encore parmi nous.
- Les assassins de Kennedy
- Une méthode pour les terroristes du Hamas pour endoctriner le bon peuple de France.

Tu peux toi-même trouver plein d’autres idées et même ecrire des livres qui font vachement peur où on explique que nous sommes controlés/fliqués/épiés. N’hesite pas à m’en envoyer un exemplaire.

Répondre
> cher TTdearteacher, Rael Wolton, 1er mai 2001

Ah ! Ne déflore pas le sujet de mon prochain livre ! Tu sais comme la concurrence est rude.

Répondre


A côté du Referer : (sic) les cookies c’est de la pisse de chat
30 avril 2001, message de Zorglub
 

Si les cookies posent quelques
petits problèmes d’intimité,
en particulier ceux qui sont persistants
et ceux qui sont gracieusement "échangés"
entre divers sites, il y a un mécanisme
dont, bizarrement, personne ne parle,
alors qu’il révèle bien plus de choses.
J’ai nommé l’en-tête HTTP "Referer :".

Votre navigateur favori a la mauvaise
habitude, lorsque vous cliquez sur un
lien se trouvant sur une page A sur un
site X et pointant vers une page B
sur un site Y, d’envoyer,
lors de la requête de la page B,
l’addresse de la page A au serveur de Y.

Autrement dit, lorsque vous êtes sur
le site de la Fraktion Armée Rouge
et que vous cliquez sur un lien
pointant vers les renseignements généraux,
le serveur ouèbe des renseignements
généraux va, en principe, enregistrer
dans son fichier de journalisation
une ligne du type

"Le jeudi 44 Mai 2039, un zigoto ayant
l’addresse IP 1.2.3.4 a demandé la page
index.html en cliquant sur un lien situé
sur la page
http://www.fraktion-armee-rouge.com/produits/revolution.asp".

Le moyen de s’en débarasser ? Installer
un proxy du genre Junkbuster. Pour ma part,
j’ai trafiqué le proxy de façon à ce qu’il
transmette de referrers bidon du genre
http://www.fist-fuck.free.edu/~hitler/query.vb.

Ah oui, on ne le rappellera jamais assez,
Junkbuster a aussi l’avantage de censurer
la pub (propagande ultralibérale brainwachante).

Répondre
> A côté du Referer : (sic) les cookies c’est de la pisse de chat, 30 avril 2001

Le moyen de s’en débarasser ? Installer un proxy du genre Junkbuster. Pour
ma part, j’ai trafiqué le proxy de façon à ce qu’il transmette de referrers
bidon du genre http://www.fist-fuck.free.edu/ hitler/query.vb.

Ah oui mais comme t’es le seul à le faire, on sait que c’est toi !
Pour infos, on voit effectivement régulièrement des milosevic.gouv.mil dans
les stats uzine. Maintenant je sais d’où ça vient...

a+

Antoine.

Répondre
> A côté du Referer : (sic) les cookies c’est de la pisse de chat, Zorglub, 30 avril 2001

Oui, on m’avait déjà dit que si j’étais le seul zigoto
à faire ce genre de choses, je me ferais repérer. Paranoiaques,
unissez-vous ! Que ceux qui veulent le patch pour Junkbuster m’écrivent.
Plus nous serons é brouiller le fichage HTTPien, moins les webmestres
vendus au capitalisme feront confiance au champ Referer de leurs logs
qui sera finalement supprimé.

Répondre
> A côté du Referer : (sic) les cookies c’est de la pisse de chat, lefayot, 30 avril 2001

Putain c’est l’enfer !

On peut savoir d’où que je viens lorsque j’arrive chez www.minirezo.net. Gasp !

Sur que tous les fichiers referer sont compilés, soumis à Echelon et qu’on arrive ainsi à etablir une fiche signalétique de chaque individu de le monde entier.

Quant à se passer les cookies d’un site à l’autre, c’est bien inutile, le cookie ne contenant qu’une reference à des données stockées sur le site, qui peut de toute façon les vendre de maniere beaucoup plus simple (voir le terrifiant episode II des cookies).

Une question : à quo sert ce genre de delire parano ? A s’imaginer etre quelqu’un de very important que les centrales de rensignement brulent de vouloir fliquer ?

Je brule aussi de savoir ...

Répondre
J’insiste : Les cookies ne sont pas tous inoffensifs mais les "Referer" eux le sont, Zorglub, 1er mai 2001

Non mais sérieusement, les Referer posent des problèmes assez graves :

1) Si l’addresse de la page sur laquelle se trouve le lien contient
des données sensibles (genre login / password pour interface CGI en
méthode GET) ces données seront transmises au site.

2) Un autre effet pervers est que lorsque vous utilisez un moteur de
recherche, et que vous cliquez sur un lien résultant, le site de
destination connaîtra les mots-clés que vous avez utilisé. Cela permet
notamment aux sites de l’autre côté de la barricade de faire du
"tuning" sur des mots-clés peu pertinents mais courants.

3) Soit X quelque chose regroupant des individus par intérêt.
Supposons que l’on fasse un site anti-X, sur le quel, pour
documentation, on donne des liens vers des sites pro-X. Alors à chaque
fois qu’un X-subversif cliquera sur un tel lien, le site pro-X saura
qu’un subversif vient visiter son site. Ainsi, le lobby des pro-X
pourra savoir quels sont les sites subversifs, et déduire des
informations annexes, du genre : l’évolution du taux d’activité des
X-subversifs. Tout cela grâce au Referer. Par exemple, supposons que
l’on fasse un site anti-scientologie. Si par malheur on met des liens
vers scientology.org, on pourra éventuellement recevoir des appels de
menaces de procès, comme c’est l’usage de la secte.

4) Mais à quoi sert au juste le Referer ? Le fait est que l’on peut
très bien s’en passer. Pour preuve, lorsque je supprime le Referer,
tous les sites continuent de fonctionner normalement, sauf de rares
exceptions où des mesures actives ont été prises pour empêcher le
référencement de données internes par des sites externes. Evidemment,
comme c’est l’utilisateur qui décide ce qu’il met dans Referer : la
contre-contre-mesure est triviale. Donc puisqu’il ne sert à rien
d’utile, pourquoi le garder ?

En bref, le Referer sert surtout aux Webmestres à la solde du
capitalisme à mieux mesurer l’origine du trafic incident, avec toutes
les applications commerciales que cela pourrait avoir.

D’après les lemmes 1,2,3 et 4 on en déduit que le Referer est MAL.
En conséquence de quoi il incombe à toute personne oeuvrant pour
le Progès et le Bien de l’Humanité de prendre les mesures adéquates,
à savoir, installer un filtrapub genre Junkbuster (c’est de l’opensource
hein !), et le configurer de façon à cacher les Referer.

On voit donc que la haine du Referer n’implique nullement une Echelonite
aiguë. D’ailleurs votre fournisseur d’accès en sait beaucoup, beaucoup
plus sur votre vie privée. Et de toute façon dans la plupart des pays
les flics branchent des tuyaux sur les fournisseurs d’accès, parfois
ouvertement, n’est-ce pas ? Donc croire que l’on échappera à un Echelon
quelconque en installant un filtre de ce genre c’est comme croire
que la NSA ne pourra pas décrypter vos mail parce que vous les avez
écrit avec du jus de citron.

PS.Referer s’écrit avec deux "r", le RFC comporte une faute, raison
de plus pour les supprimer !

Répondre
> J’insiste : Les cookies ne sont pas tous inoffensifs mais les , patator, 1er mai 2001

Prenons les problèmes un par un...

1) Dans ce cas le _site_ est mal conçu. Imagine que tu bookmarkes l’adresse sur ton ordinateur au travail, ton mot de passe et login ne seront pas protégés non plus. La majorité des formulaires avec un password se passe en POST.

2) Tu visites alors un site commercial, dont la vocation est de faire de la thune, donc d’essayer d’attirer un max de personnes possibles... Je ne vois pas où est le mal. D’autant plus que tu es libre de ne pas le visiter. Et as tu imaginé que ça puisse rendre service aux clients du site, qui le trouvent dès lors plus facilement ?

3) Je pense que les sites genre scientologie sont soit au courant, soit s’en foutent. Et si tu veux vraiment contrer ça, tu peux mettre un lien vers une page hébergée sur (par ex) geocities qui redirige vers le site de scientologie. Mieux encore, tu ne mets pas de lien mais l’adresse du site, que l’internaute devra copier dans sa barre d’adresse.

4) Tout simplement pour savoir par qui on est visité (scoop) ! Les créateurs de sites (surtout les sites perso) sont bien contents de savoir qui linke vers eux, ou, justement, quels mots clés dans les moteurs ont amené des visiteurs... Ca sert également pour "l’anti-leech", ie tu ne peux downloader un fichier que si tu viens du serveur qui l’héberge. Bon ça, ça sert surtout pour les warezeux. De plus ça peut être contré avec un utilitaire de download un brin sophistiqué...

D’après tes lemmes 1, 2, 3, 4 on en déduit que tu es parano. Comme tu le dis toi-même, ton fournisseur d’accès possède TOUTES les informations concernant ton utilisation d’internet. Après on peut évidemment imaginer les machins genre échelon ou carnivore qui t’observent... et qui connaissent du même coup beaucoup plus de ton utilisation du net qu’un simple champ referer.

Bref. On en fait tout un fromage alors que c’est insignifiant. Pour les paranos, au lieu de cliquer sur le lien, vous faites ’copy shortcut’, le collez dans la barre d’adresse, et hop, plus de referer. Dur.

LE truc qui m’énerve sur le net en ce moment sont les applications ’espionnes’ qui s’installent en même temps qu’un autre logiciel (reget par ex), sans prévenir, puis envoient des infos vers leur site. Ca me semble plus dangereux que le referer.

Non, vraiment, t’as des trucs à cacher ? Vas y raconte !

Répondre
> J’insiste : Les cookies ne sont pas tous inoffensifs mais les , 2 mai 2001

Re-salut "patator",

1) Dans ce cas le _site_ est mal conçu. Imagine que tu bookmarkes
l’adresse sur ton ordinateur au travail, ton mot de passe et login ne
seront pas protégés non plus. La majorité des formulaires avec un
password se passe en POST.

La sécurité informatique consiste aussi à éviter de propager,
par ses propres inconséquences, les erreurs des autres.

2) Tu visites alors un site commercial, dont la vocation est de faire de
la thune, donc d’essayer d’attirer un max de personnes possibles... Je ne
vois pas où est le mal. D’autant plus que tu es libre de ne pas le visiter.
Et as tu imaginé que ça puisse rendre service aux clients du site, qui le
trouvent dès lors plus facilement ?

Le spam aussi rend service. Pour l’éviter, il "suffit" de ne donner son e-mail
nulle part en public. C’est tout simple !

Et si tu veux vraiment contrer ça, tu peux mettre un lien vers
une page hébergée sur (par ex) geocities qui redirige vers le site de
scientologie. Mieux encore, tu ne mets pas de lien mais l’adresse du site,
que l’internaute devra copier dans sa barre d’adresse.

Vive la simplicité. C’est marrant cette façon d’accepter qu’on doive prendre
des précautions idiotes plutôt que de dénoncer les pratiques qui nous compliquent la vie.

Bref. On en fait tout un fromage alors que c’est insignifiant. Pour les
paranos, au lieu de cliquer sur le lien, vous faites ’copy shortcut’, le
collez dans la barre d’adresse, et hop, plus de referer. Dur.

Faux, ça ne marche pas avec tous les navigateurs. Cf. autre message.

L’hypothèse
proposée par LeFayot dans son deuxième opus est le ciblage de la
pub, qui a ma connaissance n’a encore zigouillé aucun ordinateur,
ni tué personne

Haha, le génial argument. Je ne vois même pas l’intérêt de venir faire un article
ni troller dans les forums si c’est pour parler de choses "insignifiantes" puisqu’elles
ne tuent pas de gens ni de zigouillent d’ordinateurs.

a+

Répondre
> J’insiste : Les cookies ne sont pas tous inoffensifs mais les , patator, 2 mai 2001

Je donne mon opinion, donc je ’trolle’... brillante déduction. Oui, je pense que le Referer rend plus service plutôt qu’il ne cause de tort.

1) Il faut donc retirer un champ de tous les serveurs & clients HTTP du monde entier car un login et un pass sont passés d’une manière non sécurisée. Hmmm va voir tous les programmeurs internet, on en reparle.

2) Décidément tu as trop tendance à généraliser. Je donne mon opinion sur les Cookies et le Referer, soudain je suis accusé d’être un partisan de techniques commerciales à deux francs.

>lien geocities : c’est un exemple. D’ailleurs, je pense que les scientologues connaissent les moteurs de recherche. Là non plus je ne suis pas partisan de gicler le Referer car il n’emmerde que qq internautes.

>copy shortcut : je n’ai testé que sous IE.

>dernière remarque : Oui, je pense que les cookies sont insignifiants. J’ai l’impression d’assister à leur mystification, juste pour satisfaires des personnes en mal de légendes internetiennes.

D’ailleurs, tu dis que tu mates les logs du minirezo, et donc le champ ’Referer’. Pourquoi ne recompiles tu pas ta version d’Apache afin de ne pas logger ce champ qui viole tant la vie privée des internautes ?

Maintenant, si tu as des arguments anti-cookies ou anti-referer autres que des questions évasives sur la sécurité informatique en général, je t’en prie, balance !

Répondre
> J’insiste : Les cookies ne sont pas tous inoffensifs mais les , 2 mai 2001

1) Il faut donc retirer un champ de tous les serveurs & clients HTTP
du monde entier car un login et un pass sont passés d’une manière
non sécurisée. Hmmm va voir tous les programmeurs internet, on
en reparle.

On parle de l’utilité du referer, et tu divagues sur la difficulté de
l’enlever : hors-sujet.


D’ailleurs, tu dis que tu mates les logs du minirezo, et donc le
champ ’Referer’. Pourquoi ne recompiles tu pas ta version d’Apache
afin de ne pas logger ce champ qui viole tant la vie privée des
internautes ?

1) parce que je ne suis pas foutu de le faire, 2) parce que je n’ai pas accès au serveur,
3) parce que j’ai pas que ça à foutre (notamment, il faut que je réponde à des guignols
comme toi).

Maintenant, si tu as des arguments anti-cookies ou anti-referer
autres que des questions évasives sur la sécurité informatique en
général, je t’en prie, balance !

Qu’est-ce qui est évasif, de parler de sécurité informatique ou de balancer
des arguments à la mords-moi-le-noeud du genre "de toute façon y a pas
mort d’homme" ? Ce n’est pas ma faute si ta contribution est du niveau
d’un trolleur de forum sur jeboycottedanone.com, hein....

ciao, pas la peine de continuer, cher "patator" (t’aurais pu garder ton
pseudo habituel, tu sais)...

Répondre
> A côté du Referer : (sic) les cookies c’est de la pisse de chat, plam, 1er mai 2001

J’ai une question concernant les referers. Quand on clique sur un lien, le serveur hebergeant la nouvelle page affichee peut connaitre l’URL precedente. OK
Mais est-ce le cas si je ne clique pas sur un lien mais decide d’ecrire "a la main" dans la barre d’adresse une nouvelle URL. Dans ce cas (pas de clique, simplement ecrire l’adresse dans la barre du meme browser), le referer marche-t-il ?

plam

Répondre


> Les cookies (leur vie, leurs moeurs)
30 avril 2001
 

Mouais, si 95% des cookies sont de simples outils techniques pour assurer les sessions, les autres 5% ils font quoi ? J’ai 383 cookies sur mon disque, donc une petite vingtaine (à la louche lefayot) qui font qu’est-ce ? C’est bien ça le problème non ? A part ça tout va bien rassurez-vous. Ouaf.

Répondre
> Les cookies (leur vie, leurs moeurs), lefayot, 30 avril 2001

Les 5% restant ....

Mmmh ...

Je crains de decevoir mes fans, mais je crains que ce ne soit des erreurs de programmation, des trucs dont on croyait que ce serait the Killer Hidden Tool, mais qui ne servent à rien, voire des trucs de debug/demo qu’on a oublié d’enlever.

Eh oui ! Quand on ne connait pas le monde merveilleux de la programmation, on s’imagine que des choses, et en particulier que tout est pensé et bien conçu. D’ailleurs un scoop : à l’époque où il fallait tout faire à la mimine, j’ai inséré sur un site un cookie (à titre de demo/debug) qui contient "je suis une grosse bille" à l’intérieur (ça ne sert d’ailleurs strictement à rien) ; je crains qu’il n’y soit encore si on n’y a pas le menage (ce qui est plutot rare). Dieu sait ce qu’un parano-pro peut s’imaginer en lisant "je suis une grosse bille" dans un cookie :)) ...

Répondre
> Les cookies (leur vie, leurs moeurs), 30 avril 2001

Décidément, la posture du vieux con blasé qui sait tout te va à ravir.
C’est sûr, allez hop, c’est sûrement des erreurs de programmation,
on va pas se faire chier, d’ailleurs on peut certainement tout
expliquer comme ça, dans tous les domaines de la vie.

Non, sérieusement, JC, à part te la jouer grand maître des secrets du net,
qu’est-ce que t’espères en sortant des âneries pareilles ? On croirait une
sous-parodie de Zipiz par un journaliste de Technikart.

a+

Antoine.

Répondre
> Les cookies (leur vie, leurs moeurs), lefayot, 1er mai 2001

Tu me parais bien énervé, my dear Antoine. C’est d’autant plus étonnant que tu es de la partie et qu’à priori tu ne fantasmes pas sur le monde mystérieux et secret de l’informatique.

Moi je veux bien qu’il y ait des raisons hyper rusées à la présence de cookies "inexplicables", mais dans ce cas, donne moi les raisons, je ne demande qu’à apprendre.

D’ailleurs à examiner certains cookies, on ne peut être que dubitatif devant une eventuelle utilité (lire le cookie.txt de netscape est edifiant de ce point de vue là). Quant à "erreur de programmation", c’est toi qui simplifie et interprete ; j’y vois plutot des raisons historiques (un truc qui servait à qchose en version x, et plus en version x+1 et qu’on n’a pas enlevé), des trucs de debug qu’on n’a pas enlevé non plus, etc ... Du tres classique en matiere de production informatique, comme tu devrais le savoir. Evidemment, tu bosses peut-etre dans une boite avec une cellule qualité de la mort et de la certification ISO 900x dans tous les coins. Je n’ai pas eu cette chance, et des anecdotes comme celle que j’ai citée, je pourrais en ressortir d’autres.

Evidemment, tu as peut-etre des scoops que je n’ai pas, mais - comme je l’ai dit - je ne demande qu’à savoir.

Enfin, j’ai donné un début d’explication pour les cookies inexplicables (super, on dirait un titre pour une emission de Pradel) dans "les cookies, part II".

Vas-y un peu plus mollo dans ta ferveur evangélisatrice :-)

Lefayot

Répondre
> Les cookies (leur vie, leurs moeurs), patator, 1er mai 2001

(Ce commentaire est 100% personal diatribes free, youpi)

Histoire d’apporter de l’eau au moulin sur les ’tests’... Sisi, ça existe. Je suppose qu’il faut avoir programmé pour comprendre ça : ie pourquoi il marche pas mon cookie ? essayons avec un truc plus simple, une phrase de test à la con... je sais, je l’ai fait moi aussi (juste sur mon site perso). C’est pas resté par contre :)

Tiens, à titre d’exemple, sur loftstory.fr (no comment :)) ... le cookie est de la forme

Cookie : testcookie=OK ; WSINFOS=monadresseipdns + un charabia de signes divers & variés.

Si c’est pas du TEST ça... testcookie=OK, ça doit justement être une relique d’un test à la con : on peut tester s’il y a un cookie directement avec les variables du serveur. Quant à monadresseipdns (de la forme AMaVille.abo.wanadoo.fr), on peut également l’obtenir à partir des variables du serveur.

Reste la chaîne cryptique de caractères qui suit tout ça ... qui peut être un indicateur de session.

Répondre
> Les cookies (leur vie, leurs moeurs), 1er mai 2001

Histoire d’apporter de l’eau au moulin sur les ’tests’... Sisi, ça existe. Je
suppose qu’il faut avoir programmé pour comprendre ça : ie pourquoi il
marche pas mon cookie ?

Bien sûr que ça existe, mais se targuer d’expliquer ce sur quoi on n’a aucun info
en disant simplement qu’il s’agit de tests, c’est idiot et prétentieux. A ce compte-là,
les spywares, les trous de sécurité, le fait de pouvoir propager des virus par mail
avec outlook express, c’est des tests et on n’en parle plus....

a+

Antoine.

Répondre
> Les cookies (leur vie, leurs moeurs), patator, 2 mai 2001

Keep cool : on ne parle que des cookies, là. Je voulais simplement dire que ces tests existaient, et qu’ils étaient peut-être plus répandus qu’on ne le pense. Car franchement je ne vois pas bien ce qu’on pourrait stocker dans un cookie qui serait ’mal’.
L’hypothèse proposée par LeFayot dans son deuxième opus est le ciblage de la pub, qui a ma connaissance n’a encore zigouillé aucun ordinateur, ni tué personne.

Répondre
> Les cookies (leur vie, leurs moeurs), lefayot, 2 mai 2001

C’est aussi mon avis (que les cookies ne risquent pas de contenir grand chose). Comme expliquer dans l’opus II, il ne peut finalement contenir que :

- Des données implicitement données par l’internaute : sa navigation en gros.
- Des données explicitement données par l’internaute.
- Et au final des données qui se trouvent déjà dans la BDD du serveur.

Répondre