Préserver l’origine, changer le modèle de confiance.
Le JDoor d’origine était un projet scolaire de 2022 que Djenis a réalisé avec un collaborateur. Il démontrait le réseau en Java, la capture d’écran et les entrées distantes. Cette origine commune reste dans l’historique : le travail ultérieur ne présente pas le prototype scolaire comme une réalisation individuelle.
Une démonstration n’est pas encore un produit d’assistance. L’ancien design traitait une connexion entrante comme un canal de contrôle, sans appairage fortement authentifié, état de consultation seule ni cycle complet pour les touches bloquées, erreurs de socket et arrêts. La modernisation a donc commencé par limiter ce que l’application est autorisée à faire.
Règles de l’assistance autorisée.
Le produit reconstruit suit quatre contraintes non négociables :
- Chaque session sert exclusivement une assistance autorisée et initiée par les deux personnes : l’hôte reste visible, approuve localement chaque viewer et n’expose jamais d’accès sans surveillance ou en arrière-plan.
- Le chemin réseau peut être observé ou modifié ; le viewer doit donc authentifier le certificat éphémère exact et présenter le jeton à usage unique de courte durée reçu hors bande.
- Consultation de l’écran et contrôle distant sont deux permissions distinctes ; le contrôle démarre désactivé, l’hôte peut le retirer immédiatement et la révocation ou la déconnexion libère touches et boutons suivis.
- Les entrées du protocole ne sont pas fiables : messages, images, délais, workers et nettoyage exigent des bornes explicites, des règles directionnelles et une fermeture déterministe.
Assistance à distance, pas administration distante.
La décision centrale n’était pas de masquer ou d’étendre l’ancien chemin de contrôle. Il fallait le remplacer par une frontière produit qui rend le consentement visible et retire du design persistance, exécution de shell et accès sans surveillance.
Pour la modernisation, Djenis a séparé identité TLS et appairage, protocole encadré, état de session, capture, politique d’entrée, événements d’audit et présentation Swing. Authentification, approbation, consultation et contrôle deviennent des états distincts, non des effets secondaires de l’ouverture d’une socket.
Une session construite autour d’un consentement explicite.
L’interface hôte crée une identité éphémère et un lien à usage unique. Le viewer épingle ce certificat, présente le jeton et attend l’approbation locale. Le canal borné ne transporte les images qu’ensuite ; souris et clavier ne sont appliqués que lorsque la session hôte active possède une autorisation de contrôle explicite.
Pourquoi ces technologies.
Chaque choix limite JDoor à l’assistance temporaire et visible prévue par son modèle de confiance.
Java et Swing pour l’application de bureau.
- Pourquoi
- Ils préservent le code existant et utilisent directement AWT pour la capture, les entrées et les interfaces natives sous Java 21.
- Ce que j’ai écarté
- Une réécriture web ou Electron ne supprimerait pas les privilèges desktop nécessaires et élargirait la surface du runtime.
- Ce que cela a coûté
- Nous acceptons la distribution Java, les permissions propres au système et une interface moins proche des conventions web.
Une connexion directe sur un LAN de confiance.
- Pourquoi
- Elle est proportionnée à une session entre un hôte présent et un seul assistant, sans infrastructure centrale.
- Ce que j’ai écarté
- Relais et comptes permettraient Internet et la traversée NAT, mais introduiraient secrets centraux, abus, identités et exploitation d’un service.
- Ce que cela a coûté
- Nous acceptons que les appareils partagent un réseau de confiance ou un chemin privé préparé.
Un TLS éphémère avec pin et jeton à usage unique.
- Pourquoi
- L’invitation authentifie l’endpoint exact de cette session sans créer d’identité persistante ni de base de comptes.
- Ce que j’ai écarté
- Mots de passe et identités durables exigeraient stockage, récupération, rotation et révocation hors du périmètre.
- Ce que cela a coûté
- Nous acceptons l’échange du lien hors bande, la comparaison du code et une nouvelle identité TLS à chaque démarrage de l’hôte.
Un protocole binaire étroit et borné.
- Pourquoi
- Il ne transporte que frames, heartbeats, état des permissions et entrées autorisées, avec types et tailles vérifiables.
- Ce que j’ai écarté
- Une stack généraliste comme RDP ou VNC offrirait l’interopérabilité. Pour respecter ce modèle de confiance, il faudrait toutefois limiter ou désactiver des fonctions plus larges comme le presse-papiers, le transfert de fichiers et l’accès sans surveillance.
- Ce que cela a coûté
- Nous acceptons moins de fonctions, aucune compatibilité universelle et la maintenance directe du codec et des tests.
Les décisions qui ont changé le produit.
Chaque décision retire un privilège implicite du prototype d’origine.
Approuver une personne visible
Avant d’entrer, le viewer attend pendant que l’hôte voit le nom déclaré, l’adresse et le code de vérification, puis décide localement s’il accepte cette personne.
Le compromisL’hôte doit être présent et reconnaître le demandeur ; l’entrée ne peut devenir ni automatique ni invisible.
Autoriser séparément consultation et contrôle
L’approbation ouvre uniquement un flux en consultation seule. Le contrôle de la souris et du clavier exige ensuite une autorisation explicite et révocable de l’hôte pour la session courante.
Le compromisL’assistant n’obtient pas immédiatement le contrôle et l’hôte doit le lui accorder délibérément ; le moindre privilège reste ainsi visible.
Nettoyer déterministiquement l’état des entrées
Révocation, perte de focus, déconnexion et arrêt libèrent toutes les touches et tous les boutons distants suivis, afin qu’aucun état incomplet ne survive à la session.
Le compromisLe cycle de vie doit gérer plusieurs parcours de nettoyage et tester chaque sortie, mais évite des entrées bloquées ou encore actives après la perte de permission.
Du code scolaire à une version vérifiable.
Le projet Java 21 utilise Maven Wrapper, des tests d’intégration JUnit, JaCoCo et Spotless. L’application shaded est exercée par sa CLI, et le dépôt documente architecture, confidentialité, hypothèses de menace, signalement de sécurité et attentes de contribution.
La CI vérifie les parcours Linux et Windows, CodeQL exécute une analyse statique planifiée et les jobs de publication créent des app images jpackage pour Windows, macOS et Linux avec sommes de contrôle, inventaire CycloneDX et attestations de provenance. Le projet précise que les paquets communautaires ne sont pas encore signés par les plateformes.
Ce qu’est JDoor Assist aujourd’hui.
JDoor Assist est une application de bureau fonctionnelle avec parcours launcher, hôte et viewer ; lien temporaire à usage unique ; épinglage du certificat ; approbation locale ; streaming en consultation seule ; autorisation explicite du contrôle ; nettoyage des entrées ; audit du cycle de vie et commandes visibles de déconnexion.
Le prototype de 2022 reste attribué comme un travail co-créé avec un collaborateur. La modernisation ultérieure de la sécurité, du produit, de l’UX, des tests et de la publication est la contribution de Djenis, et son résultat reste volontairement limité à une assistance visible entre personnes autorisées sur un réseau local de confiance.
Registre des preuves.
Le dépôt v1.0.0 rend ces contrôles et limites vérifiables :
- Sécurité de session
- L’hôte crée un certificat P-256 éphémère, partage son pin SHA-256 exact avec un jeton aléatoire à usage unique de 128 bits et exige une approbation locale visible avant qu’un viewer n’entre dans la session.
- Frontière du protocole
- Un protocole binaire versionné valide direction, type, dimensions, UTF-8 et taille de charge. Un seul viewer est admis, les images sont bornées et les entrées distantes sont ignorées tant que l’hôte n’active pas le contrôle.
- Gate de vérification
- Le gate Maven Wrapper exécute la suite JUnit, les seuils JaCoCo et les contrôles Spotless, puis produit un JAR exécutable avec dépendances et une SBOM CycloneDX. L’intégration couvre jeton invalide, démarrage en consultation seule, streaming, permissions et libération des entrées.
- Limite
- JDoor Assist fonctionne directement en LAN sur l’écran principal. Il ne fournit ni relais, ni comptes, ni traversée NAT, ni transfert de fichiers, ni accès sans surveillance ; les app images communautaires documentées ne sont pas encore signées.
Instantané du commit vérifié v1.0.0 Vérification du
Cette étude couvre l’instantané source v1.0.0 vérifié et son comportement LAN direct documenté. JDoor Assist est réservé à une assistance autorisée et visible ; ce n’est ni un relais Internet, ni un outil d’administration sans surveillance, ni une certification indépendante de sécurité. Il ne promet pas traversée NAT, capture multi-écran, signature de plateforme ou protection après compromission d’un terminal.