2xBRНАЗАД В SEND ↗
SEND / ДОВЕРЕННЫЕ УСТРОЙСТВА

Запомните устройство.
Не его активность.

Используйте доверенное устройство, когда вы регулярно работаете между одними и теми же браузерами и не хотите каждый раз проходить первое сопряжение. Сохранённое доверие всё равно повторно доказывается перед действием.

Управлять доверенными устройствами →
01 / WHENНужно повторно отправлять или продолжать работу между уже знакомыми браузерами.
02 / РЕЗУЛЬТАТЛокально сохранённая связь, которая ускоряет повторное подключение, но каждый раз проходит взаимное подтверждение.
03 / BOUNDARYНет облачного списка устройств, фонового presence, автоматической отправки или общего транспортного протокола.
Техническая модель доверия устройств
01СОПРЯЖЕНИЕECDH02СРАВНИТЬ6 DIGITS03REMEMBERЛОКАЛЬНО КЛЮЧ04ОТПРАВИТЬЯВНОЕ ДЕЙСТВИЕ
ОТПРАВИТЬ ДОВЕРИЕ ГОТОВОСНАЧАЛА ПРЯМОЙ P2PTRUST LOCAL ONLYБЕЗ АККАУНТА

This label is shared only with the peer during the first explicit trust ceremony. It is not registered as an account or cloud device.

TRUSTED ON THIS BROWSER0 УСТРОЙСТВОS
НЕТ trusted devices yet.Pair once with a verification code. The shared trust key stays inside browser storage on each device.
PAIR A NEW 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.

SEND TRUST / STATUSTrust a device once, then reconnect without another QR.
01 / NO DEVICE CLOUDThe server never receives your saved trust key.

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.

02 / MITM VISIBLEFirst trust requires a human comparison.

Both browsers derive the same ECDH secret and six-digit SAS. A signaling intermediary that substitutes peers produces different codes.

03 / ROTATING DISCOVERYНЕТ permanent rendezvous ID.

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.

04 / PROVE BEFORE SENDSaved trust is challenged again on reconnect.

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.

SEND TRUST SURFACE / EXPLICIT BY DESIGN

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.

FIRST TRUST ECDH P-256 + SASSAVED KEY NON-EXPORTABLE HMACТОЧКА ВСТРЕЧИ ROTATING / 15 MINRECONNECT MUTUAL PROOFДЕЙСТВИЯ EXISTING TRANSPORTSHANDOFF KNOWN 2XBR PATHS ONLYBACKGROUND PRESENCE НЕТSERVER DEVICE LIST НЕТ