Cela fait quelques temps que je m’interroge sur le modèle de sécurité du web actuel, basé sur la politique de même origine. J'aimerais proposer un modèle de sécurité différent, qui pourrait rendre beaucoup plus robuste les applications web. Mais il faut la coopération des navigateurs. Voici mon idée:
Petit résumé de la situation
A l'heure actuelle, une page web n'a pas le droit de faire une requête XmlHttpRequest sur un autre domaine. Par exemple, si example.com essaye de charger facebook.com via XmlHttpRequest, la requête échoue. A juste titre, parce que si jamais elle réussissait, example.com aurait accès aux informations privées de mon compte Facebook (je sais, il n'y a pas grand chose de privé sur Facebook, mais imaginons ...).
Maintenant, rien n'interdit example.com d'avoir un tag <img> ou même <iframe> vers facebook.com. Couplé avec des analyses de la page en JavaScript, il est possible de récupérer des informations en provenance de Facebook. Les navigateurs essaient par tous les moyens possibles de rendre cette frontière la plus étanche possible, mais on imagine facilement qu'avec des nouvelles fonctionnalités ajoutées à JavaScript, de nouvelles failles peuvent facilement voir le jour.
Un exemple simple, vous avez dans la page un tag <img> vers une image sur facebook.com, et que la taille de cette image soit différente selon que l'utilisateur est connecté ou non à Facebook. Alors n'importe quel site, en regardant la taille de cette image, pourra savoir si l'utilisateur est connecté à Facebook ou non.
Et on peut imaginer d'autres exemples, et d'autres failles avec des fonctionnalités futures de JavaScript.
Comment en est-on arrivé là ?
Tout remonte à mon avis à l'invention des cookies. Les cookies sont des informations que le serveur peut stoker dans le navigateur et qui peuvent servir à l'identifier lorsqu'il revient sur le site. Les cookies ajoutent au protocole HTTP une notion d'état ou de session qui avait été volontairement omise à la création du protocole.
Pouvoir garder une session sur un site web est utile me direz-vous. Mais par contre, il n'y a pas de raison que lorsque vous regarder une page sur example.com, il n'y a aucune raison que les serveurs de publicité gardent une session. Et encore moins que la session des serveurs de publicité soit la même pour tous les sites que vous regardez.
Ainsi, un serveur de publicité, sais exactement quels sites vous visitez.
La session n'a de sens que pour la page que vous êtes en train de regarder, et de manière exceptionnelle, pour un cadre (frame) contenue dans cette même page.
Une solution à cela ?
La solution à laquelle je pense est très simple, mais pourrait casser quelques sites web qui utilisent le login facebook ou autre. Jusqu'à une mise à jour de ces sites ...
J'aimerais beaucoup que la session soit différente pour chaque onglet ou chaque fenêtre de navigateur ! Je m'explique...
Vous regardez example.com. Ce site veut stocker un cookie, le navigateur stocke le cookie dans une nouvelle session associée à ce site et à cet onglet. Il vous l'indique de manière non intrusive dans la barre d'adresse. La page que vous visitez contient aussi une publicité du serveur adserver.net qui vous donne un cookie. De la même manière, le navigateur accepte le cookie, crée une session pour le serveur adserver.net et cet onglet précisément, et vous laisse consulter l’existence de cette session dans les propriétés de la page.
Vous ouvrez un nouvel onglet vers example.net, votre navigateur crée une session example.net avec le 2e onglet. example.net a aussi une publicité de adserver.net. Une nouvelle session adserver.net est créée pour le 2e onglet.
Vous avez donc maintenant deux sessions adserver.net. Une différente pour chaque onglet. adserver.net ne peux plus vous suivre à la trace.
Vous ouvrez un 3e onglet vers example.com, le premier site. Ce sera à votre navigateur de choisir si il vous crée une nouvelle session (cela doit être possible) ou si il réutilise la session du 1er onglet. Dans tous les cas, la publicité du 3e onglet vers adserver.net sera dans une 3e session séparée.
mais, que se passe-t-il pour les cookies qui ont une durée plus longue que la session ? Ils sont stockés, mais il appartient à l'utilisateur d'associer cette ancienne session à une nouvelle page.
Maintenant, le 2e onglet de example.net avais un bouton Login par Facebook. Ce contenu de facebook.com va chercher à récupérer les cookies d'une session précédente de Facebook pour vous connexter sur example.net. Pour ce faire, soit via JavaScript, soit via un en-tête HTTP, facebook va demander à votre navigateur d'ouvrir une session existante. Deux cas se présentent :
- Vous avez une session facebook existante (dans une autre fenêtre), votre navigateur vous propose de donner accès à votre session facebook au serveur example.net
- vous n'avez pas de session facebook, une nouvelle session est créée.
Pour résumer
- Tout chargement d'objet crée une nouvelle session, ou la reprise de la session du Referrer
- L'utilisateur peut associer une session pré-existante à un objet manuellement. Cet objet est alors rechargé avec les cookies de la session précédente
- Une page peux demander spécifiquement l'ouverture d'une session pré-existante. L'utilisateur peux alors en choisir une. Les sessions correspondant à des onglets de premier niveau sont présentées en premier, ensuite viennent les session demandées de manière spécifique, et enfin les autres sessions.
- A l'ouverture d'une nouvelle page, le navigateur peut proposer d'ouvrir une session existante, ou de le faire par défaut, selon les préférences de l'utilisateur
Conclusion
Quels sont vos avis sur cela ? Pensez-vous que j'ai une chance de faire passer cette vison des choses ?
# Plugin firefox (ou autre ? :)
Posté par Victor . Évalué à 4.
Cette proposition a le mérite de pouvoir s'implémenter du côté navigateur seulement.
Un prototype permettant de vraiment l'expérimenter serait pas mal, parce que à la lecture ça semble bien.
Mais je me demande dans quelle mesure ça ne va pas être super galère de surfer, surtout qu'on aura des politiques différentes selon les sites, ou selon la raison de l'existence de la session…
[^] # Re: Plugin firefox (ou autre ? :)
Posté par Mildred (site web personnel) . Évalué à 4.
Pour surfer, ça ne devrait pas être gênant. Sauf si tu tiens à voir tous tes amis facebook sur n'importe quelle page.
dans certaines versions de Firefox (au hasard, entre la 4, la 5 et la 6) il y a une petite icône dans la barre d'adresse avec une paire de clefs qui indique si on est authentifié sur un site ou pas. Je propose le même principe pour indiquer que le site web garde une session.
Si on clique, on peut choisir d'arrêter la session ou d'associer une autre session à la place.
J'aimerais bien faire un plugin, mais je n'ai jamais fait de plugin Firefox ... et je pense que modifier toutes ces interactions risque d'être assez invasif.
A mon avis, ça pourrait être une solution efficace contre le XSS, qu'en pensez-vous ?
[^] # Re: Plugin firefox (ou autre ? :)
Posté par mxs (site web personnel) . Évalué à 1.
J'ai du mal à voir comment cela serait efficace contre les XSS vu que le code malicieux serait dans tous les cas chargé et executé à l'ouverture de l'onglet, peut-être parlais tu des CSRF qui dépendent directement de la session.
Je ne sais pas si c'est une bonne idée mais peut-être n'ai-je pas tout compris. Si on crée une session par onglet, il risque d'y avoir parfois des problèmes sur certains sites, et pas uniquement aux niveau des Facebook connect et cie : par exemple si un site garde le contenu du panier dans la session, il y aura un panier différent par onglet, ce qui n'est pas forcément ce que veut le serveur en face ni l'utilisateur. Il faudrait alors revoir sa façon de surfer ou re-développer plein de sites pour qu'ils n'utilisent la session que pour l'authentification d'un utilisateur, et rien d'autre. Et si c'est le cas, ça demanderait collaboration des sites et des utilisateurs, mais on essaye de protéger l'utilisateur de sites malicieux, et on ne peut compter sur leur collaboration. Aussi, rien n'empêche à un site au courant de cette technique de traquer l'utilisateur avec des publicités en rajoutant un ID lié à l'utilisateur dans chaque lien i-frame ou autre.
[^] # Re: Plugin firefox (ou autre ? :)
Posté par VictorAche . Évalué à 1.
Il faut être capable d'autoriser certains cookies (au hasard, le panier) à être appelés depuis un autre onglet, non ? Ou au moins permettre de les lier manuellement.
(c'est un peu compliqué pour moi, pas sur d'avoir tout compris).
"The trouble with quotes on the internet is that it’s difficult to discern whether or not they are genuine.” Abraham Lincoln
[^] # Re: Plugin firefox (ou autre ? :)
Posté par patrick_g (site web personnel) . Évalué à 8.
Plus simple: refuser par défaut tous les cookies et ne les autoriser que sur certains sites bien précis. On se fait pas trop chier et on surfe l'esprit tranquille.
[^] # Re: Plugin firefox (ou autre ? :)
Posté par blobmaster . Évalué à 4.
Pas d'accord.
J'ai essayer de faire ça un moment et ça ma vite fait chier.
En plus il y a des sites qui se bloquent si les cookies sont désactivés.
Du coup pour savoir si le site est bien il faut activer les cookies et si tu le fais définitivement il faut penser à les désactiver si finalement le site est nul et si tu le fais provisoirement il faut le refaire et penser à le faire définitivement cette fois là don il faut se souvenir que le site est bien ou alors il faut penser à activer les cookies définitivement en allant dans l'interface de configuration des cookies et si tu est en train de chercher un vague truc sur internet il faut le faire toute les 21sec et ça gave.
trop chiant je te dis.
[^] # Re: Plugin firefox (ou autre ? :)
Posté par Marotte ⛧ . Évalué à 1.
Tu dois certainement visiter un maximum de sites en permanence...
Perso, dans mes exceptions pour les cookies j'ai moins de vingt sites autorisés (le reste est interdit)
Ça fait un bye que j'ai pas eu à ajouter d'exception...
Je suppose que ça vient peut-être de moi est de mon incapacité à appréhender une multitude de sites, mais franchement :
sortie de, son site bancaire, google, 3 ou 4 sites de vente en ligne, 2 webmails, 5 ou 6 forums/réseau sociaux, vous les activez pour quel site les cookies ?
[^] # Re: Plugin firefox (ou autre ? :)
Posté par blobmaster . Évalué à 4.
Question :
Réponse :
Je ne sais pas et je veux pas le savoir.
Explications :
C'est pour ceux qui le demandent en disant si t'as pas les cookies le site fonctionnera mal.
C'est peut-être pas vrai, que le site fonctionnera mal, mais comment le savoir...
C'est aussi pour ceux qui disent rien mais qui n'en pensent pas moins.
La différence entre le minitel et internet c'est que dès fois sur internet on trouve mieux que ce qu'on cherchait, parce qu'on ne sait pas ou on va.
Les moteurs de recherche, malgré leur défauts, on au moins la qualité de nous rendre cela simple.
Je ne vois pas ma navigation sur internet comme un petit tour dans le répertoire des mes 3615 préférés. Internet va beaucoup plus loin que ça. Et pour être sur que ces sites (que je ne citeraient pas car, le principe intéressant c'est que, je ne les connais pas tous) fonctionnent de façon optimum il faut les essayer avec les cookies.
Il faut les essayer avec les cookies avant d'être sûr que ça fonctionne sans.
[^] # Re: Plugin firefox (ou autre ? :)
Posté par j_kerviel . Évalué à 6.
J'ai fait la même chose pendant des années également.
J'ai fini par abandonner.
À la longue, ça finit par devenir fatiguant et frustrant. Quel est l'intérêt de gagner de précieuses secondes avec vimperator si c'est pour perdre 10 fois plus de temps avec la gestion personnalisée de cookies ?
Sans compter les informations potentiellement perdues. Après parfois plusieurs mois ou années, je me suis rendu compte que des pages ou des sites présentaient des informations que j'aurais bien aimé trouver et que je n'ai pas eues à cause des cookies.
Depuis, je n'autorise les cookies que pour le domaine que je visite (décocher « autoriser les sites tiers » dans les préférences de Firefox dans « vie privée »).
En plus c'est une option indolore. Presque aucune manipulation à faire dans une utilisation de tous les jours. Donc je peux mettre cette configuration sur la Debian de mon père (la même chose existe pour noscript).
Seul regret, je ne peux conserver les cookies que jusqu'à leur expiration ou jusqu'à la fermeture de Firefox. J'aurais aimé une option me permettant de dire qu'il me conserve le cookie que maximum une semaine. Si je n'ai pas revisité le site entre temps, alors qu'il dégage. Couplé à une liste blanche des sites que je visite souvent, ça peut être très efficace.
[^] # Cookies
Posté par Marotte ⛧ . Évalué à 0.
J'aimerai bien avoir un exemple. Est-ce que si je visite linuxfr.org, sans m'y connecter, avec les cookies désactivés, je vais louper du contenu ?
Oui ya pas mal de site qui te jettent silencieusement, notamment lorsque tu essayes de t'identifier, alors tu te dis "Merde c'est cassé, ça vient de chez moi ou du site ?!" Et puis tu te rapelles "Ah oui ! Les cookies pardi !". Je suis d'accord il faut un moment pour prendre le pli, mais après ça va tout seul.
[^] # Re: Cookies
Posté par Strash . Évalué à 4.
Il parle bien d'"informations" et non pas de "contenu". Tu perds aussi des fonctionnalités.
Exemple: Linuxfr.org
Si tu viens sur Linuxfr.org sans t'y connecter tu vas perdre :
- L'affichage des commentaires que tu as déjà pu lire
- L'affichage du contenu lu/non lu
- La navigation au clavier dans le contenu non lu
- La possibilité de pertinenter le contenu
Et j'en oublie certainement !
[^] # Re: Cookies
Posté par Marotte ⛧ . Évalué à 1.
Sans m'y connecter soit.
Mais entre "pas connecté, cookies activés" et "pas connecté, cookies désactivés" il n'y a pas de différence.
# bonne idée
Posté par sylvaouche . Évalué à -2.
C'est une bonne idée, mais plus pour un mode de navigation sécurisée.
En plus d'être nécessaire pour Vaadin par exemple, qui repose sur un modèle full-serveur. Vaadin ne supporte pas le multi-onglets, car c'est taillé pour de l'applicatif temps-réel en matière d'interaction.
Pour les fenêtres, à la base une fenêtre c'est un programme, mais ils ont fait en sorte il y a déjà quelques années de filer le maximum d'informations à AD* en utilisant les différents moyens technique pour communiquer entre les instances de programme lancées, puis les autre ont imités, et partant de là, l'implémentation des onglets ne gênait plus personne.
Mais juste pour info, les sessions et les cookies ne sont pas tout à fait du même niveau. J'avais fais une petite appli qui gérait la session "à la mano" en écrivant dans le cookie.
Maintenant c'est pas pour vous décevoir, mais ceux qui écrivent le HTML 5 et qui décideront du futur (en terme de realité technique) c'est Microsoft, Google et Facebook...
# JSONP
Posté par Antoine . Évalué à 7.
Oui et d'ailleurs c'est pourquoi beaucoup d'API proposent de retourner du JSON enveloppé par un appel de fonction au nom choisi par l'utilisateur faisant la requête. Le résultat peut ainsi être exécuté (si j'ai bien compris) dans un <script src="...">. Exemple:
# fermer une session http
Posté par Thomas Debesse (site web personnel) . Évalué à 1.
si on doit modifier le navigateur/développer une extension pour gérer ses ssessions cookies, pourquoi ne pas permettre aussi de fermer une session http ? :D
C'est simple mais ça manque.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: fermer une session http
Posté par toof . Évalué à 8.
http est un protocole non connecté !
je ne vois pas ce que tu appelles fermer une session HTTP.
l'application vehiculée par ce protocole utilise des sessions
[^] # Re: fermer une session http
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Je pense qu'il fait référence au fait que Firefox garde le mot de passe HTTP en cache jusqu'à la fermeture du navigateur.
C'est assez pénible quand un site utilise l'authentification HTTP et qu'il n'y a pas de moyen de se délogger.
[^] # Re: fermer une session http
Posté par sifu . Évalué à 1.
Pour info, le plugin web developper permet de remettre à zéro l'authentification HTTP et donc de se délogger.
[^] # Re: fermer une session http
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
oui c'est bien ça, je parle du simple http://user:passwd@example.com (le truc qu'on fait simplement avec un .htaccess par exemple)
Il y a quelques années j'avais eu à subir le webmail exchange, et c'était une session de ce type. Pour consulter plusieurs boites mail, il me fallait fermer toutes mes pages et mes onglets entre chaque connexion… autant dire que c'était très lourd !
Bon aujourd'hui je n'ai plus de lien avec cette horreur, mais il m'arrive encore de croiser des petites bricoles à bases de htaccess, et je me demande toujours pourquoi il n'y a pas un bouton « se déconnecter ».
ce commentaire est sous licence cc by 4 et précédentes
# Login + navigation par onglet
Posté par julo4lfr . Évalué à 8.
Sur pas mal de sites (genre ici), je m'identifie puis j'ouvre les liens du site dans des onglets. S'il me faut accepter à chaque fois la pop-up "voulez vous associer le nouvel onglet avec votre session existante" je vais pas trop aimer...
Bon après rien :
1 - n'empêche de donner une liste blanche d'acceptation automatique ou un truc du genre, mais je ne sais pas si c'est pas rouvrir la brèche que tu cherches à fermer.
2 - de passer l'info lors de l'ouverture du lien (?)
Bref, my 2 cents...
# Naïf
Posté par Bruno Michel (site web personnel) . Évalué à 10.
Je vois deux gros défauts à ce modèle :
Bref, ça pourrait venir en complément du modèle actuel de sécurité mais ça ne le remplacera pas.
[^] # Re: Naïf
Posté par Pseudo007 . Évalué à -2.
Puis côté utilisateur, ça va être un l'enfer pour si retrouver. Mieux vaut se créer un nouveau profile (Firefox le permet).
[^] # Re: Naïf
Posté par Refuznik . Évalué à 3.
Idem, dites vous avez jamais vu des outils de traçages ? C'est aberrant tout ce que l'on peut faire avec.
Le cookie ma foi c'était il y a 8 ans (et encore sur de petites structures), maintenant on tire et trace les stats directement du serveur et de pas mal d'autres fonctionnalités implantés.
Bref maintenant si vous ne voulez pas être tracé, la presque seule solution est d'avoir la possibilité de donner de fausses informations. Et c'est encore très restreints, car si vous fournissez toujours les mêmes fausses informations vous êtes quant même pisté (certes pas catalogué mais bon faire passer son opera pour un ie, je ne sais pas si ça change grand chose).
# Vous voulez de la pub ou non ?
Posté par Jeezux . Évalué à 8.
Bonjour
Si je ne souhaite pas être suivie par les régies publicitaires, j'ai trouvé un moyen très simple, il s'agit d'AdBlock. Très efficace, il me permet aussi de bloquer tous ces scripts et iframes provenant des réseaux sociaux.
Bon généralement une régie publicitaire affiche sa pub dans une iframe et donc les cookie est lié à cette iframe et donc son nom de domaine. Je peut donc aussi tout simplement bloquer les cookies correspondant aux domaines des régies publicitaire.
Maintenant je ne vois pas l’intérêt de gérer les cookies par session. Par domaine me semble tout à fait suffisant.
Ou alors vous voulez de la pub mais sans pour autant qu'elle vous cible ? Je ne vois pas l’intérêt non plus, autant tout bloquer avec AdBlock
Bref, de mon point de vue, soit je bloque les pubs soit je ne les bloque pas. La régie publicitaire n'en à rien à faire du site que je visite. Ce qu'elle veux comprendre ce sont mes goûts et mes couleurs afin de faire de ciblér la pub. Ce qui me semble assez légitime vis à vis du surfeur qui souhaite recevoir de la pub.
Concernant les réseaux sociaux c'est aussi très simple. Ne pas s'inscrire.
Cordialement
[^] # Re: Vous voulez de la pub ou non ?
Posté par NeoX . Évalué à 3.
moi j'ai reglé mes cookies pour "uniquement les sites que je visiste"
ainsi si je vais sur un site A.fr et qu'il y a des appels à des bouts de B.com
logiquement je ne recois que les cookies de A.fr
[^] # Re: Vous voulez de la pub ou non ?
Posté par Doloop . Évalué à -2.
Beaucoup de site survivent grâce à la pub. Conseiller un adblock, c'est fondamentalement discutable, si on souhaite continuer à avoir du contenu gratuit.
[^] # Re: Vous voulez de la pub ou non ?
Posté par Jeezux . Évalué à 10.
Beaucoup survivent très bien sans pub.
[^] # Re: Vous voulez de la pub ou non ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Étant donné l'argent généré par la publicité, on devrait payer les spectateurs pour la regarder!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Vous voulez de la pub ou non ?
Posté par j_kerviel . Évalué à 8.
Est ce que tu est en train de sous entendre que
1. Les contenus remplis de publicité sont gratuits ?
2. Il n'y a pas de gratuit sans publicité ?
Bizarre comme façon de penser.
[^] # Re: Vous voulez de la pub ou non ?
Posté par mdlh . Évalué à 3.
Non, il dit juste qu'il existe des sites gratuits qui vivent de pubs. Il ne dit pas que l'un va sans l'autre.
[^] # Re: Vous voulez de la pub ou non ?
Posté par Misc (site web personnel) . Évalué à 2.
Le contenu n'est pas gratuit, il est payé autrement que par une transaction monétaire entre l'utilisateur du site et l'entité en charge de sa gestion. De ton point de vue, tu ne perds rien que tu ne puisses objectivement mesuré, mais la plupart du temps, le webmaster ( au sens large ) gagne de l'argent.
C'est vrai que ça pose un probléme en l'état pour l'économie autour du web que de bloquer les publicités. Mais en france, le CSA a limité le nombre de coupure publicitaire sur les chaines de télés privé en 2009, est ce qu'on a vu la disparition des chaines ? Non. On a limité pendant longtemps le placement de produit dans les films, et ça n'a pas empéché d'avoir des films.
Donc je ne pense pas que limiter la publicité tue des sites webs. Il n'y a guére que Google ou Facebook qui arrive à en vivre, AMHA.
Quelqu'un a des chiffres sur ce que ça rapporte à un webmaster moyen, ou un developpeur d'appli android classique ( sachant qu'à mon avis, le taux de clic est plus grand sur un téléphone, à cause du dit téléphone ) ?
[^] # Re: Vous voulez de la pub ou non ?
Posté par Lucky Seven . Évalué à 4.
L'extension Ghostery pour Firefox est très bien pour ça.
Non seulement elle bloque les cookies provenant des sites de trackers, mais elle bloque aussi les morceaux de javascript de ces mêmes sites.
[^] # Re: Vous voulez de la pub ou non ?
Posté par VoixOff . Évalué à 1.
Après essai de Ghostery, je trouve que RequestPolicy est bien plus performante (bien que l'interface puisse être un peu améliorée).
Je ne visite que ce je demande à visiter. C'est finalement contraignant que marginalement, certaines pages n'étant que des agrégats de différentes sources.
# XMLHttpRequest Level 2
Posté par Jeezux . Évalué à 4.
La prochaine version de XMLHttpRequest dite Level 2, encore à l'état de brouillon W3C, mais déjà implémentée dans plusieurs navigateurs, permet, en autres autres nouveautés, les requètes cross-origin. Internet Explorer depuis sa version 8 lui à sortie la fonction http://www.siteduzero.com/tutoriel-3-56320-l-xmlhttprequest-cross-domain.html.
Cordialement.
[^] # Re: XMLHttpRequest Level 2
Posté par Cr@zy . Évalué à 1.
+1 pour Jeezux, d'autant plus que les possibilités de crossdomain fonctionnent également en XML.
# Discutable.
Posté par Doloop . Évalué à 1.
Durcir la gestion des cookies, c'est effectivement prendre le risque que ceux qui en abuse se réfugient derrière d'autres mécanismes de conservation de session, accélérant la migration des données personnelles d'un stockage coté client à un stockage coté serveur.
Pour ceux qui sont allergiques aux publicités ciblées, suivez l'implémentation de la fonctionnalité «do not track» qui permet d'exprimer son refus d'être tracé. Toutes les régies publicitaires seront rapidement obligées de respecter ce choix utilisateur, simplement pour une question d'image et de «contamination commerciale»: un peu à la manière des licences gpl, une régie publicitaire ne peut désormais faire des affaires sur certains très grands réseaux publicitaire que si elle a démontré qu'elle respecte le «do not track». Ça fait partie des contrats.
Certe ça na rien d'infaillible, mais les régies qui tricheront y perdront des plumes en terme de notoriété. Et pour des vendeurs d'images, ça peut coûter très cher.
[^] # Re: Discutable.
Posté par ᴼ ᴹᴬᴺᴺ . Évalué à 4.
Tout est dans le rapidement… On sous entend quoi 1 ans, 10 ans ?
Quand je pense à toutes mes connaissances qui ont accepté des contrats énormes qui autorisent les sites qu'ils utilisent à les pister, suivre, faire de la pub ciblée etc. ce n'est pas do not track qui va changer quelque chose (pour les vieux fadas comme nous peut être, mais qui se soucie encore de la vie privée sur le web de nos jours ?).
La plupart des gens que je connais dans le vrai vie se font totalement avoir pas les divers services gratuits fournis par les sites web, pour limiter le pistage il faudrait vraiment quelque chose côté navigateur, activé par défaut et, surtout, n’empêche pas d'avoir la dernière fonctionnalité à la mode du site dans le vent.
207829⁶+118453⁶=193896⁶+38790⁶+14308⁶+99043⁶+175539⁶
[^] # Discutons
Posté par Marotte ⛧ . Évalué à 3.
C'est ça. Donc laissons les nous traquer simplement avec les cookies. La bataille est perdue, si c'est pas les cookies c'est le flash ou les activeX ou je ne sais quoi ? Ben voyons...
Do not track c'est bien, c'est déjà une manière de montrer que l'on est pas d'accord, mais de vils businessmen s'assoiront dessus. C'est un peu comme le "robots.txt" c'est respecté, ou pas.
[^] # Re: Discutons
Posté par Jux (site web personnel) . Évalué à 3.
L'idéal serait de légiférer un peu dans le domaine. Je trouverais normal qu'il faille le consentement explicite de l'utilisateur pour enregistrer ses informations privées (je considère la liste des sites que je visite comme privé). Il me semble qu'en Suisse (par exemple) on a des lois assez contraignantes à ce niveau-là, mais j'imagine que les régies publicitaires sont toutes américaines.
Ceci dit, un des gros problèmes c'est que l'interface de gestion des cookies des navigateurs n'est pas faite pour être sélectif. J'ai par exemple configuré mon navigateur(chromium) pour ne garder de manière permanente que les cookies de sites sur une liste blanche. Les autres cookies sont effacés à la fin de ma session (dans l'idéal il faudrait une option "onglet" qui efface les cookies qui ne sont pas sur la liste blanche quand je ferme l'onglet - ça rejoint la proposition du journal). Ca n'est certes pas la panacé, mais ça limite les possibilités de tracking et ça évite de faire dysfonctionner les sites qui nécessitent des cookies. Le problème c'est que la gestion de la liste blanche est tout sauf ergonomique (il faut 5 clics pour accéder à l'option et entrer une regex). J'avais essayé une extension qui permet d'accepter/refuser chaque cookie, mais c'est vite lourdingue... Bref, je pense qu'il reste des progrès à faire sur l'interface utilisateur.
# Les cookies, c'est bon, mangez-en !
Posté par sanpi . Évalué à 3.
Malheureusement les cookies sont le b.a.-ba pour tracer un internaute.
Dernière trouvaille dans le domaine, stocker un identifiant unique dans l'en-tête HTTP last-modified : https://nikcub.appspot.com/persistant-and-unblockable-cookies-using-http-headers
[^] # Re: Les cookies, c'est bon, mangez-en !
Posté par Antoine . Évalué à 3.
Mais ce n'est vu que du serveur d'origine, qui a de toute façon déjà accès à ton IP et à des tas d'autres paramètres.
[^] # Re: Les cookies, c'est bon, mangez-en !
Posté par Mildred (site web personnel) . Évalué à 1.
C'est idiot, et comment on fait pour le contrôle de cache maintenant ? C'est vrai qu'avec toutes ces applications dynamiques, on régénère tout le temps le contenu et au final on se demande bien à quoi ça sert.
J'aime les pages statiques
[^] # Re: Les cookies, c'est bon, mangez-en !
Posté par steph1978 . Évalué à 2.
Cool, tu t'es auto-répondu ;)
# Content Security Policy
Posté par Victor STINNER (site web personnel) . Évalué à 4.
Les navigateurs essaient par tous les moyens possibles de rendre cette frontière la plus étanche possible, mais on imagine facilement qu'avec des nouvelles fonctionnalités ajoutées à JavaScript, de nouvelles failles peuvent facilement voir le jour.
Cette approche me semble intéressante :
https://developer.mozilla.org/en/Security/CSP/Using_Content_Security_Policy
Voir aussi (plus vieux, plus spécifique) :
https://developer.mozilla.org/En/HTTP_access_control
# Le plus simple...
Posté par pizaninja . Évalué à -1.
Une première avancée serait d'avoir par défaut:
- une session distincte pour chaque fenêtre,
- et la même session au sein des onglets d'une même fenêtre.
[^] # Re: Le plus simple...
Posté par ᴼ ᴹᴬᴺᴺ . Évalué à 2.
Peut être mais Mme Michu et Kevin seraient totalement désemparé qu'on leur demande de se connecter à Facebook dans la deuxième fenêtre pour partager la vidéo trop drôle qu'ils viennent de voir.
Et puis les gens n'ouvriraient qu'une seule fenêtre avec pleins d'onglets sinon « ça bug ».
Pour les gens qui veulent en arriver là il suffit d'ouvrir à chaque fois un navigateur différent
⇾⎕
207829⁶+118453⁶=193896⁶+38790⁶+14308⁶+99043⁶+175539⁶
# Clarifications
Posté par Mildred (site web personnel) . Évalué à 3.
L'idée n'est pas de complexifier la navigation, mais au contraire de la rendre plus compréhensible par l'utilisateur. Et ce dont je parle à propos des cookies, peut je pense aussi s'appliquer au reste, entre autre, au données stockées par Javascript, prévu en HTML5.
Je définis par session l'ensemble des données stockées sur la machine cliente qui permet de rendre le protocole HTTP qui à la base n'avait pas de mode connecté, d'avoir un mode connecté. L'ensemble des données qui permettent au serveur de tracer l'utilisateur. Pour simplifier, une session, c'est un fichier
cookies.txt.Non, il n'est pas question de rendre accessible les cookies à n'importe quel serveur. un cookie reste associé à un serveur unique et à un chemin de ressource.
Il n'est pas question non plus de fermer les sessions intempestivement. Lorsqu'un utilisateur clique sur un lien, la session suit, même si le lien s'ouvre dans une nouvelle fenêtre. Pourquoi pas stocker la session avec les marques pages. En bref, toutes les requêtes HTTP avec un referrer vont conserver la session du referrer
Si l'utilisateur est connecté sur ebay.com dans un onglet et qu'il tape ebay.com dans la barre d'adresse d'un autre onglet, la session peut ou non être reprise. C'est au navigateur de décider. Dans bien des cas, c'est logique de reprendre la session. Et dans tous les cas, si le navigateur ne reprend pas la session, il doit être affiché à l'utilisateur de manière non intrusive: "Vous avez déjà une session ouverte sur ebay.com, voulez-vous la réutiliser ?"
Les listes blanches/noires sont un pas en avant, mais pas du tout ce que je recherche. Je peux vouloir accepter les cookies de Google parce que je veux accéder à gmail, mais ne pas vouloir qu'il me trace partout avec ses publicités. En pratique, peut être que Google utilise des cookies différents, mais je ne veux pas que mon cookie facebook leur permette de savoir où je vais
Les options de cookies de mon navigateur ne sont pas suffisantes. Dans Firefox 6, j'ai eu beau ne pas cocher "accepter des cookies de tierces parties", j'ai quand même des cookies provenant de domaines qui n'ont jamais apparus dans ma barre d'adresse (je pense que dans ce cas, Firefox accepte quand même les cookies des iframes)
Ça me plairait pas mal de faire une extension Firefox, mais il semble que ce ne soit pas facile de décorréler la gestion des cookies par onglet ou de manière assez fine. J'en veux pour preuve l'extension SwapCookies qui nous informe:
Si quelqu'un sait comment faire, je veux bien des idées. je n'ai jamais fait d'extension Firefox.
Tout cela m'est venu lorsque je me suis renseignée sur l'option "do not track" de Firefox. Je me suis demandée pourquoi cette options était uniquement informative alors que le navigateur, en refusant les cookies, peut très bien réglementer le traçage. Il fallait alors un moyen pour que les sites puissent quand même légitimement conserver une session (temporairement).
En fait, mon idée de départ était de modifier le protocole HTTP pour ajouter une notion de session, identique à ce qu'on peut trouver poiur l'authentification HTTP. On peut imaginer que le serveur demande:
Lorsque le client voit cet en-tête, il va demander à l'utilisateur (de manière non intrusive) si il souhaite maintenir une session pour ce serveur en particulier. Dans le cas où l'utilisateur le souhaite, le navigateur demande si il souhaite initier une nouvelle session ou si il souhaite réutiliser une session existante.
Dans le cas ou l'utilisateur ne souhaite pas être tracé, le navigateur ne renvoie aucun identifiant de session et va fermer cette nouvelle session:
Si l'utilisateur veut créer une nouvelle session, le navigateur renvoie l'identifiant de session que le serveur vient de créer:
Dans le cas où l'utilisateur souhaite réutiliser une ancienne session, dans la mesure où cette session est toujours valide, alors le navigateur renvoie:
Lors des futurs échanges, les deux parties continues de s'échanger l'identifiant de session, avec un nouveau timeout si nécessaire.
À ce moment là, je me suis demandée pourquoi ne pas faire ça simplement avec des cookies. Lorsque le serveur envoie un cookie malgré l'option "do not track" alors l'utilisateur peut accepter de créer une session. Si l'utilisateur ne fait rien, aucune session n'est créée. Les notifications pour la page principale se font de manière plus visible que les notifications pour les iframes.
[^] # Re: Clarifications
Posté par sifu . Évalué à 1.
Utilisateur de SwapCookies, j'aimerais bien aussi pouvoir gérer mes cookies par onglet ou par groupe d'onglets.
En effet, dans le cadre de certains développement web, j'ai besoin d'être logué plusieurs fois sur le même site mais avec des comptes différents.
Si jamais qqun à trouver qqchose pour ça je suis très preneur.
[^] # Re: Clarifications
Posté par kowalsky . Évalué à 2.
En effet, dans le cadre de certains développement web, j'ai besoin d'être logué plusieurs fois sur le même site mais avec des comptes différents.
Ce que tu peut faire, pendant la période de tests, c'est de permettre de passer la session en post (ou même get).
[^] # Re: Clarifications
Posté par Mildred (site web personnel) . Évalué à 4.
Je viens de découvrir Multifox
# Anatomie d'une extension Firefox
Posté par Mildred (site web personnel) . Évalué à 3.
Voici comment je vois une extension Firefox pour permettre d'implémenter ce comportement:
Vocabulaire:
cookies.txtcontenant une masse de cookies, cookie jarComportement à la création d'une fenêtre:
Comportement au chargement d'une page:
Comportement suite au clic sur un lien:
Fonctions supplémentaires:
chaque fenêtre se voit orné d'un bouton à deux états "autoriser les sessions". Si les sessions sont autorisées, le comportement précédant est appliqué. Si les sessions sont interdites dans cet onglet, alors aucune session n'est autorisée dans cet onglet, que ce soit en pleine page ou dans une frame.
chaque fenêtre se voit ornée d'un bouton représentant la session de cet onglet. On peut imaginer qu'une icône unique soit générée pour distinguer les sessions (à la manière des avatars StackOverflow). Un clic que ce bouton ouvre un menu avec les sessions de l'onglet en cours. Pour chaque session, il est possible de l'oublier ou la remplacer par une session existante en mémoire.
une préférence permet de choisir si en l'absence d'intervention de l'utilisateur dans le menu cité précédemment, les sessions sont automatiquement acceptées ou automatiquement rejetées. Une préférence existe pour les sessions de pleine page, une autre pour les sessions dans les frames.
Vous avez une idée de comment implémenter ça ?
[^] # Re: Anatomie d'une extension Firefox
Posté par Mildred (site web personnel) . Évalué à 4.
Multifox est un grand pas dans cette direction
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.