Vue lecture

Comment j'ai viré Algolia et recréé le Google de 1998 sur mon site

Bon, faut qu'on parle un peu du moteur de recherche de mon site. Ceux qui l'ont déjà utilisé savent de quoi je parle : c'était pas terrible. Enfin, « pas terrible » j'suis gentil. C'est un espèce d'overlay avec des résultats certes fiables mais c'était vraiment pas pratique.

Et en plus de ça, comme j'ai un site statique généré avec Hugo, je passais par Algolia pour la recherche. Si vous ne connaissez pas, Algolia c'est un service cloud qui indexe votre contenu et vous fournit une API de recherche ultra-rapide. Sur le papier c'est génial et dans la pratique aussi d'ailleurs sauf que voilà, ça coûte des sous. Et mon site rencontre un franc succès ces derniers temps (merci à vous !), donc j'ai de plus en plus de visiteurs, donc de plus en plus de recherches, donc une facture Algolia qui grimpe gentiment chaque mois.

Du coup je me suis dit : « Et si je trouvais une solution de recherche pour sites statiques ? » Parce que oui, ça existe et c'est comme ça que j'ai découvert Pagefind.

Pagefind c'est donc un moteur de recherche statique open source développé par CloudCannon qui fonctionne comme ceci : Au moment du build de votre site, Pagefind parcourt tout votre HTML généré et crée un index de recherche qu'on peut interroger avec un peu de JS. Y'a donc plus d'API, et tout se fait localement sur le navigateur des internautes.

Bref, ça avait l'air très cool alors évidemment, je me suis lancé dans l'aventure et comme j'aime bien me compliquer la vie, j'ai décidé de pas juste intégrer Pagefind tel quel. Non non. J'ai voulu recréer l'interface du Google de 1998 parce que à quoi bon avoir son propre site web si on peut pas s'amuser un peu ^^.

Laissez-moi donc vous raconter cette aventure.

Le problème avec Algolia

Leur service est excellent, je dis pas le contraire, la recherche est rapide, les résultats sont pertinents, l'API est bien foutue mais voilà, y'a le modèle de pricing puisque Algolia facture au nombre de requêtes de recherche.

Plus les gens cherchent sur votre site, plus vous payez et quand vous avez un site qui fait plusieurs millions de pages vues par mois, bah... ça chiffre vite. En gros je dépasse très vite les 10 000 recherches offertes chaque semaine et ensuite ça chiffre. C'est pas la mort, mais c'est un coût récurrent débile pour un truc qui pourrait être gratuit.

En plus de ça, y'a la dépendance à un service externe. Si Algolia tombe, ma recherche tombe. Et si Algolia change ses prix, je vais devoir subir. Même chose si Algolia décide de modifier son API... il faudra que j'adapte mon code. Bref, c'est le cloud dans toute sa splendeur... C'est pratique mais on n'est jamais vraiment chez nous.

Pagefind à la rescousse

Pagefind résout donc tous ces problèmes d'un coup. C'est un outil en ligne de commande qui s'exécute après votre générateur de site statique (Hugo dans mon cas, mais ça marche avec Jekyll, Eleventy, Astro, ou n'importe quoi d'autre).

Concrètement, vous lancez :

npx pagefind --site public

Et Pagefind va :

    1. Scanner tous vos fichiers HTML dans le dossier public/
    1. Extraire le contenu textuel (en ignorant la nav, le footer, les pubs si vous lui dites)
    1. Créer un index de recherche optimisé
    1. Générer des fichiers JavaScript pour interroger cet index côté client

Et le résultat c'est un dossier pagefind/ qui contient tout ce qu'il faut. Ensuite; à vous de servir ces fichiers statiquement avec le reste de votre site, et la magie pourra opérer !

L'index pour mes 18 000 articles fait environ 1,5 Go. Ça peut paraître beaucoup, mais Pagefind est malin car il découpe l'index en fragments et ne charge que ce qui est nécessaire pour la recherche en cours. Du coup en pratique, une recherche typique télécharge quelques centaines de Ko, et pas plus.

L'intégration technique

Pour intégrer Pagefind dans mon workflow Hugo, j'ai donc été cherché le binaire, je l'ai mis sur mon serveur et je l'ai appelé dans un cron comme ça, je rafraichi l'index de recherche 1 fois par jour (et pas à chaque génération du site).

0 4 * * * /home/manu/pagefind/pagefind --site /home/manu/public_html --output-path /home/manu/public_html/pagefind >> /var/log/pagefind.log 2>&1

J'ai aussi créé un fichier de configuration pagefind.yml pour affiner le comportement :

root_selector: "[data-pagefind-body]"
exclude_selectors:
 - "header"
 - ".site-header"
 - "footer"
 - ".sidebar"

L'astuce ici c'est d'indexer uniquement les div ayant la class data-pagefind-body='true' et d'exclure les éléments qui ne font pas partie du contenu éditorial afin de ne pas indexer ce qui se trouve dans le header, les natives, le footer...etc.

Côté JavaScript, Pagefind utilise les imports ES6 dynamiques. Ça veut dire que le moteur de recherche n'est chargé que quand l'utilisateur lance effectivement une recherche :

async function initPagefind() {
pagefind = await import('/pagefind/pagefind.js');
await pagefind.init();
}

Et pour faire une recherche :

const search = await pagefind.search("linux");
// search.results contient les IDs des résultats
// On charge le contenu de chaque résultat à la demande
for (const result of search.results) {
 const data = await result.data();
 console.log(data.url, data.meta.title, data.excerpt);
}

C'est bien fichu parce que search.results retourne immédiatement les références des résultats, mais le contenu réel (titre, extrait, URL) n'est chargé que quand vous appelez result.data(). Du coup vous pouvez implémenter une pagination propre sans télécharger les données de milliers de résultats d'un coup.

Le délire rétro - Recréer Google 1998

Maintenant que j'avais un moteur de recherche fonctionnel, fallait l'habiller. Et c'est là que j'ai eu cette idée un peu débile : Pourquoi pas recréer l'interface du Google de 1998 ?

Pour les plus jeunes qui lisent ça, Google en 1998 c'était une page blanche avec un logo, un champ de recherche, et deux boutons : « Google Search » et « I'm Feeling Lucky« . Pas de suggestions, pas de carrousels, pas de pubs... Juste un champs de recherche. C'était la belle époque !

J'ai donc créé une page de recherche avec deux vues distinctes. La page d'accueil avec le logo centré et le champ de recherche au milieu, exactement comme le Google originel.

Et la page de résultats avec le logo en petit en haut à gauche et les résultats en dessous.

Pour le code CSS, j'ai voulu être fidèle à l'époque. Times New Roman comme police par défaut, les liens en bleu souligné qui deviennent violet une fois visités. Et surtout, les boutons avec l'effet 3D des interfaces Windows 95 :

.search-button:active { border-style: inset; }

Ce border: outset et border-style: inset au clic, c'est exactement ce qui donnait cet effet de bouton en relief qu'on avait partout dans les années 90. Pour moi, ça fait toute la différence pour l'authenticité. Même le logo, je l'ai volontairement « dégradé » pour qu'il soit de la même qualité que le logo Google d'origine.

La pagination « Koooooorben »

Vous vous souvenez de la pagination de Google avec « Goooooogle » en bas de page ? Le nombre de « o » correspondait au nombre de pages de résultats. J'ai fait pareil, mais avec « Koooooorben ».

let logo = 'K'; for (let i = 0; i < oCount; i++)
{
logo += o;
} logo += 'rben'; }

Plus il y a de résultats, plus il y a de « o ». C'est complètement inutile mais ça me fait marrer à chaque fois que je le vois.

Le bouton « J'ai de la chance »

Ah, le fameux « I'm Feeling Lucky » de Google, j'ai voulu l'implémenter comme à l'époque ! Si vous tapez une recherche et cliquez sur « J'ai de la chance », vous êtes envoyé sur le premier résultat. Classique. Mais si vous cliquez sur le bouton avec le champ vide sur la home de la recherche, vous êtes envoyé sur un article aléatoire parmi les +18 000 du site.

Pour ça, j'ai utilisé une astuce : le sitemap. Mon Hugo génère un fichier sitemap.xml qui contient toutes les URLs du site et je peux aller piocher dedans en JS :

const articles = [...xml.querySelectorAll('loc')] .map(loc => loc.textContent) .filter(url => {
// Exclure les pages qui ne sont pas des articles
const path = new URL(url).pathname;
return !path.startsWith('/categories/') && !path.startsWith('/page/') && path !== '/';
});
const randomUrl = articles[Math.floor(Math.random() * articles.length)];
window.location.href = randomUrl;
} }

Un seul fetch, un peu de parsing XML natif, et hop c'est le grand retour de la fonctionnalité « article aléatoire » qui vous manquait, je le sais !

Tri et nombre de résultats

Je vous ai aussi mis une listbox qui vous permet d'afficher 10, 25 ou 50 résultats ainsi qu'un tri par pertinence ou data. Et ça aussi Pagefind sait parfaitement le navigateur.

Mode sombre et accessibilité

Même si l'interface est rétro, j'ai quand même ajouté quelques fonctionnalités modernes. Le mode sombre respecte les préférences système, et j'ai intégré la police OpenDyslexic pour les personnes dyslexiques.

Le truc important c'est de charger ces préférences avant le rendu de la page pour éviter le fameux flash. J'ai donc un petit script qui lit les préférences dans le localStorage et applique les classes CSS immédiatement :

function() {
 if (localStorage.getItem('theme') === 'dark') {
 document.documentElement.classList.add('dark-mode');
 }
 if (localStorage.getItem('dyslexic-font') === 'true') {
 document.documentElement.classList.add('dyslexic-mode');
 }
});

Gestion de l'historique navigateur

Un détail qui peut sembler anodin mais qui est super important pour l'expérience utilisateur c'est la gestion du bouton retour du navigateur.

Quand vous faites une recherche, l'URL change selon votre requête du genre /recherche/?q=linux&p=2. Du coup si vous partagez cette URL à un collègue, la personne arrivera directement sur les résultats de recherche. Et si vous utilisez le bouton retour, vous reviendrez alors à la recherche précédente.

window.addEventListener('popstate', () => {
const query = new URLSearchParams(location.search).get('q');
if (query) doSearch(query);
else showHomePage();
});

Liens vers d'autres moteurs

Et si vous ne trouvez pas votre bonheur dans mes +18 000 articles (ce qui serait quand même étonnant ^^), j'ai ajouté des liens pour relancer la même recherche sur Google, DuckDuckGo, Qwant, Brave et Ecosia. Bref, un petit service bonus pour mes visiteurs, exactement comme le proposait Google à l'époque.

Le bilan - Algolia vs Pagefind

Après 1 semaine d'utilisation, voici donc mon verdict ! Côté portefeuille d'abord, Algolia me coûtait entre 60 et +100 euros par mois et maintenant pour Pagefind, c'est zéro euros ! Et les performances sont également au rendez-vous. Algolia c'était rapide et bien là, ça l'est encore plus. Seul compromis à noter, l'index Algolia se mettait à jour en temps réel, alors que Pagefind nécessite une reconstruction au moment du build.

La conclusion

Voilà, j'ai maintenant une recherche qui marche vraiment bien, qui me coûte 0€ par mois, et qui a un look rétro qui va en surprendre plus d'un...

Alors est-ce que c'était nécessaire de passer autant de temps sur le design rétro ? Hé bien absolument pas. Mais est-ce que ça valait le coup ?

Franchement, oui !! C'est mon site, je fais ce que je veux, et si ça peut faire sourire quelques visiteurs nostalgiques des débuts du web, c'est du bonus. D'ailleurs un grand merci aux Patreons qui me soutiennent car sans eux, je n'aurais pas pu passer mon dimanche là dessus ^^

Et puis surtout, ça m'a permis de découvrir Pagefind qui est vraiment un excellent outil. Donc si vous avez un site statique (ou n'importe quel type de contenu textuel) et que vous cherchez une solution de recherche gratuite et performante, je vous le recommande chaudement. La documentation est claire, l'intégration est simple, et le résultat est top !

Allez, maintenant vous pouvez aller tester la nouvelle recherche sur le site . Et si vous cliquez sur « J'ai de la chance » sans rien taper... bonne découverte !

  •  

Sisu - Quand votre AWS devient un simple dossier sur votre disque

Vous passez vos journées à faire des aws iam list-users | jq '.Users[]' et autres trucs interminables pour juste trouver une info ?? Laissez tomber, j'ai le truc qui va vous changer la vie !

Ça s'appelle Sisu et c'est un petit outil en Go qui monte vos ressources AWS comme un système de fichiers local. Du coup, au lieu de taper des commandes AWS complexes, vous utilisez juste grep, cat, diff, vim... c'est à dire les outils Unix que vous connaissez déjà par cœur.

Vous lancez la commande sisu et hop, vos ressources AWS se retrouvent montées dans ~/.sisu/mnt/ ! Vos buckets S3, vos paramètres SSM, vos roles IAM, vos lambdas, vos instances EC2...etc. Tout ça organisé en dossiers par profil AWS et par région.

Ainsi, pour chercher tous vos utilisateurs IAM qui ont un accès admin, c'est aussi simple que :

grep -l "AdministratorAccess" */global/iam/users/*/policies.json

Pour comparer la config d'un rôle entre prod et staging :

diff prod/global/iam/roles/api/info.json staging/global/iam/roles/api/info.json

Et pour lire un secret ? Un simple cat default/us-east-1/secrets/myapp/database/value.

C'est bête comme Jordan mais ça change tout pour la maintenance au quotidien !

Et côté services supportés, Sisu gère pas mal de trucs tels que le S3 et SSM Parameter Store en lecture/écriture/suppression, et IAM, VPC, Lambda, EC2, Secrets Manager, Route 53 et CloudWatch Logs en lecture seule. Y'a même un truc sympa pour EC2 c'est que vous pouvez vous connecter à une instance via SSM Session Manager sans avoir besoin de clés SSH. Suffit d'exécuter le fichier connect qui se trouve dans le dossier de l'instance (à condition d'avoir l'agent SSM configuré sur l'instance et le plugin Session Manager côté client, évidemment).

Pour les logs CloudWatch, c'est bien aussi puisqu'ils sont streamés à la demande par batches de 100, donc vous pouvez faire un grep dessus sans tout charger en mémoire d'un coup.

Côté installation, c'est du Go classique :

go install github.com/semonte/sisu@latest

Faudra juste penser à installer FUSE avant sur votre système (apt install fuse sous Ubuntu/Debian, yum install fuse sous RHEL/CentOS) et c'est tout, y'a rien d'autre à configurer si vous avez déjà vos credentials AWS en place.

Après, l'outil cache les résultats pendant 5 minutes pour éviter de spammer l'API AWS à chaque ls, ce qui est plutôt indispensable pour limiter les appels et le temps de réponse.

Bref, si vous en avez marre de jongler avec jq pour parser du JSON AWS, Sisu va vous aider ! C'est open source sous licence MIT, et c'est par ici !

  •  

HTTP Breakout Proxy - Le reverse engineering sans prise de tête

Pendant que Burp Suite avale 500 Mo de RAM au démarrage, HTTP Breakout Proxy lui, tient dans un binaire de quelques Mo qui disparaît dès que vous fermez le terminal.

Alors HTTP Breakout Proxy c’est quoi ?

Hé bien les amis, c’est un proxy HTTP/HTTPS écrit en Go qui intercepte le trafic réseau en temps réel et vous propose une interface web pour analyser tout ce qui passe. Requêtes, réponses, headers, body, timing… Tout est capturé et affiché proprement dans votre navigateur.

Vous le lancez avec ./http-breakout-proxy, il écoute sur 127.0.0.1:8080, et vous ouvrez l’interface dans votre browser. Ensuite, si vous voulez débugger une API par exemple, vous lancez le proxy, vous configurez votre client HTTP pour passer par localhost:8080, et vous voyez tout passer en direct.

C’est vrai que Burp est devenu un monstre à tout faire avec scanner de vulnérabilités, fuzzer, crawler, extensions… Y’a aussi Charles Proxy que j’aime bien mais qui pèse dans les 100 Mo et nécessite une JVM complète. Et même mitmproxy , pourtant réputé léger, a accumulé tellement de fonctionnalités qu’il faut lire 50 pages de doc pour comprendre comment l’utiliser.

Avec HTTP Breakout Proxy, il y a moins de features c’est vrai mais ça va plus vite et c’est gratuit. Maintenant, au niveau technique, le projet utilise l’interception MITM classique. Vous installez le certificat racine fourni par le proxy, et il peut déchiffrer le trafic HTTPS qui passe par lui. Ensuite, l’interface web affiche tout en temps réel via Server-Sent Events. Vous avez du filtrage par regex, du color-coding configurable pour repérer visuellement les requêtes importantes, et même des charts Gantt pour visualiser le timing des connexions…etc.

Que demande le peuple ? Ah oui, y’a aussi l’export vers curl ou Python requests, ce qui est pratique quand vous voulez rejouer une requête dans un script. Et bien sûr la possibilité de mettre la capture en pause pour analyser tranquillement ce qui s’est passé.

Voilà, c’est minimaliste mais ça marche hyper bien et quand on est pas un pro de la sécurité, c’est bien d’avoir des outils de ce style pour explorer un truc vite fait. Et merci à Lorenper pour le partage !

A découvrir ici !

  •  

Transformez n'importe quel lien en QR code LEGO fonctionnel

Vous avez des LEGO qui traînent chez vous et vous cherchez un projet un peu original à faire avec ? Hé bien j’ai trouvé un truc sympa pour vous occuper ce week-end : Construire un QR code fonctionnel en briques LEGO.

Ça s’appelle Brick QR Code et c’est un générateur en ligne qui transforme n’importe quelle URL en instructions de montage LEGO. Vous entrez votre lien, le site génère le pattern, et hop vous avez tout ce qu’il faut pour construire un QR code scannable avec vos petites briques colorées.

Un QR code c’est juste une grille de carrés noirs et blancs, et ça tombe bien parce que les LEGO 1x1, c’est totalement ça. Le site vous donne les instructions étape par étape, un modèle 3D pour visualiser le truc, et surtout une liste de pièces compatible BrickLink pour commander exactement ce qu’il vous manque.

Pour que ça marche, il faut respecter quand même quelques règles de base. D’abord, la taille minimum d’un QR code c’est 21x21 studs, mais ça peut monter plus haut selon la longueur de votre URL. Ensuite, et c’est super important, il faut absolument une bordure blanche autour du code sinon votre téléphone n’arrivera pas à le scanner. C’est le piège classique dans lequel tout le monde tombe au début.

D’ailleurs, le fait que ça soit en LEGO ne pose aucun problème de lecture. Malgré la surface un peu irrégulière des briques avec les studs qui dépassent, les smartphones modernes scannent ça sans broncher. Y’a même des gens qui font ça depuis 2009 et qui confirment que ça fonctionne nickel.

Après, c’est surtout un projet fun à faire pour le délire. Vous pouvez coller ça sur la fenêtre de votre bureau pour impressionner vos collègues, l’offrir à quelqu’un avec un lien vers une playlist ou un message perso, ou juste le faire parce que c’est cool de construire un code qui marche vraiment. Et puis c’est quand même plus classe qu’un QR code imprimé sur du papier, non ?

Voilà, si vous voulez vous lancer, prévoyez une baseplate d’au moins 32x32 studs pour avoir de la marge avec la bordure, et assurez-vous d’avoir assez de pièces 1x1 dans deux couleurs bien contrastées. Le noir et blanc c’est le plus fiable, mais techniquement n’importe quel combo de couleurs avec un bon contraste devrait passer.

A découvrir ici : Brick QR Code

  •  

LEGO vend enfin sa première pièce imprimée en 3D

Si vous pensiez que LEGO se contentait de mouler du plastique comme dans les années 50, vous vous gourez car la marque danoise vient de franchir un cap historique en commercialisant sa toute première pièce fabriquée par impression 3D dans un set grand public.

Et il leur a fallu neuf ans de R&D pour y arriver !

La pièce en question se trouve dans le set Holiday Express Train (10361) de la gamme LEGO Icons, disponible depuis octobre. C’est une mini locomotive bleue avec des roues qui tournent et une petite cheminée qui monte et qui descend quand le train avance. Bref, un petit élément décoratif en apparence, mais qui représente un sacré tournant pour l’entreprise.

Alors pourquoi neuf ans de développement pour une pièce de quelques centimètres ? (qui a dit cmb ?). Parce que LEGO ne rigole pas avec la qualité, les amis ! L’équipe de Billund a dû construire un système de fabrication additive (c’est comme ça qu’on appelle les imprimantes 3D qui ajoutent les couches les unes au dessus des autres) capable de produire des pièces en masse avec le niveau de finition attendu par les fans. Ils utilisent pour cela une technologie de fusion de poudre polymère d’EOS, plus précisément une plateforme P 500 avec résolution Fine Detail, qui utilise un laser CO₂ ultra-fin pour créer des détails impossibles à obtenir avec le moulage par injection classique.

Cela permet d’avoir des mécanismes internes, des assemblages tarabiscotés, bref des trucs qu’un moule traditionnel ne pourrait jamais faire. L’impression 3D ouvre donc des possibilités que LEGO n’avait jamais eues.

Ronen Hadar, le responsable de la fabrication additive chez LEGO, compare ce moment à l’achat de la première machine à injection par les fondateurs dans les années 40. Un changement de paradigme donc et ça va s’accélérer puisque LEGO a déjà doublé la vitesse de production de ses machines et l’objectif pour eux, c’est que ces pièces imprimées en 3D deviennent “ennuyeusement normales” dans leur catalogue, et pas des curiosités de niche pour les collectionneurs.

Voilà, pour l’instant c’est une seule petite pièce dans un set de train de Noël mais si LEGO tient ses promesses, on pourrait voir débarquer des éléments de plus en plus complexes dans les années à venir… Des briques avec des mécanismes intégrés, des formes organiques, et des trucs qu’on n’imagine même pas encore.

Source

  •  

Tor CGO - Quand chaque attaque se transforme en auto-sabotage

Bonne nouvelle, les amis, Tor vient d’implémenter CGO (Counter Galois Onion) !

Si ça ne vous dit rien, c’est normal, moi non plus je ne connaissais pas, mais je vais tout vous expliquer !

Jusqu’à maintenant, le réseau Tor protégeait votre anonymat avec du chiffrement en oignon. Plusieurs couches de crypto, une par relais et ça marche bien… sauf qu’il existe une technique vicieuse qu’on appelle les attaques par tagging.

Le tagging c’est quand un attaquant modifie votre trafic chiffré à différents endroits du réseau (genre en ajoutant un marqueur invisible dans certains noeuds), puis il observe ce qui sort de l’autre côté pour vous tracer. C’est comme quand vous collez un traceur GPS dans votre voiture, sauf que là c’est des bits dans du trafic chiffré.

Et de son côté, CGO fait encore mieux que de bloquer cette attaque. En effet, il transforme chaque attaque en auto-sabotage ! Si quelqu’un modifie ne serait-ce qu’un seul bit de votre trafic chiffré, tout le message devient illisible. Et pas seulement ce message… tous les messages futurs de la session deviennent du bruit blanc irrécupérable.

Avec ça en place, l’attaquant se tire une balle dans le pied à chaque tentative.

Derrière ce système, il y a 4 cryptographes qui ont bossé très dur : Jean Paul Degabriele, Alessandro Melloni, Jean-Pierre Münch et Martijn Stam. Ils ont publié leur recherche cette année et ça a été implémenté dans Arti, la version Rust de Tor et l’implémentation C arrive bientôt.

Ce qui change tout, c’est le calcul risque/bénéfice pour les attaquants car avant, tenter de tracer quelqu’un avait peu de conséquences si ça échouait. Mais maintenant, tenter de tracer quelqu’un détruit définitivement votre capacité à surveiller cette personne. Et vous vous en doutez, les agences de surveillance détestent perdre leur accès… Elles préfèrent observer en silence plutôt que de tout casser dans une tentative maladroite. Du coup CGO les force à choisir. Soit rester invisibles, soit tout perdre.

Et puis il y a un autre aspect génial à cette techno, c’est le forward secrecy renforcé que ça engendre car à chaque message, CGO transforme les clés de chiffrement de façon irréversible. Même si un attaquant récupère vos clés actuelles, il ne peut pas déchiffrer les messages précédents car les clés précédentes ont été broyées et remplacées à chaque étape.

CGO remplace aussi l’ancien système d’authentification qui utilisait un digest de 4 bytes par un authenticateur de 16 bytes. C’est donc bien plus costaud et plus difficile à falsifier ainsi qu’à contourner.

Comme d’hab, Tor publie l’algorithme en open source donc vous pouvez vous plonger dans le code si ça vous amuse.

Cette implémentation de CGO est encore expérimentale pour le moment, mais une fois que cela aura été éprouvé par la communauté et testé pendant plusieurs mois, voire des années, ce sera déployé officiellement dans les futurs relais, puis dans les services onion de Tor.

Voilà donc comment Tor fait de chaque tentative de surveillance un auto-sabotage irréversible, et ça les amis, c’est un message qui devrait faire réfléchir pas mal de gens dans des bureaux sans fenêtres.

Source

  •  

Tiny SVG - Compressez vos SVG sans rien uploader

Vous avez des SVG qui pèsent trop lourd pour votre site web ?

C’est pas graaaave, parce qu’il y a Tiny SVG est un outil en ligne qui compresse vos fichiers vectoriels directement depuis votre navigateur comme ça, pas besoin d’uploader vos œuvres sur un serveur externe puisque vos fichiers ne quittent jamais votre machine.

L’outil utilise SVGO en arrière-plan avec plus de 40 plugins configurables. Vous pouvez ainsi activer ou désactiver chaque optimisation selon vos besoins : Suppression des métadonnées inutiles, fusion des paths, simplification des transformations, et plein d’autres trucs. Le tout avec une prévisualisation en temps réel qui montre le SVG avant et après compression.

J’ai testé sur mon logo mais comme il est déjà super optimisé, ça ne m’a fait gagné que -0,5 % mais les résultats sont plutôt impressionnants car sur certains fichiers, Tiny SVG peut réduire la taille jusqu’à 70%. Ça dépend évidemment de la complexité du SVG d’origine et des optimisations que vous activez, mais globalement c’est très efficace.

Et y’a pas que la compression puisque Tiny SVG génère aussi du code prêt à l’emploi pour vos frameworks préférés. Vous pouvez ainsi exporter votre SVG optimisé en composant React (JSX ou TSX), Vue, Svelte, React Native ou même Flutter. Trop pratique pour ne plus avoir besoin de convertir manuellement vos icônes en composants.

Y’a aussi des fonctionnalités de transformation telles que la rotation, flip horizontal et vertical, redimensionnement…etc et vous pouvez exporter en Data URI dans plusieurs formats, et également générer des PNG ou JPEG avec les dimensions de votre choix. Le diff viewer intégré permet aussi de comparer le code SVG avant et après optimisation pour voir exactement ce qui a changé.

Côté technique, c’est une Progressive Web App qui fonctionne même hors ligne et le traitement se fait via Web Workers pour ne pas bloquer l’interface. Le projet est développé par hehehai, distribué sous licence MIT, et le code source est sur GitHub donc vous pouvez l’héberger vous-même sur Vercel, Netlify ou Docker si vous préférez avoir votre propre instance.

A tester ici : Tiny SVG !

  •  

Ackify - Pour confirmer la lecture d'un document

Benjamin, lecteur de korben.info, m’a envoyé un email pour me parler d’ Ackify , son nouveau projet open-source. L’idée avec Ackify c’est de pouvoir confirmer qu’un document a bien été lu !

Je parle pas de signature électronique, hein. Pour ça y’a déjà DocuSign, Adobe Sign, HelloSign…etc. Non, je vous parle des cas où vous avez juste besoin de prouver que Thérèse de la compta a bien reçu, ouvert et lu le PDF de la nouvelle procédure RGPD. Et pour ça, les solutions du marché sont soit surdimensionnées, soit inexistantes, du coup, les boîtes bidouillent avec des Google Forms pourris ou des macros Excel qui traînent dans le coin depuis 2003.

Ackify tourne en Docker distroless, s’installe en 5 minutes avec un script, et fonctionne sur PostgreSQL 16. L’authentification se fait via Magic Link sans mot de passe, ou OAuth 2 si vous préférez Google, GitHub ou GitLab. Ensuite, une fois connecté, vous lisez le document, vous cliquez sur “J’ai lu”, et c’est terminé. Une signature cryptographique Ed25519 est générée, le checksum SHA-256 du document est vérifié, et tout part dans un audit trail immuable.

Le principe est donc super solide et chaque utilisateur ne peut signer qu’une seule fois par document. Ensuite, vous en tant qu’admin, vous avez un dashboard pour tracker qui a lu quoi. Il y a également des rappels automatiques par email pour ceux qui traînent et des widgets que vous pouvez intégrer dans votre intranet si ça vous amuse !

Sans oublier que c’est multi-lingue !

Bref, que ce soit pour obtenir des attestations de lecture de politiques de sécurité, des formations internes avec validation, la prise en compte de directive RGPD, des procédures de conformité…etc, Ackify pourra vous aider sans avoir à sortir l’artillerie lourde de la signature électronique traditionnelle.

Voilà, c’est gratuit, open source et vous pouvez avoir tous les détails sur le site officiel du projet : ackify.eu .

  •