Mildred a écrit 2245 commentaires

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

Voici comment je vois une extension Firefox pour permettre d'implémenter ce comportement:

Vocabulaire:

• session: fichier cookies.txt contenant une masse de cookies, cookie jar
• Fenêtre de navigateur: une fenêtre ou un onglet, c'est pareil
• frame: cadre ou iframe. Inclusion d'une autre page web dans un cadre à l'intérieur de la page web

Comportement à la création d'une fenêtre:

• Création d'une nouvelle fenêtre sans referrer: on crée une nouvelle session associée à cet onglet
• Création d'une nouvelle fenêtre après suivi d'un lien: on réutilise la session du referrer

Comportement au chargement d'une page:

• les cookies sont acceptées uniquement pour la requête principale (celle de la barre d'adresse). Aucune autre demande de cookies n'est acceptée, sauf ...
• pour chaque frame, une nouvelle session est créée
• si deux frames de la même page pointent sur un même domaine, deux sessions sont créées. Pour le moment, mieux vaut s'en tenir à des règles simples, on verra ensuite si elles peuvent être assouplies.

Comportement suite au clic sur un lien:

• le lien est chargé avec la session de la page qui contenait le lien. Que ce soit une page dans une frame ou en pleine page. Même si on ouvre un nouvel onglet/fenêtre
• si on clique sur un lien qui remplace la page en cours, et que cette page avait des frames, les sessions de ces frames sont perdues.

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 ?

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:

  Note: When swapping profiles with CookieSwap, the cookies in all tabs and all browser windows are changed at the same time. This means that your web login to sites like gmail will change in all the tabs at once. I know it would be great to support different cookies per tab, but that problem poses some significant challenges.

  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:

Session-Initiate: <identifiant de session généré par le serveur>
Session-Timeout: temps au bout duquel l'identifiant de session est invalidé

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:

Session-Reject: <identifiant de session généré par le serveur>

Si l'utilisateur veut créer une nouvelle session, le navigateur renvoie l'identifiant de session que le serveur vient de créer:

Session: <identifiant de session généré par le serveur>

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:

Session-Close: <le nouvel identifiant de session>
Session: <l'ancien identifiant de session>

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.

La guerre en Irak avec ses 'armes de destruction massives' n'a t elle pas suffi. Les guerres sont toujours prétexta a manipulation.

Wikipédia n'est pas un livre sacré. Au dela des sujets techniques j'ai tendance a me méfier. L'article n'est pas toujours objectif .

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 ?

Sans doute que gdm bloque lui même ... parce qu'il à besoin de lire des fichiers dans les homedirs il me semble.

En utilisant le phénomène de dégravitation: http://www.hatem.com

Je sais que si demain je change l'emplacement du lien « google » sur la page d'accueil de l'intranet, tous les utilisateurs qui accèdent à google sans passer par le champ de recherche (ou d'adresse) de firefox mais par ce lien sur la page d'accueil de l'intranet viendront demain se plaindre auprès de moi en me disant « je n'ai plus Internet² ».

En fait, j'ai pu tester que lorsque j'ai changé la page d'accueil de mon netbook vers autre chose que google, ça déroute certains, qui sont obligés de se rabattre sur le champ de recherche pour chercher des sites qui sont en marque pages.

Parfois, j'aimerais que les moteurs de recherche n'existent plus.

Pour inkscape, il me semble qu'il veulent que la version 1.0 corresponde à 100% du standard svg, ils en sont à 48%

Tu ne fais "que" rajouter une personne de confiance dans la chaîne

On est bien d'accord, mais en pratique ça casse un peu toute la sécurité qu'offrirait OpenPGP.

Prenons le cas simple de deux utilisateurs ayant chacun un webmail avec OpenPGP: alice@example.com et bob@server.net. Si Alice envoie un message à Bob, on va avoir les communications suivantes:

• alice -> webmail.example.com: pas chiffré
• webmail.example.com -> mx.server.net: chiffré
• webmail.server.net -> bob: pas chiffré

En l'occurrence, on a 4 entités dans la communication et tous les 4 ont accès au message non chiffré.

Alors, bien sûr, cela protège le message entre example.com et server.net, mais il suffit que la communication SMTP soit chiffrée par SSL pour obtenir le même résultat.

Ce que j'ai compris, c'est qu'en fait, tu veux faire une application HTTP pour échanger des messages via des URLs définies et normalisée via ton API REST : les messages sont hébergés sur le serveur et seuls les utilisateurs de ce serveur peuvent lire ou échanger des messages. Si tu veux t'affranchir de cette limitation et pouvoir échanger entre serveurs, ça va être plus difficile car il faut trouver un moyen raisonnable d'échanger les données entre serveur, sûrement via une API REST qui te permet de tester la capacité du serveur à échanger des messages.

En l'occurence, ce que je définis est l'API inter-serveurs. Au sein d'un même serveur, on peut réutiliser la même API mais on doit pouvoir se passer de la vérification.

Idéalement, j'aimerais bien une API REST commune à tous les systèmes de PM qu'on voit de partout (en particulier sur Tor pour remplacer les e-mails) pour qu'on puisse communiquer entre plusieurs serveurs différents.

Et si on veut de l'authentification, HTTp gère ça nativement (même si pas forcément trop bien). Je n'ai pas non plus envie de rajouter une couche login à un protocole.

À l'origine, je ne suis pas fan du tout des interfaces web. Et pas tellement fan du HTTP à toutes les sauces. Mais j'ai du me rendre à l'évidence:

Si je veux faire un client web (parce que les gens ne veulent pas installer un client lourd), j'ai à ma disposition du HTML pour la description de l'interface et du Javascript pour le comportement. Et javascript ne peux communiquer qu'avec XmlHttpRequest -- du HTTP.

Su je veux gérer un canal de communication sécurisé, je dois soit me palucher tout SSL à la main sur mon flux TCP, soit réutiliser un protocole de plus haut niveau (HTTPS en l'occurence)

Si je veux pouvoir faire plus d'une chose sur le même port TCP, délimiter des messages, soit je prend un formalisme que je définis moi même, soit je réutilise quelque chose d'existant comme HTTP, WebSockets, ...

J'aurais aussi pu réutiliser XMPP (j'en suis pas mal fan), mais je dois admettre qu'il dispose de moins de libs et est bien moins démocratisé. Au final, j'ai fini par choisir HTTP.

Au final, j'adore quand les interfaces sont documentées et normalisées, ça permet d'écrire des clients lourds ... je n'aime pas trop les clients légers.

Quel effort est fait concernant l'ergonomie du bureau. Cela ne risque-t-il pas d'être un frein majeur à son utilisation ?

J'utilise pavatar, et je le trouve bien mieux que gavatar. En effet, gavatar dépend d'un serveur centralisé alors que chacun peut mettre un pavatar sur sa page perso, et il sera reconnu.

Je serais d'avis de chercher d'abord pavatar, et si il n'est pas trouvé, alors utiliser éventuellement gavatar.

c'est fait exprès pour que l'item sélectionné soit sous la souris

À mon avis, c'est l'effet de masse, Linux, KDE, Gnome, Fedora sont (ou seront) sous git, du coup, tu te dit que ça doit valoir la peine.

C'est exactement ça.

Au début j'étais pro-mercurial, mais pour des raisons politiques, j'ai changé pour git, et depuis je le trouve mieux.

Je sais qu'à l'époque, je reprochais à git de ne pas permettre comme dans mercurial d'avoir deux têtes dans une seule branche. Mais j'ai compris que git faisait différamment:

git:
- on rapatrie les commits distants qu'on stocke dans une branche distante
- on merge la branche distsante avec la branche locale du même nom

mercurial:
- on rapatrie les commits distants qui s'ajoutent au dépôt. Pour les branches qui on divergé, elles se retrouvent avec deux têtes.
- on merge ces deux commits de tête pour se retrouver dans un cas classique où les branches ne divergent plus.

Si on ne connaît pas bien git, on peut lui reprocher que le "detached HEAD" ne soit pas aussi biebn géré que le "dual head" sous mercurial. Dans mercurial, si je commite à un autre endroit que HEAD, ce commit sera enregistré comme faisant partie de la branche du commit parent alors qu'avec git, on peut perdre le commit et le voir un jour disparaître par garbage collector.

La version awk est meilleure ... et c'est bien le 9e champ. Le problème c'est que cut -d' ' va considérer tous les espaces comme des séparateurs, et si il y a deux espaces d'affilée, il va compter qu'il y a un champ vide entre. Et le problème c'est qu'au début du mois, ls va insérer un espace supplémentaire avant le numéro du jour (car il n'a qu'un seul chiffre) et pas à la fin. Donc avec cut, selon si c'est au début du mois où à la fin, tu va avoir à taper -f9 ou -f10 Exemple:

mildred@meryl:~/Documents$ ls -l comptes comptes.save
-rw-r--r--. 1 mildred mildred 4242 Dec  4 11:29 comptes
-rw-r--r--. 1 mildred mildred 3029 Oct 22 08:35 comptes.save
mildred@meryl:~/Documents$ ls -l comptes comptes.save | cut -d' ' -f9
11:29
comptes.save
mildred@meryl:~/Documents$ ls -l comptes comptes.save | cut -d' ' -f10
comptes

acpidump: http://dl.free.fr/rKI6ZqO4s

Je peux fournir un acces ssh IPv6 si besoin, avec Fedora 14. Enfin ça dépend pourquoi faire ... et l'ordinateur et souvent chargé, la connexion intermittente et je n'ai pas de DNS.

Me contacter: shanti.bouchez+pub@gmail.com

Juste une balise meta a mettre sur ta page OpenID:

http://pavatar.com/

C'était déjà firefox ?
Il me semble que sur la debian 2.2 netscape devait à peine avoir été remplacé par mozilla. De la à parler de firebird ... oups, firefox. Enfin, à l'époque j'étais encore sous Mandrake.

On peut bidouiller en mettant plusieurs IP publiques sur le même NAT (donc bien sûr, ton IP publique changera à chaque connexion). Cela permettra d'avoir un peu plus de ports par utilisateur.

On est bien d'accord, ça ne tiendra pas longtemps. A un moment, les limites seront tellement tendues que ça finira par craquer.

Par contre, les RIR risquent de commencer à se préoccuper de la question, vu que les opérateurs continueront à leur demander des adresses mais qu'ils ne pourront plus en avoir de nouvelles.