JDoor Remote assistance Source opens in a new tab
Open-source desktop project Source 1.0.0

The person at the screen stays in charge.

JDoor is remote assistance for trusted local networks. A short-lived invitation reaches the named host; the person at that screen approves locally, starts view-only and can stop the session at any time.

See one session Read the source opens in a new tab
The real interface Source 1.0.0 / Windows 11

Consent is the main interaction, not a promise in the margins.

These are actual desktop surfaces from the 1.0.0 codebase. The launcher separates the two roles before a connection begins; the shared computer names the viewer, shows the matching code and asks locally before revealing the screen.

JDoor Assist 1.0.0 launcher on Windows with separate Share this screen and Join a session actions.
01 / Launcher

Two roles, one visible boundary before anything connects.

JDoor local approval dialog showing a Trusted helper request, a matching verification code and text that approval does not enable control.
02 / Local approval

The endpoint is redacted here; the matching code and permission boundary remain visible.

A session

One session, from invitation to screen sharing.

The application checks the route and constrains the protocol. Both people compare the same code; the host makes the final decision.

01
Host / prepare

Create a short-lived invitation

The host creates a fresh P-256 certificate, its exact SHA-256 fingerprint and a random 128-bit token that expires after 10 minutes.

02
People / share

Send the complete link privately

The host sends the one-time jdoor:// link to the intended helper through a separate, trusted channel.

03
Client / check

Check the destination

The helper’s application checks the advertised host and exact certificate fingerprint before presenting the single-use token inside TLS 1.2/1.3.

04
People / decide

Compare the code and approve

Both computers show the same verification code. The host reviews the request and approves it on the machine being shared.

05
Session / view

Show the screen without control

Primary-display frames begin only after approval. Remote input stays disabled unless the host enables it for that session.

The project

It began by connecting two computers. The rebuild changed the question.

Two student collaborators created JDoor as a school experiment in networking and remote control. The first version proved the connection could work. Years later, one maintainer rebuilt it around a narrower and more useful premise: the person sharing the machine should remain visibly present in every decision.

Then / prove the connection
An unauthenticated remote-access prototype focused on moving screen and input data between two machines.
Now / define the boundary
A short-lived invitation, an exact endpoint check, local approval and permission that belongs only to the current session.

The modernization covers product direction, security, UX, testing and release engineering while preserving the project’s shared origin.

Design decisions Choice / alternative / accepted cost

The product stays small because its choices are narrow.

JDoor is not a reduced version of a remote-management suite. Its architecture follows one situation: two people, one approved support session and a trusted local network. Each omission protects that boundary, while introducing a cost we accept explicitly.

01 / Desktop runtime

Java 21 + Swing

One desktop process owns the interface, screen capture, transport and input policy. Java provides mature TLS and concurrency while Swing keeps the approval surface independent of a browser runtime.

Instead of
A browser product or Electron shell plus a privileged native bridge
Accepted cost
Packaging, signing and operating-system permissions still need platform-specific work
02 / Network shape

Direct trusted-LAN connection

A direct route avoids creating a relay, account database or permanent control plane for an occasional support session. The network boundary remains visible to both people.

Instead of
A public relay with accounts, device enrolment and centralized trust
Accepted cost
No NAT traversal and no support session across unrelated networks
03 / Session identity

Ephemeral TLS + exact pin

Every host run creates a fresh P-256 identity. The invitation binds the advertised host, exact certificate fingerprint and one-time token; the matching code gives both people something human-readable to compare.

Instead of
Persistent product accounts or a long-lived private certificate authority
Accepted cost
The complete link needs a trusted channel, and the pin identifies the endpoint—not the person
04 / Capability surface

Bounded protocol, view first

Screen frames and optional input use an explicit, size-limited protocol. Viewing and control are separate permissions, so approval never silently grants the more powerful capability.

Instead of
A general-purpose RDP, VNC or remote-administration feature set
Accepted cost
No file transfer, clipboard, audio, multi-display or unattended access
Trust & privacy

The software checks the endpoint. The host decides the person.

Connection evidence narrows a request to the endpoint named in that invitation for the current host run. Trust in the person—and every permission that follows—remains a local decision.

Software checks

Connection evidence

Endpoint
Exact SHA-256 certificate pin for the advertised host
Invitation
Random 128-bit token, single-use and short-lived
Protocol
TLS 1.2/1.3 plus explicit type, size and range bounds
The host decides

Human permission

Person
Whether the helper behind the checked endpoint is expected
Capability
Whether to remain view-only or enable mouse and keyboard input
End
When to revoke control or stop the session immediately
Local audit / not a recording

JDoor has no telemetry, analytics, crash upload, account service or public relay. It keeps a bounded local trail of security events—not a copy of the screen or what was typed.

Local trail
Time, event type, remote address and a short lifecycle description.
Never content
No tokens, private keys, screen pixels, typed content or raw input events.
Retention
Daily JSONL, capped at 5 MiB and retained by the app for 30 days.
Limits

Useful when both people are present. Wrong when they are not.

JDoor fits a family member, classroom, lab or small office where the helper and host can coordinate on the same trusted network. If the job needs background administration or an Internet service, choose a product designed for that job.

A good fit

Short support with the owner present

  • Helping family on the same trusted home network
  • Guiding a student at a classroom or lab workstation
  • Troubleshooting with a colleague in a small office
  • One approved viewer and optional, revocable input
  • A short local audit trail of the session lifecycle
Choose something else

Persistent or Internet-scale administration

  • Support across the Internet or through NAT
  • Unattended access, persistence or fleet management
  • Remote shell, privilege escalation or background policy
  • File, clipboard, webcam or microphone transfer
  • Public relay, accounts or centralized device enrolment

Network boundary. Use JDoor only on a trusted LAN, share the complete pairing link through a separate trusted channel and do not expose port 8443 directly to the internet.

Residual risk. An approved helper can see the shared display and, while the host enables control, act through the host’s existing user session.

Current status
Source 1.0.0

The code is versioned. Distribution is still manual.

The repository identifies the current source as 1.0.0 and publishes its architecture, threat model, privacy documentation and tests. There is no signed installer or tagged GitHub release yet, so begin with the threat model and build locally. Community builds may trigger an unverified-publisher warning.

Inspect the repository opens in a new tab Build it locally opens in a new tab Read the case study