Security

How your data is protected, in plain words

Pairing starts with a QR code on your PC. It carries a one-time secret that expires after two minutes, so only a device that actually saw your screen can pair. Both screens then show the same 6-digit code, and you confirm that they match.

• Every connection is encrypted end to end with the Noise protocol (X25519, ChaCha20-Poly1305, BLAKE2s). Each device has its own key that never leaves it, and devices recognise each other by that key — not by IP address, name or account.
• Every connection and every data stream uses fresh keys (forward secrecy): a key stolen later cannot decrypt traffic recorded earlier.
• Encryption sits above the network, so it protects you the same way on Wi-Fi, over the internet (QUIC, TCP or WebRTC) and through our rendezvous service, which only relays sealed messages it cannot read.
• Being paired does not mean being allowed everything: each device gets only the permissions you grant, and remote input and camera access ask for your consent every session.
• Files, links and clipboard data you receive are checked before use: they cannot escape the download folder, dangerous link types are refused and sizes are bounded.

The full technical specification and the threat model are in our security documentation, which we share with researchers and auditors.

Audit status

We would rather be precise than impressive:

• Internal security review: done. The design, pairing, session encryption, permissions and input validation were reviewed against a written threat model, and the security rules are covered by automated tests that run on every change.
• Automated checks: dependency advisories and licences are checked on every change, and the parts that read untrusted input are fuzzed every week.
• External audit: planned before version 1.0 and not yet done. When it is complete we will publish the auditor, the scope and a summary of the findings here.

Until then Personal Device Bridge is a preview. Please keep that in mind before relying on it for highly sensitive data.

Verify what you download

You should not have to take our word that a download is genuine:

• Checksums: every release includes a SHA256SUMS file covering all of its files, so you can confirm that your copy is exactly what we published.
• Reproducible builds: the Linux command-line tool is built deterministically. Anyone with the source code at the release tag can rebuild it and get a bit-for-bit identical file, and an automated check builds it twice in different environments and fails if even one byte differs.
• Build provenance: our release workflow is set up to attach a signed SLSA provenance attestation (Sigstore) to every file, recording which workflow and which commit produced it; you can check it with the “gh attestation verify” command. GitHub enables this once the source repository is public, and we will announce it here when it is live.
• Code signing: our release pipeline signs Windows programs and installers with Authenticode (Azure Artifact Signing); you can check the publisher under Properties → Digital Signatures before running a file.

Windows and Android builds are not reproducible yet; that work is planned. Step-by-step verification instructions for bash and PowerShell are in our reproducible-builds guide, available on request.

Continuous testing

Every decoder that reads data from another device or from the network — message envelopes, pairing links, discovery beacons, file names and feature messages — is fuzzed weekly with libFuzzer, which feeds it millions of malformed inputs to find crashes and broken safety checks.

On top of that, unit, integration and end-to-end tests run on Windows and Linux for every change, including two real processes pairing and transferring files over the network.

How to report

E-mail projectteamforyou@gmail.com with the subject “[SECURITY] short title”, in Korean or English. Please include:

• the affected app or component and its version;
• what the problem is and what an attacker could do with it (a CVSS vector is welcome);
• step-by-step reproduction or a proof of concept, and the platform you tested on.

Please do not report vulnerabilities through public issues or social media.

Encryption: we have not published a PGP key yet. When we do, it will be placed in the /.well-known/ folder of this website and listed in personaldevicebridge.com/.well-known/security.txt. Until then, if your report contains sensitive exploit details, send a short first message without them and we will agree a secure channel with you.

Our source code is proprietary. If you need access to it to research or confirm a finding, ask us; we review each request individually.

What happens after you report

• We acknowledge your report within 72 hours.
• We triage it — validity, severity and affected versions — within 7 days, and update you at least every 14 days until it is resolved.
• Fix targets from triage: Critical within 30 days (with a mitigation within 7 days where possible), High within 60 days, Medium within 90 days, Low in a later scheduled release.

We are a small team. If we cannot meet a target, we will tell you why and when to expect the fix.

Contact details for tools

Our contact details are also published in the standard machine-readable form (RFC 9116) at personaldevicebridge.com/.well-known/security.txt, which points to this page. We answer in Korean or English.