Trusted devices live only in this browser’s IndexedDB. The key is stored as a non-exportable Web Crypto key, not as a cookie or account credential.
Remember trust.
Not activity.
This advanced SEND surface manages saved browser trust for repeat device work. First trust uses ephemeral ECDH P-256 plus a six-digit human verification code. Reconnect uses rotating rendezvous and mutual proof before any queued SEND action or pathname-only continuity offer can proceed.
This label is shared only with the peer during the first explicit trust ceremony. It is not registered as an account or cloud device.
Trust once. Verify together.
Use QR/code signaling to establish WebRTC, then compare a six-digit SAS generated from an ephemeral ECDH exchange before either browser stores trust.
Both browsers derive the same ECDH secret and six-digit SAS. A signaling intermediary that substitutes peers produces different codes.
Availability starts only when you explicitly make a device available or connect. It uses an HMAC of the saved trust key and a short time bucket; there is no background presence.
Both peers exchange fresh nonces and verify mutual HMAC proof inside WebRTC before Device Hub can service a queued SEND action or continuity route. Route handoff is canonical-path only and drops query/hash data before transmission.
Trust is subordinate.
Payloads stay specialized.
Trusted Devices does not become a transport and does not merge trust protocol with payload protocols. It only recognizes a saved browser relationship, proves that relationship again, then launches the existing bounded BEAM, LINK, CLIP, TRAY or CONTINUE workflow—or offers a known 2XBR pathname. The receiving browser still explicitly opens or continues.