RemoteViewer

Sessione remota

• Coda di frame limitata tra cattura ed encoder: vince sempre il frame più recente, con keyframe su richiesta e watchdog per recuperare lo stream.
• Puntatore corretto anche quando WebRTC ridimensiona il video: le coordinate vengono rimappate sulla cattura originale e sul monitor scelto.
• Tastiera tra piattaforme: testo come Unicode e tasti virtuali per le scorciatoie, layout risolti con XKB su Linux (verificati US, IT, DE, FR).
• Policy di accettazione per dispositivo: automatica, rifiutata o con conferma, password o TOTP; connessioni ad hoc per RemoteViewer ID con rate limit e backoff.
• Connessione diretta via IP su LAN, senza passare dal control plane per il signaling.
• Client a schede con finestre staccabili, command palette e barra degli strumenti personalizzabile, sincronizzata sull’account.

Identità e sicurezza

• JWT con refresh token; nel browser cookie HttpOnly, protezione CSRF, header di sicurezza, rate limiting e lockout.
• 2FA via TOTP o email, codici di recupero e di backup; login social (Google, Microsoft, GitHub), SSO OIDC/SAML con JIT e provisioning SCIM 2.0.
• CA Ed25519 per RV-E2E con firma via Vault Transit in produzione, rotazione a caldo delle chiavi e rinnovo proattivo dei certificati.
• Credenziali macchina protette (DPAPI su Windows, store AES-GCM con rilevamento delle manomissioni su Linux) e rotazione di tutti i token con compare-and-swap.
• Host bloccato finché non è registrato in un’organizzazione, con flussi di approvazione dei dispositivi.

Permessi e policy

• Due livelli separati: i permessi di sistema governano dashboard e API, le capability di sessione cosa si può fare su un host.
• Ruoli owner, admin, viewer e personalizzati; il middleware ricarica l’utente a ogni richiesta, così un JWT vecchio o falsificato non concede permessi.
• Policy a livelli (organizzazione, utente, gruppo, dispositivo, policy locale dell’host) con editor a tre stati: eredita, consenti, nega.
• Il grant è l’intersezione con le capability dichiarate dall’host ed è fail-closed: un ID sconosciuto o un grant vuoto bloccano la sessione.
• L’host verifica ogni messaggio contro il grant e ricontrolla prima degli effetti collaterali; il client mostra un CapabilityDenied strutturato.

Host Windows

• Servizio Windows con watchdog, helper SYSTEM per il desktop sicuro e helper UAC per le operazioni amministrative.
• Gestione locale tramite le named pipe autenticate HostControl v1 e ServiceControl v1, con correlation ID e autorizzazione per comando.
• Il video resta attivo durante i passaggi al desktop sicuro: la duplicazione normale si sospende mentre Winlogon controlla l’input.
• Pagina Driver nelle impostazioni: stato desiderato e reale, riavvio richiesto, installazione, riparazione e diagnostica gestite dal servizio.
• Tema chiaro/scuro coerente anche quando host e client girano come SYSTEM, leggendo la preferenza dell’utente collegato.

Host Linux

• hostd gira come utente di sistema remoteviewer, senza login e con un sandbox systemd rigoroso; possiede identità, token e signaling.
• Un agente per sessione utente, senza capability e con NoNewPrivileges, gestisce cattura, input e media; agenti dedicati per headless e greeter GDM.
• IPC RVAG/RVLC su socket SOCK_SEQPACKET con credenziali del kernel, legame alla sessione logind e protezione dal replay.
• Operazioni privilegiate solo tramite Polkit e un servizio root attivato via socket che accetta operazioni systemd/logind tipizzate.
• Strumenti nativi: processi da /proc, unità systemd, pacchetti APT/Snap/Flatpak, aggiornamenti autenticati, terminali PTY.

Strumenti remoti

Gli strumenti “Ghost” girano sull’host e si usano dal client senza disturbare l’utente remoto.

• Task manager con processi, prestazioni e GPU; terminazione, priorità, affinità e dump.
• Esplora file a doppio pannello con copia, spostamento, conflitti Chiedi/Salta/Sovrascrivi, cestino e proprietà.
• Terminale con scelta della shell, completamento dei percorsi ed esecuzione come utente corrente, elevato o con credenziali.
• Servizi, programmi all’avvio, programmi installati, Windows Features, Windows Update e sessioni utente.
• Comandi di sistema: blocco, logout, riavvio, spegnimento e popup di stampa remota.

Amministrazione e operazioni

• Dashboard Angular per tenant e admin: dispositivi, gruppi, utenti, sessioni, audit, crash report, diagnostica di rete, aggiornamenti e CA.
• Console di piattaforma separata per gli operatori: realm di autenticazione distinto, allowlist CIDR, TOTP obbligatorio, step-up, doppia approvazione e audit a catena verificabile.
• Crash reporting con minidump opzionali e retention, support bundle con filtro privacy che rimuove token, chiavi e password.
• Endpoint /health e /ready strutturati, metriche Prometheus su latenze HTTP/gRPC, CA, Redis e crash, con regole di alert.

Rilasci e aggiornamenti

• Due setup Windows autosufficienti dalla stessa build, con payload in allowlist e protezione dal downgrade di edizione.
• Aggiornamenti delta verificati da catalogo e manifest firmati Ed25519; canali, rollout graduale, pinning e rollback dalla dashboard.
• Pacchetti per Jammy, Noble e Resolute costruiti in Docker e pubblicati con swap atomico in un repository APT firmato servito dal control plane.
• Aggiornamenti consapevoli della piattaforma: Linux riceve solo rilasci APT, Windows solo setup Windows.

Qualità e test

• Test GTest/CTest per host, client e librerie condivise (oltre 1.200 casi sulla build Linux), test Go con race detector.
• CI su Windows e Ubuntu 22.04/24.04/26.04 con E2E full-stack su Linux, actionlint e check obbligatori.
• Controllo dei confini di piattaforma: nessuna API Windows fuori dalle zone autorizzate e nessun import vietato nei binari Linux.
• Framework di qualificazione per la GA con matrici di esecuzione, protocollo statistico BCa ed evidenze sigillate e firmate.

Stato e prossimi passi

Le funzioni sono implementate; alcune aree hanno ancora gate di qualificazione aperti.

• Client Linux: GA in attesa delle evidenze sigillate sulla matrice GPU Intel/AMD/NVIDIA e dei test di fault Wayland.
• Host Windows senza driver: qualificazione su VM pulite con Secure Boot attivo.
• Trasferimenti QUIC: matrice di validazione in produzione (ripresa, checksum, cartelle grandi, reti instabili).
• Firma Authenticode dei setup; il driver audio virtuale richiede ancora il test-signing. macOS è un’espansione futura.