Security & Bug Bounty

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.

What is in scope

Please report anything that could harm our users' security or privacy in:

• The core engine: device identity and key storage, QR pairing, encrypted sessions, the wire protocol, transports (QUIC, TCP, WebRTC), discovery, trust and permissions, and every feature (file transfer, clipboard, links, Continue, MyDrop, SmartPrint, file browser, notifications, remote input, camera).
• The apps: the pdb command-line tool, the Windows desktop app and its installers, and the Android app.
• The rendezvous service we operate for connections over the internet.
• This website, personaldevicebridge.com.
• Our release process: build and release workflows, code signing, checksums and provenance.

We are especially interested in: pairing without seeing the QR code, breaking encryption or device authentication, a paired device doing more than it was allowed to, reading or writing files outside the intended folder, running code through received data, and the rendezvous service learning or changing message contents.

What is out of scope

• Denial of service by sheer traffic volume, load testing of our hosted services, and spam.
• Social engineering or phishing of our team or users, and physical attacks.
• Attacks that need a device or user account that is already compromised (for example malware running as the user), a rooted or jailbroken phone, or physical access to an unlocked device.
• Information that is visible on the local network by design, such as the presence of a device or the volume of traffic.
• Limitations already documented in our security documentation, unless you show a worse impact.
• Bugs in third-party platforms themselves (Cloudflare, Railway, GitHub, Google) — please report those to the vendor. How we use them is in scope.
• Reports without a demonstrated security impact: missing headers on static pages, e-mail SPF/DMARC settings, self-XSS, version numbers, or scanner output without a proof of concept.

How to report

E-mail [email protected] 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;
• whether and how you would like to be credited.

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.

Rewards

Rewards are discretionary. They depend on impact, report quality and whether the issue is new to us, and the first person to report an issue is eligible. We rate severity with CVSS (v3.1 or v4.0) against the latest release and explain our rating to you.

Duplicates, out-of-scope issues and reports that break this policy are not rewarded. Several issues chained together count as one finding at the resulting severity.

Rewards are paid in Korean won; dollar amounts are approximate. Payment requires the details that Korean tax law and our bank need, and cannot be made where the law or sanctions forbid it. You may also ask us to donate your reward to a charity.

Safe harbour

If you make a good-faith effort to follow this policy, we consider your research authorised. We will not take or support legal action against you and will not report you to law enforcement for it. If someone else takes action against you for research that followed this policy, we will make it known that you had our authorisation.

Acting in good faith means that you:

• test only your own devices, installations, pairings and rendezvous mailboxes;
• do not access, change or keep other people's data — if you come across it, stop, tell us and delete it;
• do not disrupt our services or leave lasting changes behind;
• give us time to fix the issue before disclosing it;
• never ask for payment in exchange for not disclosing.

We cannot authorise testing of systems we do not own. If in doubt, ask us first.

Coordinated disclosure

Please give us 90 days from your report — or until a fix is released, if that is sooner — before you publish details. For a complex fix we may ask for a short extension and will agree the date with you.

After the fix we publish an advisory in the release notes and credit you, unless you prefer to stay anonymous. If an issue is being actively exploited, we may disclose it earlier, together with you.

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.

Hall of fame

Thank you to everyone who helps keep our users safe. Researchers who report valid issues are listed here, with their permission.

No reports have been credited yet — yours could be the first.