Forem: h13ris

Inside WatchTower: 4-layer defacement detection in async Python

h13ris — Tue, 05 May 2026 14:01:10 +0000

A defaced website is a curious problem.

It's loud — anyone visiting the page can see something is wrong. But it's also quiet from a server's perspective: HTTP returns 200, your uptime monitor is happy, your TLS cert hasn't moved, and the CMS logs show a "successful" content update from a legitimate-looking session. The signal is on the rendered page, not in the metrics.

I run a site at hi3ris.blueshield.tg and surveil a couple of dozen others for various reasons. After my third "you've been hacked, by the way" message from a friend, I got tired of trusting external uptime services that don't know what my homepage is supposed to look like. So I built WatchTower — an async-first defacement monitor that combines four detection layers, captures evidence, and alerts on multiple channels.

This post is a tour of how it actually works under the hood. We'll go through the four detection layers, the async crawler, the way the PyQt6 UI is decoupled from scanning, and what's coming next (spoiler: a local model to replace Gemini).

The full source is on github.com/hi3ris — Python 3.10+, MIT licensed.

Why four detection layers, not one?

The intuitive approach to "did the page change?" is to hash the HTML and compare. Done in three lines.

import hashlib
sha = hashlib.sha256(html.encode("utf-8", "ignore")).hexdigest()

The problem: legitimate sites change all the time. A timestamp in the footer. An ad rotator. A CSRF token in a form. A blog adding a new article. A pure SHA-256 comparison flags all of those as "changed", and you end up either drowning in false positives or whitelisting so aggressively that real defacements slip through.

A real defacement detector needs to answer a more nuanced question: "did the page change in a way that matters?" That question can't be answered by one signal alone. WatchTower stacks four:

SHA-256 of normalized text — fastest, catches anything bit-exact
Perceptual hash (pHash) of the rendered screenshot — catches visual changes, robust to text noise
TF-IDF cosine similarity between old and new text — catches semantic shifts
AI escalation (currently Gemini, soon a local model) — last-resort visual analysis on suspicious cases

Any one layer flagging is a yellow signal; multiple layers agreeing is when an alert fires. Let's look at each.

Layer 1 — SHA-256: the cheap fast pass

The first layer is just a content fingerprint. It runs on every scan, costs essentially nothing, and tells you whether anything changed at all. If the SHA matches the previous scan, you can skip the rest of the pipeline.

def calculate_sha256(self, text_content: str) -> str:
    return hashlib.sha256(text_content.encode("utf-8", "ignore")).hexdigest()

The trick is what you hash. Hashing raw HTML triggers on every dynamic element. WatchTower normalizes first — strips scripts, comments, and a few well-known dynamic attributes — then hashes the visible text only. That keeps SHA-256 useful as a "did the visible content change?" filter.

Layer 2 — Perceptual hashing: the visual eye

When the SHA-256 changes, the next question is how visually different the page is. That's a job for imagehash.phash over the rendered screenshot.

from functools import lru_cache
import imagehash
from PIL import Image

@lru_cache(maxsize=1000)
def calculate_phash(self, image_path: str) -> str:
    with Image.open(image_path) as img:
        return str(imagehash.phash(img))

def phash_distance(self, h1: str, h2: str) -> int:
    return imagehash.hex_to_hash(h1) - imagehash.hex_to_hash(h2)

pHash gives you a 64-bit hash where Hamming distance correlates with perceptual similarity. WatchTower's default threshold is distance > 10 (≈ 15% of bits flipped) before the page is flagged as visually changed. That tolerance is configurable — phash_tolerance_percent in the config — because some homepages legitimately rotate hero images.

The lru_cache(maxsize=1000) matters: when you're scanning 50 sites every 30 seconds, recomputing pHashes for unchanged screenshots burns CPU for nothing.

Layer 3 — TF-IDF: the semantic check

Visual hashing fails on text-only defacements: somebody rewriting your homepage with the exact same layout, but different words. For that we need a content similarity score.

WatchTower uses scikit-learn's TfidfVectorizer to vectorize old and new text, then cosine similarity to compare:

from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.metrics.pairwise import cosine_similarity
import numpy as np

self.vectorizer = TfidfVectorizer(
    stop_words=self.french_stop_words,
    max_features=5000,
    dtype=np.float32,
)

def text_similarity(self, old_text: str, new_text: str) -> float:
    matrix = self.vectorizer.fit_transform([old_text, new_text])
    return float(cosine_similarity(matrix[0:1], matrix[1:2])[0][0])

The threshold defaults to 0.80 — below that, the text content has shifted enough to be suspicious. Stop words live in an external file (assets/french_stop_words.txt), so the language can be swapped without touching code.

What this layer catches: a defacer overwriting your "About us" page with a manifesto. SHA-256 fires, pHash might or might not (same template, just different text), but cosine similarity drops to ~0.2 instantly.

Layer 4 — AI escalation: the judge of last resort

When the first three layers disagree, you have a borderline case: SHA changed, pHash is suspicious, semantic similarity is in a gray zone. WatchTower escalates these cases — and only these — to a vision-capable LLM with the screenshot and a focused prompt:

"Compare the previous screenshot with the current one. Has this page been defaced? Look for: hacker tags, foreign-language banners, signature payloads ("hacked by ...", "your security is an illusion"), broken layouts, or political/ideological overlays. Reply with a confidence score and a one-line justification."

Today this hits Gemini (gemini-1.5-flash-latest) with retries (2s, 8s, 32s exponential backoff) and a kill-switch — if 5 consecutive calls fail, the API is disabled for the session and the system falls back to layers 1–3 alone. Graceful degradation matters here: the monitor should never go offline because Google had a bad afternoon.

This is the layer I'm replacing. Sending screenshots to a third-party API for every borderline case is a privacy and cost problem at scale, and the prompt has to be language-agnostic which is genuinely hard. I'm training a local CNN+text classifier on a corpus of confirmed defacements (zone-h archive + my own captures) and benchmarking it head-to-head with the Gemini path. When recall plateaus around the same level, Gemini gets demoted to a fallback.

The async crawler: how it stays fast

Multi-layer detection is meaningless if you can't scan often enough. The first version of WatchTower was synchronous — and scanning 100 sites took 145 seconds per cycle. The current async version does the same in 8 seconds (18× faster on the same hardware).

The core is aiohttp with a tuned TCPConnector:

import aiohttp

self.connector = aiohttp.TCPConnector(
    limit=100,                # max total open connections
    limit_per_host=10,        # max per host — prevents single-host bottleneck
    ttl_dns_cache=300,        # 5-minute DNS cache
    enable_cleanup_closed=True,
)
self.session = aiohttp.ClientSession(connector=self.connector)

Three knobs that matter:

limit_per_host=10 is the one most people forget. Without it, scanning a slow site with 50 pages will block your entire pool.
ttl_dns_cache=300 saves a DNS round-trip on every request. For monitoring, where you hit the same hosts on a loop, this is free latency.
enable_cleanup_closed=True prevents file-descriptor leaks under sustained load — important for a long-running daemon.

Discovery is BFS-bounded:

@retry_on_network_error(max_attempts=2)
async def _fetch_and_parse_links(self, url: str) -> set[str]:
    async with self._semaphore:                    # bounds in-flight requests
        html = await self.http_client.get_html(url)
        if self.delay_between_requests > 0:
            await asyncio.sleep(self.delay_between_requests)
    return self._extract_internal_links(html, url)

A semaphore (concurrent_requests=5 by default) caps in-flight requests, and a 0.1s polite delay keeps us off WAFs' bad side. The crawler stops at max_depth=2 and max_pages=100 per site — enough to catch the homepage and immediate deep links without spidering forever.

The UI is decoupled from scanning — and that matters

The PyQt6 dashboard runs on Qt's main thread. The async crawler and detection workers run on other threads. They communicate exclusively through Qt signals:

class AnalysisWorker(QThread):
    analysis_completed = pyqtSignal(dict)   # result payload
    alert_logged = pyqtSignal(str, str, dict)

    def run(self):
        for site in self.sites:
            result = self.engine.run_layers(site)
            self.analysis_completed.emit(result)
            if result["should_alert"]:
                self.alert_logged.emit(result["alert_type"], site.url, result["evidence"])

The dashboard connects to those signals once at startup:

worker.analysis_completed.connect(dashboard.update_kpis)
worker.alert_logged.connect(alert_manager.send_alert)

The benefit: every scan cycle pushes incremental updates to the UI as soon as a site is done. KPI cards tick up in real time, the table fills row by row. No "loading..." overlay, no UI freezes — even when a single site is timing out for 30 seconds.

The alerting pipeline: throttle, capture, dispatch

A defacement alert without evidence is useless. WatchTower's alert manager runs three steps every time it fires:

Throttle check — same site, same alert type within the last 15 minutes? Suppress. (throttle_minutes config.) Without this, a flapping site would page you 50 times an hour.
Evidence capture — the screenshot, the rendered HTML, and the visible text are saved to evidence/{domain}/{timestamp}_{alert_type}/. This becomes the audit trail when you need to explain the incident.
Dispatch — Telegram (bot API with photo + Markdown caption), SMTP (HTML email with base64 screenshot), and Discord-compatible webhooks. Each channel is independent; one failing doesn't block the others.

def send_alert(self, alert_type: str, site_url: str, evidence: dict):
    if not self._should_trigger_alert(alert_type, site_url):
        return                                          # throttled
    path = self.evidence_manager.save_alert_evidence(
        url=site_url, alert_type=alert_type,
        screenshot=evidence["screenshot"],
        html_content=evidence["html"],
        text_content=evidence["text"],
    )
    for channel in self.enabled_channels:
        try:
            channel.send(alert_type, site_url, evidence, path)
        except Exception:
            log.exception("alert_channel_failed", channel=channel.name)

The try/except per channel is deliberate. Telegram going down should not eat the email; email going down should not silence the webhook.

Reputation enrichment

The same pipeline is used for IoC enrichment. When a new external host is found in a page (a script src, an image, an iframe), WatchTower checks it against:

A local IoC file (assets/ioc.txt) — instant, offline
VirusTotal v3 (rate-limited to 4 req/min — the free tier ceiling)
AbuseIPDB v2 (1 req/sec, confidence threshold 50%)

Each external API has a session-local cache and a kill-switch on consecutive failures. The principle is the same as for Gemini: the monitor must keep monitoring even if the enrichment APIs vanish.

What's next

Two things are on the roadmap:

Local model replacing Gemini. The training pipeline is in progress; the goal is a small image+text classifier (~50MB, CPU-friendly) that runs entirely offline. Privacy and cost both improve, and the prompt-engineering brittleness goes away.
Full async monitoring controller. Right now the controller still has some sync scaffolding — converting it to an async event loop would let the same process scan thousands of sites instead of hundreds.

I also want to expose a small REST API so a Grafana dashboard can pull KPIs directly, and ship a Docker image for headless deployments.

Takeaways

If you're building anything in the "watch this thing for changes" space — defacement, content drift, dependency hijack, anything — three patterns from WatchTower are worth stealing:

Stack detection layers, don't pick one. Each layer's blind spots are covered by the next, and combining cheap-to-expensive lets you short-circuit when nothing changed.
Bound everything async — semaphores, per-host connection limits, retry caps, kill-switches on failing APIs. A monitor that DDoS's its own targets or gets stuck on a single bad host is worse than no monitor.
Decouple the UI from the work — Qt signals across threads, or queues across processes, anything but blocking the loop your humans look at.

Source code, issues, and roadmap: github.com/hi3ris. More projects at hi3ris.blueshield.tg.

If you've shipped something similar — or have war stories about the perfect detection threshold — I want to hear it in the comments.

PyQt6: how to ship Python GUIs that don't look like 1998

h13ris — Mon, 04 May 2026 18:56:36 +0000

I have a confession. For years, when a developer proudly showed me their Python app — gray square buttons, a Listbox straight out of 1998 — I would politely nod. I've stopped doing that.

Not because I turned mean. Because PyQt6 exists, and there's no excuse anymore.

This article is my attempt to convince you — yes, you, the one still typing import tkinter out of habit — that something radically better is sitting one pip install away. I'll walk you through side-by-side comparisons and real snippets from a project I've been building for months: WatchTower, a website defacement monitoring system written entirely in PyQt6.

Spoiler: by the end, you'll want to rewrite everything you ever shipped in Tkinter.

The Tkinter problem in three lines

Let's be honest. Tkinter ships with Python, it's free, it's documented, and it works. That's the whole pitch. The rest is masochism.

# Tkinter — a "dashboard" that hurts to look at
import tkinter as tk
from tkinter import ttk

root = tk.Tk()
root.title("My fancy tool")
root.geometry("400x300")

label = tk.Label(root, text="Status: OK", bg="grey", fg="white")
label.pack(pady=10)

button = tk.Button(root, text="Scan")
button.pack()

root.mainloop()

You get something gray, flat, screaming "1998" at the top of its lungs. Want to change the font? Fight with font=("Arial", 10). Want a dark theme? Good luck. Want a real-time chart? Cram matplotlib in there and pray.

The same thing in PyQt6

Now look at the equivalent in PyQt6:

# PyQt6 — clean, modern, stylable
import sys
from PyQt6.QtWidgets import (
    QApplication, QMainWindow, QLabel, QPushButton, QVBoxLayout, QWidget
)

class MainWindow(QMainWindow):
    def __init__(self):
        super().__init__()
        self.setWindowTitle("My fancy tool")
        self.resize(400, 300)

        central = QWidget()
        layout = QVBoxLayout(central)

        self.label = QLabel("Status: OK")
        self.button = QPushButton("Scan")
        self.button.clicked.connect(self.on_scan)

        layout.addWidget(self.label)
        layout.addWidget(self.button)
        self.setCentralWidget(central)

        self.setStyleSheet("""
            QMainWindow { background-color: #282c34; }
            QLabel { color: #61afef; font-size: 14pt; font-weight: bold; }
            QPushButton {
                background-color: #61afef; color: #282c34;
                border-radius: 6px; padding: 8px 16px; font-weight: bold;
            }
            QPushButton:hover { background-color: #56a4e0; }
        """)

    def on_scan(self):
        self.label.setText("Scanning...")

app = QApplication(sys.argv)
window = MainWindow()
window.show()
sys.exit(app.exec())

A few extra lines. But the result? A dark window, a button with rounded corners and a hover effect, readable typography. And we didn't install a single external theme.

Why PyQt6 changes the game

1. Stylesheets (QSS) are basically CSS for your app

This is probably the most underrated feature in Qt. If you know CSS, you already know 80% of QSS. Here's a slice of the dark theme I use in WatchTower:

QWidget {
    background-color: #282c34;
    color: #abb2bf;
    font-family: "Segoe UI", "Roboto", sans-serif;
    font-size: 10pt;
}
QPushButton {
    background-color: #3a3f4b;
    border: 1px solid #4b5263;
    border-radius: 4px;
    padding: 6px 12px;
}
QPushButton:hover { background-color: #4b5263; }
QHeaderView::section {
    background-color: #21252b;
    color: #e6efff;
    padding: 6px;
}

Load it from a .qss file, apply it via app.setStyleSheet(qss), and the whole app is themed in one shot. Light, dark, cyan, accessible — you swap a string. With Tkinter you styled widget by widget, by hand, while quietly weeping.

2. The signal/slot system is a superpower

In Tkinter, components talk to each other through callbacks and sad global variables. In Qt, every widget can emit signals, and anything else can subscribe.

In WatchTower I have clickable KPI cards that emit a card_clicked signal carrying the card's title ("ACTIVE ALERTS", "MONITORED SITES", etc.). The dashboard listens and filters the list accordingly:

from PyQt6.QtCore import pyqtSignal
from PyQt6.QtWidgets import QFrame

class KpiCard(QFrame):
    card_clicked = pyqtSignal(str)  # declares a signal that emits a string

    def mousePressEvent(self, event):
        self.card_clicked.emit(self.title)
        super().mousePressEvent(event)

# On the dashboard side:
self.alerts_card.card_clicked.connect(self.filter_by_category)

Decoupled. Testable. Scalable. The widget doesn't know who's listening, the listener doesn't know where the signal came from. Real event-driven design — not three layers of command=lambda: ... stacked on top of each other.

3. Threading that doesn't freeze your UI

The worst moment in any Tkinter app is when you fire off a long-running operation and the window goes white for 30 seconds. You know it. We all know it.

PyQt gives you QThread and QRunnable with QThreadPool, and signals work across threads. In WatchTower, my async scanner runs in a dedicated worker and pipes results back to the UI through signals:

from PyQt6.QtCore import QThread, pyqtSignal

class ScanWorker(QThread):
    progress = pyqtSignal(int, str)        # %, message
    site_done = pyqtSignal(dict)           # structured result
    finished = pyqtSignal()

    def __init__(self, sites):
        super().__init__()
        self.sites = sites

    def run(self):
        for i, site in enumerate(self.sites):
            result = self.scan_one(site)   # blocking — that's fine in here
            self.progress.emit(int(100 * (i+1) / len(self.sites)), site["url"])
            self.site_done.emit(result)
        self.finished.emit()

# In the main window:
self.worker = ScanWorker(my_sites)
self.worker.progress.connect(self.statusBar().showMessage)
self.worker.site_done.connect(self.dashboard.add_result)
self.worker.start()

The UI stays responsive. You can scroll, click elsewhere, open a dialog. Tkinter doesn't do this natively, and the threading + after() workarounds are fragile.

4. The widgets you actually want in 2026

Tkinter gives you a Listbox. Qt gives you QListView, QTableView, QTreeView with a proper model/view system, sorting, filtering, inline editing, drag & drop, and virtualization for millions of rows. Drop a QSortFilterProxyModel on top and you get text search for free.

For real-time charts, you have QtCharts (official) or pyqtgraph (extremely fast, perfect for monitoring dashboards). In WatchTower I plot live alert counts and CPU usage with zero lag.

And icons? One line with qtawesome:

import qtawesome as qta
button.setIcon(qta.icon("fa5s.shield-alt", color="#61afef"))

Thousands of Font Awesome, Material Design, and Elusive icons — recolorable, resizable, vectorial.

WatchTower, the project that converted me

I built WatchTower, a website defacement monitoring system, because I needed a real-time dashboard surveilling dozens of sites. Here's what PyQt6 let me do painlessly:

A modern dashboard with clickable KPI cards, live stats, and a multi-site grid (1, 2, or 4 sites in parallel)
Embedded WebViews (QWebEngineView) showing the actual rendered pages — practically impossible to do cleanly in Tkinter
A theming system: dark, light, cyan — hot-swappable without restarting
Async workers that scan in parallel without freezing the interface
Incident timelines, multi-tab config dialogs, system tray, native notifications, PDF report generation…

Every UI brick is a reusable widget that emits its own signals. When I add a new data source, I don't rewrite half the interface — I wire up a signal and move on.

The same project in Tkinter? Either it wouldn't exist, or it'd be 10,000 lines of spaghetti.

"But Tkinter is in the standard library!"

Yes. So is urllib, and yet everyone uses requests. Performance and ergonomics matter more than skipping a pip install.

For reference:

pip install PyQt6 qtawesome pyqtgraph

That's all you need to ship apps that look like real tools, not freshman CS projects.

PyQt6 vs PyQt5?

I started on PyQt5 and moved to PyQt6 a while back. The main differences:

Namespaced enums: Qt.AlignCenter becomes Qt.AlignmentFlag.AlignCenter. More verbose, but much clearer.
exec_() is now exec(): Python 3 freed the keyword.
Cleaner, better typed, and that's the version Qt keeps investing in.

If you're starting today, go straight to PyQt6 (or PySide6 if you want the LGPL license).

Where to start

Créer des interfaces Python modernes et fluides avec PyQt6

h13ris — Mon, 04 May 2026 18:29:44 +0000

J'ai un aveu à faire : pendant longtemps, quand un dev me montrait fièrement son app Python avec un bouton gris carré et une Listbox qui sentait Windows 95, je hochais la tête poliment. Aujourd'hui, j'ai arrêté.

Pas parce que je suis devenu méchant. Parce que PyQt6 existe, et qu'il n'y a plus aucune excuse.

Cet article, c'est ma tentative de te convaincre — toi qui ouvres encore tkinter par réflexe — qu'il existe quelque chose de radicalement mieux. Je vais te montrer pourquoi, à travers des comparaisons côte à côte et des extraits réels du projet sur lequel je bosse depuis des mois : WatchTower, un système de monitoring de défacement web construit entièrement avec PyQt6.

Spoiler : à la fin, tu vas vouloir réécrire tout ce que tu as fait avec Tkinter.

Le dashboard principal de WatchTower. 100 % PyQt6, sans framework JS, sans Electron.

Le drame Tkinter en trois lignes

Soyons honnêtes deux secondes. Tkinter est livré avec Python, c'est gratuit, c'est documenté, et ça marche. Voilà. C'est le seul argument. Le reste, c'est du masochisme.

# Tkinter — un "dashboard" qui fait pleurer
import tkinter as tk
from tkinter import ttk

root = tk.Tk()
root.title("Mon super outil")
root.geometry("400x300")

label = tk.Label(root, text="Statut : OK", bg="grey", fg="white")
label.pack(pady=10)

button = tk.Button(root, text="Scanner")
button.pack()

root.mainloop()

Tu obtiens un truc gris, plat, et qui te crie « 1998 » en pleine figure. Tu veux changer la police ? Tu te bagarres avec font=("Arial", 10). Tu veux un thème sombre ? Bon courage. Tu veux un graphique en temps réel ? Tu intègres matplotlib au chausse-pied et tu pries.

La même chose en PyQt6

Maintenant regarde le même bidule en PyQt6 :

# PyQt6 — propre, moderne, et stylable
import sys
from PyQt6.QtWidgets import (
    QApplication, QMainWindow, QLabel, QPushButton, QVBoxLayout, QWidget
)

class MainWindow(QMainWindow):
    def __init__(self):
        super().__init__()
        self.setWindowTitle("Mon super outil")
        self.resize(400, 300)

        central = QWidget()
        layout = QVBoxLayout(central)

        self.label = QLabel("Statut : OK")
        self.button = QPushButton("Scanner")
        self.button.clicked.connect(self.on_scan)

        layout.addWidget(self.label)
        layout.addWidget(self.button)
        self.setCentralWidget(central)

        self.setStyleSheet("""
            QMainWindow { background-color: #282c34; }
            QLabel { color: #61afef; font-size: 14pt; font-weight: bold; }
            QPushButton {
                background-color: #61afef; color: #282c34;
                border-radius: 6px; padding: 8px 16px; font-weight: bold;
            }
            QPushButton:hover { background-color: #56a4e0; }
        """)

    def on_scan(self):
        self.label.setText("Scan en cours...")

app = QApplication(sys.argv)
window = MainWindow()
window.show()
sys.exit(app.exec())

À peine plus de lignes. Mais le résultat ? Une fenêtre sombre, un bouton avec coins arrondis, un effet hover, et une typo lisible. Et tout ça sans installer un seul thème externe.

Tkinter (à gauche) vs PyQt6 (à droite). Devine lequel donne envie de cliquer.

Pourquoi PyQt6 change la donne

1. Les stylesheets (QSS), c'est du CSS pour ton app

C'est probablement la fonctionnalité la plus sous-estimée de Qt. Tu connais CSS ? Alors tu connais déjà 80 % de QSS. Voici un extrait du thème sombre que j'utilise dans WatchTower :

QWidget {
    background-color: #282c34;
    color: #abb2bf;
    font-family: "Segoe UI", "Roboto", sans-serif;
    font-size: 10pt;
}
QPushButton {
    background-color: #3a3f4b;
    border: 1px solid #4b5263;
    border-radius: 4px;
    padding: 6px 12px;
}
QPushButton:hover { background-color: #4b5263; }
QHeaderView::section {
    background-color: #21252b;
    color: #e6efff;
    padding: 6px;
}

Tu charges ça depuis un fichier .qss, tu l'appliques avec app.setStyleSheet(qss), et toute l'application est habillée d'un coup. Thème clair, sombre, cyan, accessible : il suffit de switcher la string. Avec Tkinter, tu changeais ça widget par widget, à la main, en pleurant.

2. Le système signaux/slots, c'est un super-pouvoir

Dans Tkinter, la communication entre composants se fait avec des callbacks et des variables globales tristes. En Qt, chaque widget peut émettre des signaux, et n'importe qui peut s'y connecter.

Dans WatchTower, j'ai des cartes KPI cliquables qui émettent un signal card_clicked portant le titre de la carte (« ALERTES ACTIVES », « SITES SURVEILLÉS », etc.). Le dashboard écoute ce signal et filtre la liste en conséquence :

from PyQt6.QtCore import pyqtSignal
from PyQt6.QtWidgets import QFrame

class KpiCard(QFrame):
    card_clicked = pyqtSignal(str)  # déclare un signal qui émet une string

    def mousePressEvent(self, event):
        self.card_clicked.emit(self.title)
        super().mousePressEvent(event)

# Côté dashboard :
self.alerts_card.card_clicked.connect(self.filter_by_category)

C'est découplé, testable, et ça scale. Le widget ne sait pas qui l'écoute, et le listener ne sait pas d'où vient le signal. Du vrai event-driven, pas du command=lambda: ... empilé sur trois étages.

3. Le threading qui ne fait pas freezer ton UI

Le pire moment d'une app Tkinter, c'est quand tu lances une opération longue et que la fenêtre devient blanche pendant 30 secondes. Tu connais. Tout le monde connaît.

PyQt te donne QThread et QRunnable avec QThreadPool, et les signaux marchent à travers les threads. Concrètement, dans WatchTower, mon scanner async tourne dans un worker dédié et envoie les résultats à l'UI via signaux :

from PyQt6.QtCore import QThread, pyqtSignal

class ScanWorker(QThread):
    progress = pyqtSignal(int, str)        # %, message
    site_done = pyqtSignal(dict)           # résultat structuré
    finished = pyqtSignal()

    def __init__(self, sites):
        super().__init__()
        self.sites = sites

    def run(self):
        for i, site in enumerate(self.sites):
            result = self.scan_one(site)   # blocking, mais c'est OK ici
            self.progress.emit(int(100 * (i+1) / len(self.sites)), site["url"])
            self.site_done.emit(result)
        self.finished.emit()

# Dans la fenêtre principale :
self.worker = ScanWorker(my_sites)
self.worker.progress.connect(self.statusBar().showMessage)
self.worker.site_done.connect(self.dashboard.add_result)
self.worker.start()

L'UI reste fluide. Tu peux scroller, cliquer ailleurs, ouvrir un dialog. Tkinter ne fait pas ça nativement, et les workarounds avec threading + after() sont fragiles.

4. Les widgets qu'on attend en 2026

Tkinter te donne une Listbox. Qt te donne QListView, QTableView, QTreeView avec un système modèle/vue (MVC), tri, filtre, édition inline, drag & drop, virtualisation pour des millions de lignes. Tu peux brancher un QSortFilterProxyModel au-dessus de ton modèle et obtenir une recherche textuelle gratuite.

Pour les graphiques en temps réel, tu as QtCharts (officiel) ou pyqtgraph (très rapide, parfait pour du monitoring). Dans WatchTower, j'affiche en live l'évolution des alertes et la consommation CPU sans aucun freeze.

Quatre sites surveillés en parallèle avec leur vrai rendu HTML. Bonne chance à faire ça en Tkinter.

Et pour les icônes ? Une seule ligne avec qtawesome :

import qtawesome as qta
button.setIcon(qta.icon("fa5s.shield-alt", color="#61afef"))

Des milliers d'icônes Font Awesome, Material Design, Elusive — colorables, redimensionnables, vectorielles.

WatchTower, le projet qui m'a fait basculer

J'ai construit WatchTower, un système de monitoring de défacement web, pour avoir un tableau de bord temps réel surveillant des dizaines de sites. Voici ce que PyQt6 m'a permis de faire sans douleur :

Dashboard moderne avec cartes KPI cliquables, statistiques live, et grille multi-sites (1, 2 ou 4 sites en parallèle)
WebViews intégrées (QWebEngineView) qui affichent le rendu réel des sites surveillés — impossible à faire proprement en Tkinter
Système de thèmes : sombre, clair, cyan, switchable à chaud sans relancer l'app
Workers async qui scannent en parallèle sans figer l'interface
Timeline d'incidents, dialogs de configuration multi-onglets, system tray, notifications natives, génération de rapports PDF…

Chaque brique de l'UI est un widget réutilisable qui émet ses propres signaux. Quand j'ajoute une nouvelle source de données, je n'ai pas à réécrire la moitié de l'interface : je connecte un signal, et c'est plié.

Sept onglets, chacun étant un widget indépendant. C'est ça, la modularité.

Le même projet en Tkinter ? Soit il n'aurait pas existé, soit il aurait fait 10 000 lignes de spaghetti.

« Mais Tkinter est dans la stdlib ! »

Oui. Et urllib aussi, mais tout le monde utilise requests. La performance et l'ergonomie comptent plus que l'absence d'un pip install.

Pour info :

pip install PyQt6 qtawesome pyqtgraph

Et tu as de quoi faire des apps qui ressemblent à des outils pros, pas à un TP de L1.

Et PyQt6 vs PyQt5 ?

J'ai démarré sur PyQt5, je suis passé à PyQt6 il y a un moment. Les différences principales :

Enums namespacées : Qt.AlignCenter devient Qt.AlignmentFlag.AlignCenter. Plus verbeux, mais beaucoup plus clair.
exec_() devient exec() : Python 3 a libéré le mot-clé.
Plus propre, mieux typé, et c'est la version sur laquelle Qt continue d'investir.

Si tu démarres aujourd'hui, va directement sur PyQt6 (ou PySide6 si tu veux la licence LGPL).

Par où commencer

pip install PyQt6
Code une fenêtre minuscule. Ressens la satisfaction d'un bouton qui a l'air normal.
Découvre QSS, joue avec un thème sombre.
Fais ton premier signal/slot custom.
Ajoute qtawesome et pyqtgraph quand tu veux passer au niveau au-dessus.

La doc de Qt est dense mais excellente, et 90 % du temps, ce que tu cherches existe déjà comme widget officiel.

Conclusion

Faire des interfaces moches en 2026 est un choix, pas une fatalité. PyQt6 te donne du QSS façon CSS, des signaux/slots qui tiennent la route, du threading propre, et un catalogue de widgets qui couvre la quasi-totalité des besoins.

Si tu veux voir ce que ça donne à grande échelle, j'ai mis WatchTower en open-source sur github.com/hi3ris, et le reste de mes projets traîne sur hi3ris.blueshield.tg si tu veux jeter un œil. Et si après ça tu reviens à Tkinter pour ta prochaine app desktop, c'est qu'on n'aura vraiment pas eu la même conversation.

Allez, à toi de jouer. Et arrête de pondre des Listbox grises.

Si cet article t'a parlé, lâche un ❤️ et un 🦄 — et dis-moi en commentaire le pire crime UI que tu aies commis avec Tkinter. Promis, pas de jugement (enfin, un peu).

A Website at Home? Yep, Even Without a Static IP!

h13ris — Fri, 06 Jun 2025 23:03:13 +0000

It all started with a joke...

"You know, you could also host your site at home."

It's possible, yes. And I thought to myself: how could I do it... for FREE?

To make a site accessible from the internet, what do you need?

A server – in my case, it'll be my desktop.
A public IP – I have one, but it's dynamic (it changes).
Continuous uptime – and with the power cuts around here, we can forget about that.
A domain name – because sharing your IP address isn't very cool.

I'll handle finding solutions for points 1, 2, and 4.
As for point 3, I'll leave that to the power company (good luck, folks, I'm counting on you 😉).

Goal: Get a free domain name that automatically points to my public IP, even when it changes.

This is the part where I'm supposed to tell you how I discovered America and defeated Satan before stumbling upon the FreedomBox project, blah blah blah...

But let's be serious: today, I'm talking about GnuDIP, a DDNS service that FreedomBox introduced me to – and it's the real deal.

What is GnuDIP?

GnuDIP is a Dynamic DNS (DDNS) service.
It allows you to link a domain name to a changing IP address – typically what you have if you're with a standard ISP.

The public instance available at gnudip.datasystems24.net offers two free domains:

freedombox.rocks
sds-ip.de

And yes, it's 100% free.

Tutorial: Using GnuDIP to Get a Free Subdomain

Step 1: Create an Account

Go to https://gnudip.datasystems24.net
And sign up:

Step 2: Create a Subdomain

Hostname: choose a short, simple name with no special characters.
Domain: select sds-ip.de or freedombox.rocks.

Once registered, go back to the login page and sign in.

By default, the domain points to the IP you used to connect.

But you can change it manually:

Even Better: Automatically Update Your Public IP

If your IP changes regularly (as it does with many providers), GnuDIP offers a simple solution: the "Quick Login URL".

Just click on "Set quick login URL", copy the link, and use it in a small script that runs regularly, using cron for example.

A simple curl to this link will automatically update the domain's IP:


bash
curl "[https://gnudip.datasystems24.net/nic/update?username=...&password=...&hostname=](https://gnudip.datasystems24.net/nic/update?username=...&password=...&hostname=)..."

Are Quantum Computers Really Going to Break the Internet?

h13ris — Fri, 06 Jun 2025 22:28:44 +0000

It's all you hear about these days. The great "crypto-geddon" is coming. The quantum machine that will obliterate our passwords, our banks—our entire digital world.

So, is it time to panic? Sell your Bitcoin, build a bunker? Or is this just another tech-apocalypse storm in a teacup?

Let's be real and break it down.

So, What's the Actual Flaw?

To put it simply, modern web security is like a padlock. It relies on a mathematical principle: it's super easy to multiply two huge prime numbers together, but it's a total nightmare to do the reverse. If I give you the result, it would take a normal computer thousands of years to figure out the two original numbers.

The problem is, a researcher named Peter Shor figured out an algorithm back in 1994 that, on a quantum computer, could do that math in a few hours.

So yes, on paper, the threat is real. Our current locks (the ones called RSA and ECC) have a known weakness. The question isn't if they're vulnerable, but when someone will have the key to open them.

Okay, But When is the Real Danger?

Take a breath. No, your bank account isn't getting drained tomorrow. Building a quantum computer powerful enough to do this is an incredibly complex feat of engineering. We're still a long way off. The most serious estimates point to 10, 15, or even 20 years from now.

So, why is everyone talking about it now?

Because of a much more insidious idea: Harvest Now, Decrypt Later.

That's the real danger today. Imagine intelligence agencies or criminal groups vacuuming up and storing tons of encrypted data that they can't currently read. They're just waiting patiently. The day they get their hands on a quantum computer, they can unpack all of our past secrets.

Your work emails, trade secrets, health records... if that information needs to stay secret for more than 10 years, the problem isn't in the future. It's right now.

Luckily, the Experts Haven't Been Sleeping.

Faced with this, the crypto community has been at work for years. The solution is called Post-Quantum Cryptography (PQC).

The concept? If thieves learn how to pick our current locks, let's just switch to a completely different kind of lock. Let's use weird math problems that even a quantum computer can't solve. It's as simple as that.

NIST (the U.S. institute that sets the tone for tech standards) launched a global competition years ago to find the best ones. The winners have been announced, and names like Kyber and Dilithium are the new rock stars.

And in the Real World, Is It Actually Being Deployed?

The good news is, this isn't just theory anymore. It's already in the wild.

Your Signal app is already using one of these new algorithms to protect your messages, specifically against data harvesting.
Your Chrome browser is quietly testing and deploying a hybrid security model (classic + post-quantum) to keep your HTTPS connections safe.
Tech giants, from Microsoft to the Linux community, are currently integrating these algorithms into the core of their systems.

The transition has definitely begun.

The 'But' in the Story (Because There's Always One).

If everything is going so well, why is it taking so long? Because the task is monumental.

Key Size. The new keys are much larger. It makes no difference to you and me, but for billions of small IoT devices or high-speed banking systems, it's a real headache.
Inertia from the 'Old World'. Crypto is everywhere. In 20-year-old legacy software, in satellites, in cars... Updating all of that without breaking anything is a titanic effort.
The Expert Shortage. There are very few people who truly master this subject from A to Z. A whole generation of developers will need to be trained on these new tools.

So, Do We Panic or Not?

No, there's no need to panic. Crying "crypto-geddon" is over the top.

But you can't be naive, either. The threat is real, and the danger of data harvesting is immediate. The good news is that the solution is already in motion.

That's where the real work is: for companies, it's time to start looking for the old locks and figuring out how to change them. For us developers, it's time to start learning and playing with these new libraries.

It's less spectacular than crying wolf, for sure. But it's how we actually move forward.

L'ordinateur quantique va casser Internet. Vraiment ?

h13ris — Fri, 06 Jun 2025 22:24:09 +0000

On n'entend que ça en ce moment. Le grand "crypto-geddon" qui arrive. La machine quantique qui va pulvériser nos mots de passe, nos banques, bref, tout notre monde numérique.

Alors, on cède à la panique ? On vend ses Bitcoins, on se construit un bunker ? Ou est-ce que c'est encore une de ces tempêtes dans un verre d'eau de la tech ?

Franchement, faisons le tri.

La faille, elle est où au juste ?

Pour faire simple, aujourd'hui, la sécurité du web, c'est un peu comme une serrure. Elle repose sur un principe mathématique : c'est super facile de multiplier deux très grands nombres, mais c'est un cauchemar de faire l'inverse. Si je vous donne le résultat, retrouver les deux nombres de départ vous prendrait des milliers d'années avec un ordi normal.

Le problème, c'est qu'un chercheur, Peter Shor, a imaginé en 1994 un algorithme qui, sur un ordinateur quantique, ferait ce calcul en quelques heures.

Donc oui, sur le papier, la menace existe. Nos serrures actuelles (celles qui s'appellent RSA et ECC) ont bien une faiblesse connue. La question n'est pas de savoir si elles sont vulnérables, mais quand quelqu'un aura l'outil pour les ouvrir.

OK, mais le vrai danger, c'est pour quand ?

Respirez. Non, votre compte en banque ne sera pas vidé demain. Un ordinateur quantique assez puissant pour ça, c'est une bête incroyablement complexe à construire. On en est encore loin. Les estimations les plus sérieuses parient sur 10, 15, voire 20 ans.

Alors, pourquoi on en parle maintenant ?

À cause d'une idée bien plus vicieuse : Récolter maintenant, déchiffrer plus tard.

C'est ça, le vrai danger aujourd'hui. Imaginez des services de renseignement ou des groupes criminels qui aspirent et stockent des tonnes de données chiffrées qu'ils ne peuvent pas lire. Ils attendent juste, patiemment. Le jour où ils auront la machine quantique, ils pourront déballer tous nos secrets passés.

Vos emails pros, des secrets industriels, des données médicales... Si ces infos doivent rester secrètes dans 10 ans, le problème n'est plus du tout futuriste. Il est bien présent.

Heureusement, les experts n'ont pas dormi.

Face à ça, la communauté crypto s'est mise au boulot depuis des années. La solution, c'est ce qu'on appelle la cryptographie post-quantique (PQC).

Le concept ? Si les voleurs apprennent à crocheter nos serrures actuelles, changeons de type de serrure. Utilisons des problèmes mathématiques tordus que même un ordinateur quantique ne sait pas résoudre. C'est aussi simple que ça.

Le NIST (l'institut américain qui fait la pluie et le beau temps sur les standards) a lancé une compétition mondiale il y a des années pour trouver les meilleures. Les gagnants ont été annoncés, et des noms comme Kyber ou Dilithium sont les nouvelles stars.

Et concrètement, ça se déploie ?

La bonne nouvelle, c'est que ce n'est plus de la théorie. Ça tourne déjà.

Votre appli Signal utilise déjà un de ces nouveaux algorithmes pour protéger vos messages, justement contre la récolte de données.
Votre navigateur Chrome teste et déploie discrètement une sécurité hybride (classique + post-quantique) pour s'assurer que vos connexions HTTPS restent sûres.
Les grands de la tech, de Microsoft à la communauté Linux, sont en train de les intégrer au cœur de leurs systèmes.

La transition a bel et bien commencé.

Le "mais" de l'histoire (parce qu'il y en a un).

Si tout va bien, pourquoi ça prend du temps ? Parce que le chantier est immense.

La taille des clés. Les nouvelles clés sont beaucoup plus grosses. Ça ne change rien pour vous et moi, mais pour des milliards de petits objets connectés ou des systèmes bancaires ultra-rapides, c'est un vrai casse-tête.
L'inertie du "vieux monde". La crypto est partout. Dans des vieux logiciels qui tournent depuis 20 ans, dans des satellites, des voitures... Mettre à jour tout ça sans rien casser est un travail de titan.
Le manque d'experts. Il y a très peu de gens qui maîtrisent vraiment le sujet de A à Z. Il va falloir former toute une génération de développeurs à ces nouveaux outils.

Alors, on panique ou pas ?

Non, pas la peine de paniquer. Crier au "crypto-geddon" est exagéré.

Mais il ne faut pas être naïf non plus. La menace est réelle, et le danger de la récolte de données est immédiat. La bonne nouvelle, c'est que la solution est en marche.

Le vrai boulot, il est là : pour les entreprises, il faut commencer à regarder où sont les vieilles serrures et comment les changer. Pour nous, les développeurs, il est temps de commencer à se former et à jouer avec ces nouvelles bibliothèques.

C'est moins spectaculaire que de crier au loup, c'est sûr. Mais c'est comme ça qu'on avance.

Site web à la maison ? Oui, même sans IP public!

h13ris — Thu, 15 May 2025 11:36:29 +0000

Tout est parti d'une blague...

"Tu peux aussi héberger ton site chez toi."

C'est possible, oui. Et je me suis dit : comment est-ce que je pourrais le faire... GRATUITEMENT ?

Pour rendre un site accessible depuis Internet, il faut quoi ?

Un serveur – dans mon cas, ce sera mon desktop.
Une IP publique – j'en ai une, mais elle est dynamique (elle change).
Une disponibilité continue – et là, avec les coupures d’électricité, on oublie
Un nom de domaine – parce que donner son IP, c’est pas très sexy.

Je me charge de trouver des solutions pour les points 1, 2 et 4.

Le point 3, je le laisse à la CEET (courage les gars, je compte sur vous ).

Objectif : Avoir un nom de domaine gratuit qui s’adapte automatiquement à mon IP publique, même quand elle change.

C’est le moment où je devrais vous raconter comment j’ai découvert l’Amérique et vaincu Satan avant de tomber sur le projet FreedomBox, blablabla...

Mais restons sérieux : aujourd’hui, je vous parle de GnuDIP, un service DDNS que FreedomBox m’a fait découvrir – et c’est du lourd.

C’est quoi GnuDIP ?

GnuDIP est un service de DNS dynamique (DDNS).

Il permet de lier un nom de domaine à une adresse IP changeante – typiquement ce que tu as si tu es chez un FAI standard.

L’instance publique dispo sur gnudip.datasystems24.net propose deux domaines gratuits :

freedombox.rocks
sds-ip.de

Et oui, c’est 100 % gratuit.

Tutoriel : Utiliser GnuDIP pour obtenir un sous-domaine gratuit

Étape 1 : Création d’un compte

Rendez-vous sur https://gnudip.datasystems24.net

Et inscrivez-vous :

Étape 2 : Créer un sous-domaine

Hostname : choisissez un nom court, simple, sans caractères spéciaux.
Domain : sélectionnez sds-ip.de ou freedombox.rocks.

Une fois enregistré, retournez sur la page de connexion et connectez-vous.

Par défaut, le domaine pointe vers l’IP que vous avez utilisée pour vous connecter.

Mais vous pouvez la modifier manuellement :

Mieux encore : Mettez à jour automatiquement votre IP publique

Si votre IP change régulièrement (comme chez beaucoup de fournisseurs), GnuDIP vous propose une solution simple : le "Quick Login URL".

Il suffit de cliquer sur "Set quick login URL", copier le lien, et l’utiliser dans un petit script qui s’exécute régulièrement via cron par exemple.

Un simple curl vers ce lien mettra automatiquement à jour l’IP du domaine :

curl "https://gnudip.datasystems24.net/nic/update?username=...&password=...&hostname=..."

Et tada !!!

Votre domaine gratuit pointe vers votre réseau local, même si votre IP change.

Il ne vous reste plus qu’à faire une redirection de port sur votre routeur pour exposer un service (web, SSH, etc.).

Bonus1 : Et DuckDNS alors ?

Si vous préférez une alternative encore plus simple, il y a aussi DuckDNS.org, qui offre des sous-domaines en duckdns.org et fonctionne aussi avec un script ou une URL à appeler périodiquement.

Configuration de base (avec cron) :

echo "url=https://www.duckdns.org/update?domains=MONDOMAINE&token=MONTOKEN&ip=" | curl -k -o ~/duckdns/duck.log -K

Et ajoutez ce script à votre crontab :

*/5 * * * * ~/duckdns/update.sh >/dev/null 2>&1

Bonus : Se connecter à son serveur chez soi en SSH grâce au domaine dynamique

Maintenant que votre domaine pointe toujours vers votre IP publique, vous pouvez même l'utiliser pour accéder à votre machine à distance via SSH.

Exemple : connexion SSH avec domaine GnuDIP

Imaginons que vous avez configuré le domaine monserveur.sds-ip.de pour pointer vers votre IP publique.

Sur votre machine distante (là où vous voulez te connecter), il vous suffit d'utiliser :

ssh utilisateur@monserveur.sds-ip.de

Et voilà, vous êtes chez vous

Pré-requis côté maison :

Votre box/routeur doit rediriger le port 22 (ou un port personnalisé si vous avez modifié sshd) vers votre machine.
Votre machine doit être allumée et le service SSH actif.

Astuce sécurité : changez le port SSH par défaut, utilisez une clé SSH au lieu du mot de passe, et configurez fail2ban pour limiter les attaques.

Cette configuration, combinée au domaine dynamique, vous permet un accès sécurisé et stable à votre environnement local, même si votre IP change toutes les 12 heures !

Conclusion

Finalement, j’ai quand même pris un VPS pour héberger mon portfolio.

Mais, juste pour le fun, il est aussi dispo via GnuDIP ici :

https://hi3ris.sds-ip.de