PROJET AUTOBLOG


le hollandais volant

Site original : le hollandais volant

⇐ retour index

Quelques astuces pour les clés GPG

dimanche 20 septembre 2015 à 18:22
L’ami Matronix a perdu sa clé GPG et a donc été obligé d’en créer une nouvelle. Bouuuhouu… *paf*[1]
Le problème maintenant :

Pour éviter ça, il y a des solutions !
Ne pas perdre sa clé publique est la plus évidente, mais personne n’est à l’abri d’une panne ou d’une mauvaise manipulation.

Pour éviter de perdre ses clés


Sauvegardez votre clé publique et privée sur un stockage externe[2], de préférence dédié à ça. S’il vous reste une vieille clé USB de 64 Mo (une antiquité, quoi), vous pouvez l’utiliser pour ça. Une disquette, c’est possible aussi, mais qui lit encore les disquettes ? Qui sait même encore ce qu’est une disquette, de nos jours ?

Une clé USB pour stocker ses clés GPG c’est bien, donc. Mais si la clé tombe en panne ?

Ma solution, c’est imprimer vos clés GPG. Pas en texte, car ça prendrait trop de temps pour taper le code en base64 à la main, mais dans un QR-Code, ou un datamatrix.
Si vous faites ça, vos clés seront sur un document en papier et vous pourrez les numériser très facilement avec un téléphone ou une webcam. Gardez quand même vos documents à l’abri (des gens, mais aussi d’un accident plus grave : incendie…).

De cette façon, perdre complètement vos clés GPG ne se reproduira plus.
Vous pouvez générer ici un QR-Code de façon sécurisé et anonyme.

Ma clé publique GPG dans un QR-Code se trouve ici.

Pour éviter que votre clé soit utilisable une fois perdue


Je veux dire par là que si vous perdez vos clés et que ces derniers n’expirent jamais, alors ils pourront être utilisées pour chiffrer des messages sans que vous ne puissiez les déchiffrer. Il faut donc utiliser une date d’expiration sur vos clés.

Ma méthode, qui permet de garder sa clé à la fois longtemps et sans risquer qu’elle reste valide indéfiniment, c’est de mettre une durée d’expiration (par exemple 1 an) et de repousser cette date quand on arrive à la fin de l’année. Votre clé est ainsi toujours valide, mais si vous la perdez alors elle s’expirera toute seule au bout d’un an.

Quand vous mettez à jour la date d’expiration (par exemple un mois avant la fin), n’oubliez pas de la republier la clé publique sur les serveurs de clé GPG, pour que tout le monde puisse avoir la dernière version à jour.




(Pour ceux qui ne savent pas ce qu’est une clé GPG et le chiffrement des emails, vous pouvez consulter mon tutoriel pour ça : utiliser GPG dans Thunderbird pour envoyer des e-mails chiffrés.)

Taxe Google Image… Ou comment ça va tuer les photographes

lundi 14 septembre 2015 à 22:25
photographie interdite
Un député désire instaurer une taxe google pour les images car tout ceci faciliterait le pillage des photographes par les internautes.

Super l’idée d’une taxe, hein ? Elle va financer les photographes, les auteurs, vous croyez ?
Non ! Elle va financer les comités d’ayants-droits (comme d’habitude) et tuer les photographes et les auteurs, vu que Google refusera dès-lors d’indexer leurs sites (puisqu’il leur faudra payer).

Les photographes (comme tous les sites web qui l’autorisent) profitent gratuitement de l’indexation de votre site par Google, non ?
Et bah la gratuité, c’est du vol, selon les ayants-droits !

Ils préfèrent payer Google pour être dans l’index du site le plus visité au monde ?

Ce député et les ayants-droits prouvent encore une fois qu’ils n’ont rien compris à Google et à internet.

Le problème c’est que les internautes n’ont jamais appris (n’ont jamais été éduqué à ça, en fait) à citer leur sources et à vérifier que la source est exploitable et sous quelles conditions (de la simple citation à la rémunération), y compris pour les images et n’importe quel média. Faut peut-être débuter par là, non ?

La solution ? Si vous êtes un internaute ou un éditeur de site web comme moi, sachez que certains photographes publient toute ou partie de leurs créations sous une licence permissive (Creative Commons, généralement) qui autorise leur réutilisation gratuitement, y compris parfois pour un usage commercial. Tout ce qui est demandé, c’est de citer l’auteur et de faire un lien : c’est ce que je fais dans tous mes articles, vu que je n’aurais jamais les moyens de payer des images non-gratuites, mon blog ne me rapportant rien financièrement.

Image de Johann Ebend

Utiliser LibreOffice pour supprimer les pubs sur les e-billets à imprimer

dimanche 30 août 2015 à 12:29
Les tickets de train ou de concerts qui sont à imprimer chez soi, c’est pratique (quand ils ne sont pas surtaxés). Par contre ils sont souvent bourrés de publicité, ce qui est moche et surtout finit par coûter cher en encre déjà cher.

Ceci avait d’ailleurs agacé un sénateur qui avait demandé au gouvernement de faire quelque chose. Malheureusement, ce dernier, voyant là quelque chose de pratique pour le con-sommateur, a décidé de ne rien faire (ce qui est peut-être mieux : ils auraient pu empirer la situation).

Il y a quand même un moyen de virer cette publicité à la con : éditer le PDF avant de l’imprimer.
Pour cela, vous pouvez utiliser la suite Libre Office (anciennement OpenOffice.org) et son éditeur Draw (logiciel libre et gratuit, pour Windows, Mac et Linux).
Draw peut en effet éditer les PDF et je vais vous montrer comment faire.

Je prends ici l’exemple d’un e-billet de la SNCF (ou de Capitain-Train, peu importe), mais ça doit marcher avec toute sorte de billet, et même avec toute sorte de fichiers PDF.

Premièrement, commencez par ouvrir le PDF avec LibreOffice Draw :

supprimer la publicité sur les e-billets à imprimer
Ensuite, sélectionnez à la souris d’un coup toute la partie contenant la publicité. N’hésitez pas à sélectionner de façon très large : il faut que les éléments soient bien dans la sélection :

supprimer la publicité sur les e-billets à imprimer
Relâchez la souris une fois la zone de publicité sélectionnée. Il suffit maintenant de supprimer tout ça avec la touche « Suppr » du clavier et le tour est joué :

supprimer la publicité sur les e-billets à imprimer
Pour finir, il faut exporter le document modifié au format PDF, avec le bouton prévu à cet effet, et de l’enregistrer sous le nom que vous voulez.

supprimer la publicité sur les e-billets à imprimer
Voilà, votre billet de train est désormais imprimable sans aucune pub.

Pour aller plus loin, vous pouvez supprimer les couleurs, ajouter des notes à vous (trajet, adresses, etc.), mais conservez bien le flashcode et les informations du trajet.
Ce que je fais en plus bien souvent c’est que j’ouvre à la fois le billet aller et celui de retour, et que je met les deux billets sur une seule feuille (en sélectionnant tout le haut du billet de retour et en le copiant-collant à la place de la pub sur le billet de l’aller).

Autrement, vous pouvez toujours commencer par imprimer la page et éteindre l’imprimante (ou annuler l’impression) une fois que la partie utile est imprimé et avant que la publicité ne soit encore sur la feuille. C’est moins propre, mais ça marche.

Sortie de Blogotext 3.0

samedi 29 août 2015 à 19:15
Je viens de mettre en ligne la dernière version majeure de Blogotext. Elle est disponible sur sa page habituelle.

Blogotext 3.0 screenshot
La charte graphique de Blogotext 3 est complètement refondue pour un style Google Material.
C’est le design utilisé par Google dans ses applications Android, mais aussi dans Android lui-même et la plupart de ses sites web.

D’autres captures d’écran de Blogotext 3 sont visibles ici.

Si j’ai choisit ce thème, c’est que je le trouve particulièrement pratique et joli, à la fois sur un mobile et sur ordinateur.
J’ai respecté au mieux les recommandations de Google pour ce thème, tout en l’adaptant pour convenir à Blogotext (tous les cas n’étant pas étudiés dans les recommandations).

Bien que les spécifications du Material Design soient faites par Google, Blogotext ne contacte à aucun moment leurs serveurs et tous les fichiers sont dans l’archive (polices, icônes…).

Ce n’est pas la seule nouveauté, bien-sûr : j’ai corrigé un grand nombre de bogues, un peu partout et j’ai refondu partiellement la gestion des fichiers & images ainsi que le lecteur RSS.

Concernant la compatibilité CSS, Blogotext 3 est compatible avec Firefox, Chrome, Opera 15+, Vivaldi. Microsoft Edge / IE11 sont compatibles hormis le glisser-déposer des fichiers. Les versions mobiles de Chrome, Opera et Firefox fonctionnent également sans soucis avec un thème entièrement responsive.
Au niveau du serveur, il faut toujours PHP 5.3 minimum ainsi que quelques bibliothèques particulières (listées ici).

Les anciens thèmes pour Blogotext devraient fonctionner sans problèmes. Consultez tout de même la note de version si vous mettez à jour depuis une version 2.x.

Pourquoi mettre le JavaScript à la fin et le CSS au début ?

jeudi 27 août 2015 à 19:46
Dans la création de pages web, on lit souvent qu’il faut mettre les fichiers CSS dans head, au début du document HTML et qu’il faut mettre le JavaScript à la fin. Bien rarement par contre il est dit pourquoi.

disposition en 3D des éléments d’une page web
Schématisation en 3D des éléments d’une page web.


Lors du processus d’affichage d’une page web, la première phase consiste au téléchargement de la page web : le document HTML ainsi que les images, mais aussi les feuilles CSS de styles et les scripts JS liés.

Le contenu HTML, c’est ce qu’on voit : le texte, les images, les champs de recherche, etc.
Les styles CSS, c’est comment le HTML sera vu : disposition, couleurs polices et taille du texte, couleur du fond de la page.

Le CSS et le HTML sont donc nécessaires à l’affichage de la page web et donc au visiteur qui souhaite lire votre site.
Les scripts JS, en revanche, ce sont des instructions destinées au navigateur, pas à l’internaute. Le navigateur les traite en tâche de fond et l’utilisateur de voit pas de différence s’ils sont là où pas (normalement).

Le problème, c’est la capacité du JS de modifier le HTML et le CSS. Du coup, le navigateur qui reçoit une page HTML+CSS n’aura en réalité la totalité de la page web qu’une fois qu’il aura terminé d’exécuter les scripts JS. Avant cela, il ne peut (presque) rien faire : il va bien commencer à afficher les différents éléments de la page (menu, titres, liens…) mais si le JS supprime le menu entre temps, il devra tout recommencer.

La solution du navigateur pour le problème du JS ?

Commencer d’effectuer le rendu (l’affichage) de la page et mettre ce rendu en pause quand il détecte un script JS : à ce moment là, il doit télécharger tout le script JS et l’exécuter entièrement (ce qui a des chances de modifier le HTML et le CSS, souvenez-vous) avant de reprendre de rendu (et au besoin le recommencer, si le JS a beaucoup modifié le HTML ou le CSS).
Le fait pour le navigateur d’avoir à se mettre en pause lorsqu’il rencontre un script, nous fait dire que le JS est bloquant.

Le CSS, le HTML et même les images sont non-bloquant : le navigateur peut continuer à décoder la page web même quand il est encore en train de télécharger du CSS, par exemple. Il peut donc télécharger du CSS en parallèle avec le HTML. Une fois qu’il a tout le CSS, il commence le rendu tel qu’il est décrit par le CSS. Le décodage du HTML, lui, se poursuit durant tout ce temps.

Un document HTML simple, sans CSS ni JS, s’affiche quand même : c’est le rendu par défaut d’une page web : le fond est blanc, le texte est noir et tous les éléments sont à la suite les uns des autres. Bref, c’est moche, mais ça reste lisible.

mon site sans CSS
Mon site tel qu’il s’affiche sans les styles CSS.


Le navigateur, quand il reçoit le document HTML, commence par effectuer le rendu par défaut. Lorsqu’il reçoit le CSS, ce rendu par défaut continu (de façon à ce que la page soit lisible — même si c’est moche). Le rendu par défaut est stoppé quand tout le CSS est arrivé : à ce moment là, c’est le rendu tel qu’il est décrit dans le CSS qui est appliqué : les couleurs, les fonds, les bordures, les ombres… tout ça est alors affiché. Le traitement du CSS ne bloque pas le téléchargement du reste du contenu de la page.


Pour l’instant je n’ai pas vraiment répondu à la question « pourquoi mettre le JS à la fin et le CSS au début ? », mais j’y viens.

On sait que l’affichage des données (texte, images…) dans la page web commence dès que le HTML est en train d’être téléchargé : ceci permet à l’internaute d’accéder à l’information contenue dans la page le plus rapidement possible, même si le CSS et le JS ne sont pas encore arrivés. Une fois que tout le CSS est obtenu, l’information est alors restructurée, organisée sur la page et coloriée.
Lorsque le navigateur reçoit un script JS, l’affichage est mis en pause : le JS doit finir de s’exécuter avant que l’affichage puisse continuer.

L’intérêt de placer le CSS en haut et le JS en bas se trouve à ce niveau.

Si on met le CSS en haut, c’est pour que l’affichage « colorié » se fasse le plus vite possible : pour que la page web soit « jolie » et « organisée » tout de suite, avant que l’utilisateur ne puisse se trouver face à une page web dans son rendu par défaut. Cela tombe d’ailleurs bien : le téléchargement du CSS n’est pas bloquant : l’information dans la page web continue d’arriver pendant ce temps : l’affichage de la page web n’est pas ralentie par le CSS. C’est juste mieux de l’avoir avant, pour que l’affichage se fasse directement comme la page doit être, sans à avoir un rendu par défaut entre-temps.

Parallèlement si on met le JS en bas du document, toute l’information contenue dans la page web sera déjà affichée (car déjà téléchargée et déjà rendue à l’écran). Au moment où le navigateur rencontre le JS, l’écran ne sera pas tout vide ni tout blanc : l’internaute pourra commencer à lire la page web pendant que le navigateur traite le script JS et effectue les derniers changements.

Si on mettait le JS tout en haut, la page n’aurait encore aucune donnée que l’affichage et le téléchargement seraient déjà bloqués : l’internaute n’aurait alors qu’une simple page blanche et rien à lire. Si le script est gros, cela peur prendre plusieurs secondes. Si ça ne semble pas long dit comme ça, croyez-moi, ça l’est : si toutes les pages web mettaient 2 secondes de plus pour s’afficher, vous le verriez très rapidement. Placer le JS en haut n’est donc pas génial, car il oblige le navigateur à tout mettre en pause et l’internaute à attendre devant une page vide.
Mettre le CSS en bas de la page n’est pas avantageux non plus : le CSS n’est pas bloquant. Il peut être téléchargé en parallèle avec le reste. Si on le met en bas de la page, il sera téléchargé en dernier et tout seul, donc sans tirer profit de la possibilité de télécharger deux choses en même temps. De plus, tout le document HTML sera déjà là mais affiché avec le rendu par défaut du navigateur, donc tout moche. Si l’internaute a déjà commencé à lire, il verrait alors la page se modifier sous ses yeux à l’instant même où tout le CSS aura fini de télécharger et que le rendu se fasse.

Il convient donc naturellement de mettre le CSS le plus tôt possible dans la page (dans le head) pour tirer profit du téléchargement en parallèle du CSS avec d’autres ressources et pour que le rendu se fasse directement de façon voulue ; et il faut placer le JS en bas du document pour que quand le navigateur le trouve, tout le reste de la page soit déjà affiché à l’écran et que l’internaute puisse commencer à lire votre page pendant le traitement du script JS par le navigateur en tâche de fond.


Quelques liens :