Identity
Device-held identity
Enrollment tokens are one-time and hash-only at rest. Device private keys are generated locally and are not sent to the server.
Verified foundationSecurity must be behavior
Authority should be narrow, visible, and easy to end.
NoBS Remote is being designed around explicit identity, bounded consent, immediate revocation, and evidence. The current work is a development foundation—not a security certification or customer-ready remote-access service.
Verified development foundationVerified foundations
Controls already exercised in the development system.
These statements describe bounded control-plane and Windows authority work. They do not imply an implemented screen or input path.
Requests
Replay-resistant device calls
Signed heartbeats bind the request method, path, body hash, time, request ID, and device. Reuse and signature failures are rejected and recorded with bounded metadata.
Verified foundationConsent
Bounded, revocable authority
Consent expires on an absolute server-defined boundary. Heartbeats, retries, and reconnects cannot extend it, and Stop or revoke ends the authority.
Verified foundationWindows boundary
Session-bound local prompt
The production-shaped development path binds the trusted SessionHost to one observed active Windows user session and fails closed when that binding is lost.
Verified foundationAudit
Useful events without secrets
Accepted transitions and bounded audit records commit together. Keys, tokens, arbitrary content, and raw Windows identity details do not belong in normal events.
Verified foundationScam resistance
Local understanding matters
The intended support prompt warns people to approve only expected help from someone they know and trust. Local Stop remains an authority control, not decoration.
Building nowCurrent boundary
No customer-ready connection exists.
NoBS Remote does not currently provide production network transport, screen capture, input injection, clipboard, file transfer, relay forwarding, hosted service, or supported self-host package.
“Consent approved” means only that a bounded authority record exists. It does not mean connected, streaming, or under remote control.
Required before launch
Security work still ahead
- Production identity, passkeys/MFA, account recovery, roles, and cross-tenant evidence.
- Authenticated endpoint-to-endpoint transport and content protection across direct and relay paths.
- Signed installers, updates, rollback, revocation, SBOM, and provenance.
- Operational monitoring, incident response, abuse handling, backup, and recovery drills.
- Independent transport/cryptographic review and penetration testing before commercial release.
Trust boundaries
What the product is intended never to centralize.
Endpoint private keys
The service and relay are not intended to receive endpoint private or content keys.
Plaintext session content
The control plane and relay are not intended to receive screen frames, input streams, file bodies, or other plaintext session content.
Silent consent
Attended support is intended to require explicit, understandable local consent with visible state and immediate Stop.
These are design and commercial-GA requirements. They become shipped claims only after the relevant transport, application, deployment, and independent-review gates pass.
See something concerning?
Report it carefully.
Start with a minimal, non-sensitive report so we can arrange an appropriate channel.