Answers from first scan to final deletion

It moves one value from your phone into the exact editable Chrome field you select. It is a narrow bridge, not a password manager, synchronized vault, form filler, or login service.

Supported targets include text, email, password, search, telephone, URL, textarea, and editable-content fields. The phone displays a short-text, long-text, or masked password control that matches the selected target.

No. Start from the Chrome extension, scan the one-time QR with the phone's camera, and use the transfer page it opens. There is no Fill from Phone account or device-pairing record.

1. Open the unlisted extension test page.
2. Right-click a short-text, long-text, or password example and choose Fill from Phone.
3. Scan the QR and confirm that the phone presents the matching control.
4. Send a synthetic value and confirm it appears only in the selected field.

Never use a real password while testing.

The first phone to present the one-time write capability claims the transfer and receives a separate claim capability. The QR disappears from the desktop after that claim, later claim attempts fail, and all remaining state expires within two minutes. This prevents a second submission, but it does not identify whether the first scanner was the intended person.

No. It inserts the returned value only into the selected field. You review the result and submit the destination form yourself. The transfer requests no clipboard permission.

Password managers bind saved credentials to website origins. The Fill from Phone transfer page is a different origin from the destination, so you may need to open the password manager and copy the value manually.

Start a new transfer if the QR expired or was already claimed. Keep the original page and selected field open. Navigation, a replaced frame, a removed field, a changed field type, or a restricted Chrome page causes the transfer to stop rather than target something different. Use Chrome 120 or newer and the test page to distinguish a page restriction from a service problem.

1. The extension creates a non-exportable ephemeral P-256 private key, public key, exact 256-bit random route, 128-bit challenge, and independent 256-bit read and write capabilities.
2. The relay reserves only short-lived session state and SHA-256 capability hashes. Field classification is excluded from its reservation schema.
3. The QR gives the phone public bootstrap data in the URL fragment. Browser fragments are not included in HTTP requests.
4. The first scanner atomically claims the mailbox and receives a separate 256-bit claim capability.
5. The phone creates its own ephemeral P-256 key, derives a content key, and encrypts the chosen value before upload.
6. The relay accepts one opaque envelope and delivers it once to the authorized desktop reader.
7. The extension authenticates the envelope, revalidates the original page and field, decrypts, and inserts without using the clipboard or submitting the form.

Phone page

The entered plaintext, destination host, field type, and public bootstrap data.

Relay

Short-lived session metadata, capability hashes, transiently presented bearer capabilities, and the opaque encrypted envelope—never the content key or plaintext.

Extension

The selected page context and plaintext only after authenticated decryption.

Destination page

The inserted value and any subsequent behavior of that page's own code.

It contains the public bootstrap and one-time capabilities needed to attempt the transfer. Treat the complete QR as private while it is visible. A person who captures it may race the intended phone for the first claim.

The phone clears its visible control and overwrites its mutable plaintext byte buffer after encryption. The relay removes the envelope reference after delivery or expiry and keeps only a short-lived consumed tombstone to reject replay. Fill from Phone creates no account or recoverable transfer history.

Browser code cannot prove physical erasure from device memory, swap, screenshots, telemetry, password managers, or compromised endpoints. The phone receipt states that boundary directly.

No decryption path exists in the reviewed relay. Its accepted schema excludes the desktop public key, QR challenge, destination origin, field classification, private keys, derived key, and plaintext. It receives capability hashes and the opaque phone envelope. Under the endpoint-integrity, ECDH, HKDF, and authenticated-encryption assumptions, that transcript is insufficient to recover the content.

This property is relay opacity, not a formal zero-knowledge proof protocol. The phone page and extension are encryption endpoints and necessarily handle plaintext.

The protocol version, route, challenge, expiration, destination origin, field classification, and delivery path are authenticated with the ciphertext. Origin substitution, field-shape substitution, route substitution, protocol downgrade, and ciphertext tampering therefore fail authenticated decryption.

• Authenticated phone-to-extension round trips and single consumption.
• One winner under concurrent claim attempts and rejection of duplicate claims and replay.
• Origin, route, field classification, version, challenge, expiry, and ciphertext tamper rejection.
• Known-answer checks for SHA-256, RFC 5869 HKDF-SHA-256, and AES-256-GCM.
• Two independent P-256 endpoints derive the same 256-bit secret while private keys remain non-exportable.
• The shipped relay contains no ECDH, HKDF, AES-GCM, content key, private key, or content-decryption path.

These automated checks provide code-level regression evidence. They do not replace independent source review or penetration testing.

Email contact@asanowharton.com and follow the machine-readable policy at /.well-known/security.txt. Use synthetic values. Never include live passwords, private keys, complete QR payloads, bearer capabilities, encrypted envelopes, or other sensitive content.

No. On the unlisted test route, a minimal script exposes only the literal value installed. It performs no request, reads no page content, and discloses no extension ID, version, account, browsing history, or selected-field data. Any page script could imitate a DOM marker, so it is used only as a testing convenience—not identity, authorization, attestation, or evidence of a particular release.

No such status is claimed. The algorithm families and parameters align with applicable NIST standards, and release tests exercise their protocol use. Code-level tests do not establish CAVP validation, CMVP validation of the exact browser or runtime module, operation in a validated approved mode, FedRAMP authorization, an ATO, an independent audit, or a penetration test.

Algorithm-aligned

The construction and parameters map to an approved or recommended standard.

Release-tested

Automated checks exercise known answers, round trips, authenticated binding, tamper rejection, and single consumption.

CAVP validated

A particular algorithm implementation was tested through the NIST validation program. This is not asserted.

CMVP validated

An exact cryptographic module and operational environment have an applicable certificate. This is not asserted.

It cannot protect plaintext from compromised phone code, extension code, browser code, operating systems, keyloggers, screen capture, or the destination page after insertion. The web-delivered phone sender also inherits trust in code delivered by its origin; integration into a password manager's signed mobile client can move that boundary into the existing trusted application.

No. It ensures that only the first claimant can submit and that later copies cannot deliver. Without an identity or user-confirmation ceremony, it cannot prove that the first scanner was the intended person. Someone who wins that race can deny the intended transfer or send a chosen value.

Hosting and network providers necessarily process routine connection metadata such as IP address and timing to deliver HTTPS traffic. The application creates no account, synchronized store, analytics profile, or transfer history. The complete data-handling disclosure is maintained on the Privacy page.