Conservare l’origine, cambiare il modello di fiducia.
JDoor originale era un progetto scolastico del 2022 che Djenis ha realizzato con un collaboratore. Dimostrava networking Java, cattura dello schermo e input remoto. Questa origine condivisa resta nella storia del progetto: il lavoro successivo non presenta il prototipo scolastico come opera individuale.
Una dimostrazione non è ancora un prodotto di assistenza. Il vecchio design trattava una connessione in ingresso come canale di controllo, senza pairing autenticato forte, stato view-only o ciclo completo per tasti bloccati, errori delle socket e arresto. La modernizzazione è quindi partita restringendo ciò che l’applicazione può fare.
Regole per l’assistenza autorizzata.
Il prodotto ricostruito segue quattro vincoli non negoziabili:
- Ogni sessione serve esclusivamente a un supporto autorizzato e avviato da entrambe le persone: l’host resta visibile, approva localmente ogni viewer e non espone mai accesso non presidiato o in background.
- Il percorso di rete può essere osservato o modificato, quindi il viewer deve autenticare il certificato effimero esatto e presentare il token monouso a breve scadenza ricevuto fuori banda.
- Visione dello schermo e controllo remoto sono permessi distinti; il controllo parte disabilitato, l’host può revocarlo subito e revoca o disconnessione rilasciano tasti e pulsanti tracciati.
- L’input di protocollo non è fidato: messaggi, immagini, timeout, worker e cleanup richiedono limiti espliciti, regole direzionali e chiusura deterministica.
Assistenza remota, non amministrazione remota.
La scelta centrale non era nascondere o ampliare il vecchio percorso di controllo. Era sostituirlo con un confine di prodotto che rende il consenso visibile ed elimina dal design persistenza, esecuzione di shell e accesso non presidiato.
Per la modernizzazione, Djenis ha separato identità TLS e pairing, protocollo framed, stato di sessione, cattura, policy di input, audit e presentazione Swing. Autenticazione, approvazione, visione e controllo diventano stati distinti, non effetti collaterali dell’apertura di una socket.
Una sessione costruita attorno al consenso esplicito.
L’interfaccia host crea un’identità effimera e un link monouso. Il viewer fissa quel certificato, presenta il token e attende l’approvazione locale. Solo dopo il canale limitato trasporta i frame; mouse e tastiera vengono applicati soltanto mentre la sessione host attiva possiede un permesso di controllo esplicito.
Perché queste tecnologie.
Ogni scelta restringe JDoor all’assistenza temporanea e visibile prevista dal suo modello di fiducia.
Java e Swing per l’app desktop.
- Perché
- Conservano il codebase e usano direttamente AWT per cattura, input e interfacce native su Java 21.
- Cosa ho escluso
- Una riscrittura web o Electron non eliminerebbe il bisogno di privilegi desktop e allargherebbe la superficie del runtime.
- Quanto è costata
- Accettiamo distribuzione Java, permessi specifici del sistema operativo e un’interfaccia meno vicina alle convenzioni web.
Connessione diretta su LAN fidata.
- Perché
- È proporzionata a una sessione tra un host presente e un solo helper senza infrastruttura centrale.
- Cosa ho escluso
- Relay e account abiliterebbero Internet e NAT traversal, ma introdurrebbero segreti centrali, abuso, identità e operazioni di servizio.
- Quanto è costata
- Accettiamo che i dispositivi debbano condividere una rete fidata o un percorso privato predisposto.
TLS effimero con pin e token monouso.
- Perché
- L’invito autentica l’endpoint esatto per quella sessione senza creare un’identità persistente o un database di account.
- Cosa ho escluso
- Password e identità durature richiederebbero storage, recupero, rotazione e revoca oltre il perimetro del progetto.
- Quanto è costata
- Accettiamo lo scambio out-of-band del link, il confronto del codice e una nuova identità TLS a ogni avvio host.
Un protocollo binario stretto e limitato.
- Perché
- Trasporta soltanto frame, heartbeat, stato dei permessi e input autorizzato con tipi e dimensioni verificabili.
- Cosa ho escluso
- Uno stack general-purpose come RDP o VNC offrirebbe interoperabilità. Per rispettare questo modello di fiducia, però, dovremmo limitarne o disattivarne funzioni più ampie come clipboard, trasferimento file e accesso non presidiato.
- Quanto è costata
- Accettiamo meno funzioni, nessuna compatibilità universale e la manutenzione diretta di codec e test.
Le decisioni che hanno cambiato il prodotto.
Ogni scelta rimuove un privilegio implicito del prototipo originale.
Approvare una persona visibile
Prima di entrare, il viewer resta in attesa mentre l’host vede nome dichiarato, indirizzo e codice di verifica e decide localmente se accettare quella persona.
Il compromessoL’host deve essere presente e riconoscere il richiedente; l’ingresso non può diventare automatico o invisibile.
Separare visione e controllo
L’approvazione apre soltanto una sessione view-only. Il controllo di mouse e tastiera richiede un’autorizzazione successiva, esplicita e revocabile assegnata dall’host alla sessione corrente.
Il compromessoL’helper non ottiene subito il controllo e l’host deve concederlo deliberatamente; è il costo di mantenere visibile il minimo privilegio.
Azzerare deterministicamente lo stato dell’input
Revoca, perdita del focus, disconnessione e arresto rilasciano i tasti e i pulsanti remoti tracciati, così uno stato incompleto non sopravvive alla sessione.
Il compromessoIl ciclo di vita deve gestire più percorsi di cleanup e testare ogni uscita, ma evita input bloccati o ancora attivi dopo la perdita del permesso.
Dal codice scolastico a un rilascio verificabile.
Il progetto Java 21 usa Maven Wrapper, test di integrazione JUnit, JaCoCo e Spotless. L’applicazione shaded viene provata attraverso la CLI, mentre il repository documenta architettura, privacy, ipotesi di minaccia, segnalazione di sicurezza e regole per i contributi.
La CI verifica Linux e Windows, CodeQL esegue analisi statica pianificata e i job di rilascio creano app image jpackage per Windows, macOS e Linux con checksum, inventario CycloneDX e attestazioni di provenienza. Il progetto dichiara chiaramente che i pacchetti community non sono ancora firmati dalle piattaforme.
Cos’è oggi JDoor Assist.
JDoor Assist è un’applicazione desktop funzionante con flussi launcher, host e viewer; link monouso a scadenza; pin del certificato; approvazione locale; streaming view-only; permesso di controllo esplicito; cleanup dell’input; audit del ciclo di vita e comandi visibili di disconnessione.
Il prototipo del 2022 resta attribuito come lavoro co-creato con un collaboratore. La modernizzazione successiva di sicurezza, prodotto, UX, test e rilascio è il contributo di Djenis, e il risultato resta limitato all’assistenza visibile tra persone autorizzate su una rete locale fidata.
Registro delle evidenze.
Il repository v1.0.0 rende verificabili questi controlli e limiti:
- Sicurezza della sessione
- L’host crea un certificato P-256 effimero, condivide il suo pin SHA-256 esatto insieme a un token casuale monouso da 128 bit e richiede un’approvazione locale visibile prima dell’ingresso del viewer.
- Confine del protocollo
- Un protocollo binario versionato valida direzione, tipo, dimensioni, UTF-8 e grandezza dei payload. Entra un solo viewer alla volta, i frame sono limitati e l’input remoto viene ignorato finché l’host non abilita il controllo.
- Gate di verifica
- Il gate Maven Wrapper esegue la suite JUnit, le soglie JaCoCo e i controlli Spotless, poi produce un JAR eseguibile con dipendenze e una SBOM CycloneDX. L’integrazione copre token non valido, avvio view-only, streaming, permessi e rilascio dell’input.
- Limite
- JDoor Assist opera direttamente in LAN sul display primario. Non offre relay, account, attraversamento NAT, trasferimento file o accesso non presidiato; le app image community documentate non sono ancora firmate.
Snapshot del commit verificato v1.0.0 Verifica del
Questo case study descrive lo snapshot sorgente v1.0.0 verificato e il comportamento direct-LAN documentato. JDoor Assist è destinato soltanto a supporto autorizzato e visibile: non è un relay internet, uno strumento di amministrazione non presidiata né una certificazione di sicurezza indipendente. Non promette attraversamento NAT, cattura multi-display, firma delle piattaforme o protezione dopo la compromissione di uno dei due endpoint.