Security

Bisha Remote is designed around explicit consent, cryptographic device identity, and least privilege. This page summarizes the user-facing model — not a full protocol specification.

Device identity

Each installation maintains a cryptographic device identity. The numeric Device ID is a shareable locator, not a password and not proof of authorization by itself.

Connection approval

Interactive sessions require explicit approval on the remote side. Capabilities (screen, input, clipboard, files) are granted as scoped permissions for that session.

Encrypted peer communication

Peer media and control traffic are designed to travel on an encrypted peer path. Connections prefer direct connectivity first.

Relay fallback

When a direct path is unavailable, a relay may forward traffic. The relay is intended to forward encrypted peer payloads — it is not a place where session content is meant to be inspected in cleartext.

Unattended access

Unattended access is opt-in. A trusted device must be configured explicitly. Closing the UI does not silently open your PC to the internet.

File transfer

File transfer requires capability grants. Received files are never automatically executed by Bisha Remote.

Updates

The production update path verifies signed update metadata and, when production Authenticode is available, requires Valid signatures on installers before apply. Development/private-beta builds may be unsigned and must not be presented as production-signed.

Canonical production manifest URL (when live): https://releases.bisharemote.com/stable/update-manifest.v1.json. Live status: not live.

Windows service separation

Privileged Windows service components are separated from the user interface process. Elevation is used only where Windows requires it for install/update or privileged session features.

What Bisha Remote does NOT do

• Treat Device ID alone as authentication
• Enable unattended access by default
• Automatically execute received files
• Claim “military-grade”, “unhackable”, or zero-knowledge marketing language
• Weaken production updater trust checks to ship an unsigned public release

Security contact

Intended address: security@bisharemote.com.

Mailbox routing is not confirmed as operational yet. Treat this as a deployment TODO until DNS/mail is configured — do not assume active triage SLAs.