Preserve the origin, change the trust model.
The original JDoor was a 2022 school project that Djenis built with a collaborator. It demonstrated Java networking, screen capture and remote input. That shared origin remains part of the project record; the later work does not recast the classroom prototype as a solo project.
A demonstration is not yet a support product. The old design treated an incoming connection as a control channel, without a strong authenticated pairing ceremony, a view-only state or a complete lifecycle for stuck keys, socket failures and shutdown. The modernization therefore began by narrowing what the application is allowed to do.
Rules for authorized assistance.
The rebuilt product follows four non-negotiable constraints:
- Every session is for authorized support initiated by both people: the host stays visible, approves each viewer locally and never exposes unattended or background access.
- The network path may be observed or modified, so the viewer must authenticate the exact ephemeral certificate and present the short-lived one-time token received out of band.
- Screen viewing and remote control are separate permissions; control starts off, the host can revoke it immediately, and revocation or disconnect releases tracked keys and mouse buttons.
- Protocol input is untrusted: messages, images, timeouts, workers and cleanup need explicit bounds, directional rules and deterministic closure.
Remote assistance, not remote administration.
The central decision was not how to hide or extend the original control path. It was to replace that path with a product boundary that makes consent visible and removes persistence, shell execution and unattended access from the design.
For the modernization, Djenis separated TLS identity and pairing, the framed protocol, session state, screen capture, input policy, audit events and Swing presentation. That structure makes authentication, approval, viewing and control distinct states instead of side effects of opening a socket.
A session built around explicit consent.
The host UI creates an ephemeral identity and one-time link. The viewer pins that certificate, presents the token and waits for local approval. Only then does the bounded channel carry screen frames; pointer and keyboard messages are applied only while the active host session owns an explicit control grant.
Why the assistance surface stays narrow.
The implementation preserves the project’s Java origin while removing infrastructure and privileges that visible LAN assistance does not need.
Java 21 and Swing remain the desktop application stack.
- Why
- The project already centres on Java networking, screen capture and input, and Swing can place host approval, view-only state and disconnect controls in the same native runtime.
- What I ruled out
- A web interface cannot perform the required raw LAN, capture and input work by itself; an Electron rewrite would add a browser-to-native bridge and discard the project’s existing implementation path.
- What it cost
- The product accepts Swing-specific UX work, platform integration differences and Java application packaging instead of inheriting a web UI ecosystem.
The viewer connects directly over the trusted LAN.
- Why
- Direct connectivity keeps screen data and session decisions between the two endpoints and avoids a central service that stores accounts or relays an authority-bearing session.
- What I ruled out
- A relay and account backend would make internet and NAT traversal easier, but it would add persistent identities, hosted infrastructure and a much larger operational and security boundary.
- What it cost
- Both people must arrange network reachability, JDoor does not cross NAT automatically and exposing its port beyond the trusted LAN is outside the supported model.
Every run uses ephemeral pinned TLS and a single-use token.
- Why
- The complete invitation binds the viewer to the exact temporary certificate and one short-lived session, while local approval confirms the person before viewing begins.
- What I ruled out
- A reusable password or long-lived account identity would reduce repeated pairing, but compromise and recovery would persist beyond one support session and require an identity service.
- What it cost
- The invitation must be shared privately, both parties pair again for each host run and there is no account-based recovery when the link expires.
A narrow framed protocol carries only the approved session features.
- Why
- Direction, message type, dimensions and payload size can be validated, and viewing remains distinct from the host’s revocable input grant.
- What I ruled out
- A general-purpose RDP or VNC stack would require constraining or disabling broader facilities such as clipboard, file transfer and unattended access because they contradict this product’s consent-first boundary.
- What it cost
- JDoor supports fewer capabilities, one approved viewer and the primary display, and every future protocol feature must preserve the explicit state machine and bounds.
Decisions that changed the product.
Each decision removes an implicit privilege from the original prototype.
Make approval legible to the host
Before any stream begins, the local dialog identifies the viewer by name and network address, pairs that identity with a verification code and asks the host to approve that person explicitly.
The trade-offPossessing the invitation is not enough and the host must be present; that extra step turns access into a visible human decision.
Separate viewing from control
Approval starts a view-only stream. A host toggle grants input only for the current session and keeps the permission visible while it is active.
The trade-offThis adds a second permission step, but viewing no longer implies authority to act.
Release remote input on every exit path
Revocation, focus loss, disconnect and shutdown each trigger deterministic cleanup that releases held keys and buttons before control ends.
The trade-offThe lifecycle needs explicit cleanup branches and tests, but an ended session cannot leave remote input logically pressed.
From classroom code to a reviewable release.
The Java 21 project uses Maven Wrapper, JUnit integration tests, JaCoCo and Spotless. The shaded application is exercised through its CLI, and the repository documents architecture, privacy, threat assumptions, security reporting and contributor expectations alongside the code.
CI verifies Linux and Windows paths, CodeQL performs scheduled static analysis, and release jobs create jpackage app images for Windows, macOS and Linux with checksums, a CycloneDX inventory and provenance attestations. The project states clearly that community packages are not yet platform-signed.
What JDoor Assist is now.
JDoor Assist is a working desktop application with launcher, host and viewer flows; an expiring one-time link; certificate pinning; local approval; view-only streaming; an explicit control grant; input cleanup; lifecycle audit records and visible disconnect controls.
The 2022 prototype remains credited as work co-created with a collaborator. The later safety, product, UX, testing and release modernization is Djenis’s contribution, and its result is intentionally limited to visible assistance between authorized people on a trusted local network.
Evidence ledger.
The v1.0.0 repository makes these controls and limitations inspectable:
- Session security
- The host creates an ephemeral P-256 certificate, shares its exact SHA-256 pin with a random 128-bit single-use token, and requires a visible local approval before a viewer enters the session.
- Protocol boundary
- A versioned binary protocol validates direction, type, dimensions, UTF-8 and payload size. One viewer is admitted at a time, screen frames are bounded, and remote input is ignored until the host enables control.
- Verification gate
- The Maven Wrapper gate runs the JUnit suite, JaCoCo thresholds and Spotless checks, then builds a runnable shaded JAR and CycloneDX SBOM. Integration coverage exercises invalid-token rejection, view-only startup, streaming, permission changes and input release.
- Boundary
- JDoor Assist is direct LAN software for the primary display. It provides no relay, account service, NAT traversal, file transfer or unattended access, and the documented community app images are currently unsigned.
Verified commit snapshot v1.0.0 Verified on
This case study covers the checked v1.0.0 source snapshot and its documented direct-LAN behaviour. JDoor Assist is only for authorized, visible support; it is not an internet relay, unattended administration tool or claim of independent security certification. It does not promise NAT traversal, multi-display capture, platform signing or protection after either endpoint is compromised.