• Restore the existing password suggestion action when Google or another split sign-in page has focused its field before the assistant starts, or before vault unlock completes.
• Keep account selection behind a real user interaction. Typing and dismissal suppress late availability responses; saved passwords are filled only after explicit selection.
• Ignore empty aria-labelledby tokens when inspecting fields, eliminating Firefox's repeated "Empty string passed to getElementById()" warnings.
• Start the inline chooser readiness timeout before inserting its frame. A blocked frame that emits neither load nor error now returns to the trusted toolbar fallback instead of leaving a blank panel.

Regression tests cover autofocus, availability after unlock, typing races, unsafe/unmatched/new-password fields, empty accessibility labels and a silent frame failure. Disposable browser QA uses Google-shaped HTTPS fixtures and fictional accounts, without accessing a user profile or real Google credentials.

Chromium and Firefox packages are built from the committed source and independently rebuilt byte-for-byte before mirroring. The Firefox ZIP is unsigned; browser-store submission/signing is separate.

• Smart suggestions resolve the active website from the last focused normal browser window when AsyVault is opened separately. Authenticator filtering and explicit code fill use that same verified context.
• Password account suggestions remain available when a page refresh overlaps a trusted field focus.
• Passive conditional passkey requests wait for an explicit passkey choice. Password fields, Continue, Next and Try another way no longer open a passkey chooser; a challenge URL alone cannot activate it.
• Explicit passkey sign-in, encrypted vault sessions and user-confirmed credential selection are preserved.

Includes regression coverage for detached windows, site filtering, password suggestion timing, passive Google requests, explicit passkey actions, and credential signing.
Chromium and Firefox packages are built from the committed source and independently rebuilt before mirroring. Firefox archive is unsigned.

• Wider popup, a roomier full-page workspace and navigation below the scrollable content.
• Folder panels and long lists remain scrollable with multiple accounts selected. Virtualized lists retain a bounded viewport.
• Header language choices use short codes (EN, RO, etc.); Settings keeps full language names.
• Trash has a dedicated labeled button and icon beside folders, import and review tools.
• Duplicate folder names are rejected during creation and renaming, including differences in case, spacing and Unicode presentation.
• Existing duplicate folder names are reconciled inside the encrypted vault. Imported General folders join the permanent General folder; credentials are retained. Encrypted aliases preserve later import and restore destinations.
• Password health checks short, predictable and reused passwords locally using bundled zxcvbn 4.4.2. Duplicate copies of one account do not count as reuse.
• A warning can be acknowledged. Reviews remain encrypted; changing the password or adding a new risk requires review again.
• Optional Pwned Passwords checks run only when selected and started by the user. Only five-character SHA-1 hash prefixes are sent, with padded responses requested. Passwords, full hashes and account details are never sent. Unavailable checks are reported as unknown.
• Health results recommend changing the password on the website and then updating the saved entry. A matching leaked password does not prove that the user's own account was breached.
• New health messages are included in all twelve shipped interface languages.

Existing AsyVault backups remain compatible. Strength checks are advisory; no warning is a guarantee of safety. Very long passwords receive limited pattern analysis, which is stated in the result.

Store publication and Firefox signing remain separate from these local packages.

AsyVault 0.7.64 — release files

asyvault-chromium-0.7.64.zip: Chrome/Opera store package.
asyvault-firefox-0.7.64.zip: unsigned Firefox package for AMO.
asyvault-firefox-source-0.7.64.zip: complete source for review.
opera-unpacked/: Chromium files for local testing.
NOTICE.txt / RELEASE-NOTES-0.7.64.md: changes and usage notes.
FIREFOX-REVIEWER-NOTES-0.7.64.txt: reproducible-build instructions.
SHA256SUMS-0.7.64.txt: artifact checksums.

For Chromium testing, use Developer mode > Load unpacked and select
opera-unpacked. Firefox can temporarily load the unsigned package through
about:debugging. Signing and store publication are separate.

Use the Site or IP filter for accounts, and Duplicates for comparisons.
“Keep both — reviewed” acknowledges a group until an entry changes.
Trash stores deleted items encrypted and can restore them.

General cannot be deleted. Rename it or choose its color in Folders.
When deleting another folder, explicitly choose whether its contents move
to General or to Trash. Select several items to move them together.

Import opens directly inside the extension popup. The header language
selector is available on locked and unlocked screens.

Build requirements: Node.js 20+ and Python 3. No npm install or network is
needed to build. Run npm run check, npm test and npm run build.
Browser QA uses a separately installed Playwright/Chromium test runtime.
Language catalogs are static; the optional translation-maintenance script
is not part of the build and never reads a vault or browser profile.

Authenticator toolbar buttons use matching 32px rounded controls and consistent SVG icons. The plus is centered independently of font rendering; accessible labels, hover/focus behavior and reduced-motion support remain available.

Authenticator display updates now compute only visible/nearby accounts, reuse a TOTP within its current time step, and write changed DOM values only. Scrolling refreshes newly visible codes. Copy/fill still generates a fresh code; HOTP remains explicit and persisted before display. Session clearing drops the display cache. Repeated settings/Authenticator renders also avoid rewriting unchanged translations and inactive UI cleanup.

Isolated Chromium 154 benchmark, 200 fictional logins plus 131 OTP accounts, 12 navigation rounds: median Authenticator handler 41.6 -> 6.0ms; median two-frame completion 72.2 -> 46.3ms, p95 113.9 -> 68.4ms. Idle DOM mutations over 2.2 seconds: 3406 -> 36; maximum observed frame gap 50.1 -> 16.8ms. These are fixture measurements, not guaranteed physical click latency. Other tested menu handlers were already short. The 500-OTP stress fixture improved but still spends a median 178.2ms opening its full DOM list.

Validation: syntax checks and all 969 Node tests pass. Firefox 157 and Chromium 154 pass toolbar centering, account operations, import/export, QR scanning, themes, popup/full-page layout, lock clearing, Smart Filter and direct code fill. Native Chromium toolbar scan/handoff, clipboard-denied fill and lock cancellation pass. Separate scroll/menu checks confirm offscreen codes appear and an open account menu survives timer ticks.

Local Chromium/Opera and unsigned Firefox packages include complete source, checksums and reproducible-build verification. Store signing/publication and installation in an existing browser profile are separate.

Date: 2026-10-28

Clicking a code now fills the current HTTPS verification page and also attempts
to copy the code. Imported accounts no longer need a manually configured website
before filling. A clipboard denial does not prevent the requested page fill.
The optional Copy menu preference also fills when using that menu action.

Smart Filter now uses Authenticator Extension's original matching logic:
issuer/service name, page title, domain-derived site name and issuer::host aliases.
It finds brand labels such as GitHub and Google without requiring a dotted domain
in the account label. All matching accounts are shown; if there are no matches,
the full list remains available. Show all is reset for a new page. Aliases are
retained in account data while only their service label appears in the card.

The filter refreshes on tab activation, navigation, title changes and focus.
A separate Authenticator window keeps its source browser-window context and
follows that window's active tab. New preferences default Smart Filter to on;
explicitly saved preferences are preserved.

This adapts actual Authenticator Extension source at
9d9660bb73700b3e725800edc22836662d94afac:
- src/utils.ts: getSiteName and isMatchedEntry.
- src/content.ts: pasteCode and fireInputEvents.
- EntryComponent.vue: click-to-fill/copy workflow.
The original MIT attribution and license are retained.

AsyVault adaptations retain the shared encrypted vault/master password, reject
a changed active page or locked session, use native input setters and original
input/keyboard events, and support autocomplete and split-digit code inputs.
No setup key is injected into a website. No new permissions are added.

Validation:
- Syntax checks and all 965 Node regression tests passed, with no skipped tests.
- Firefox 157 and Chromium 154 passed isolated fixture checks for imported
accounts without configured origins, service/title/alias filtering, direct
code clicks, split digits, focused generic fields, tab/navigation refresh,
Show all reset and no-match fallback. Clipboard writes were deliberately denied.
- A real Chromium toolbar popup also filled an imported account on code click.
- Direct page QR scanning, confirmation, cancellation and vault-lock cleanup passed.
- Packages rebuild byte-for-byte from committed source and are mirrored with
checksums in the release and Downloads folders.

Tests used fictional accounts and controlled HTTPS pages, not live user logins.
Firefox ZIPs are unsigned; no store publication or real-profile installation.

Date: 2026-10-28

Fixes extension interference inside Cloudflare verification documents, relevant
to the reported Turnstile 600010 failures on Cloudflare and Tebex.

Changes:
- Excludes challenges.cloudflare.com, its subdomains and
/cdn-cgi/challenge-platform/ documents from static and persistent injection.
- Applies the same shared policy to manual activation, automatic hook repair
and inherited frame principals.
- Preserves native WebAuthn methods and capability responses in verification
frames, without adding the AsyVault relay, UI or repair listeners there.
- Migrates existing persistent script registrations automatically.
- Retains passkey and form assistance on ordinary Cloudflare and Tebex login pages.

After updating or reloading the extension, fully reload affected tabs to remove
the old page-world hooks.

Validation:
- Syntax checks and all 931 Node regression tests passed.
- Disposable Firefox before/after QA confirmed that 0.7.56 modified the APIs
inside synthetic verification documents; 0.7.57 preserves native methods
there while keeping normal login assistance active.
- Chromium and Firefox packages were built and checked against their dist trees.
- The release process independently rebuilds both packages from the included
committed source archive and checks byte-for-byte equality.

This is a local release. Firefox ZIPs are unsigned; browser-store signing and
publication are separate. No user browser profile or real vault is included.
Production Cloudflare verification has not been completed in the user's browser;
fixture tests cannot guarantee acceptance of a particular IP/browser/session.

Cloudflare error reference:
https://developers.cloudflare.com/turnstile/troubleshooting/client-side-errors/error-codes/

Date: 2026-10-28

Passkey implementation and its regression tests are restored unchanged from
0.7.54 (260f85b). The WebAuthn policy changes from 0.7.55 and the subsequent
attempted passkey repairs are excluded.

The two independent security fixes from 0.7.55 (f1562aa) are retained:
- Native form getters and validation of every associated submitter prevent
DOM clobbering and unsafe action/method overrides from disclosing filled
credentials. Implicit JavaScript forms remain supported; their native GET
submission is cancelled after filling.
- Inline and single-account website filling refuse requireRePrompt entries.
Those entries use the existing trusted main UI for master-password confirmation.

The form policy, fill controllers and their regression tests are reused from
the original security fix. The browser security QA covers these two fixes
separately from the unchanged 0.7.54 passkey implementation.

This is a local package release. Browser-store signing and publication remain
separate; user profiles and real vaults are unchanged.

Validation:
- Syntax checks and all 923 Node tests passed.
- All passkey source files and passkey regression tests match 0.7.54 exactly.
- Real Chromium: all six form/confirmation security scenarios and all 17
authentication compatibility scenarios passed with intercepted HTTPS,
fictional credentials and disposable profiles.
- Real Firefox 157.0 and Chromium: passkey registration and authentication,
independent signature verification, Bitwarden import and the existing
lifecycle/cancellation scenarios passed. These are synthetic tests, not
acceptance tests against a real Google account.

The earlier local 0.7.56 packages containing only the 0.7.54 rollback are
superseded by this candidate, which retains the two independent security fixes.

Date: 2026-10-28

• Form validation reads native browser getters, avoiding named-control DOM clobbering. It checks associated submit buttons and image inputs, including external form=id controls, for foreign destinations, HTTP downgrade and unsafe method overrides. Manual, split, automatic and sensitive filling reuse the same policy. Implicit JavaScript forms remain supported; a filled implicit form cannot fall back to a native GET submission.
• Inline and single-account website filling refuse entries with requireRePrompt. Protected entries are filled through the existing trusted main extension interface, which performs master-password confirmation. Other unlocked accounts keep their existing click-to-fill behavior.
• WebAuthn policy is checked in the isolated world for top-level and inherited documents as well as ordinary HTTPS frames, both before chooser admission and before signing. Direct page bridge messages cannot bypass the gate. On browsers without a native policy API, independent observed response headers and verified ancestor/container policy are required. Header evidence follows document navigation and same-document URL changes rather than expiring while a page remains open.

• Local syntax checks passed. The Node regression suite passed all 932 tests.
• Real Chromium 145.0.7632.6: all 9 security boundary scenarios passed using a disposable profile, fictional vault and locally intercepted HTTPS. Both original form attacks were refused before a password write; protected inline filling disclosed neither username nor password; top-level and inherited-frame direct WebAuthn bridge requests under a deny policy created no chooser/job. A permitted ceremony still produced a signature independently verified with Node crypto.
• The existing real-browser authentication matrix passed all 17 scenarios, including classic and implicit JavaScript forms, dynamic forms, shadow DOM, same/cross-origin provider frames, split login, unsafe endpoint exclusion, registration, explicit proposal dismissal and locked capture.
• Native GET submission after filling an implicit JavaScript form was cancelled; a framework submit handler still ran normally.
• The browser security regression is repeatable with scripts/qa_security_boundaries.mjs and the same ASYVAULT_PLAYWRIGHT_MODULE / ASYVAULT_CHROME_BINARY / ASYVAULT_E2E_WORK overrides as the existing auth QA scripts. Run npm run build before browser QA.
• Firefox fallback policy and navigation lifecycle are covered by Node regressions. Firefox runtime/store validation was not performed in this task.

This is a local source/package candidate. No browser-store submission, signing, remote publication, user-profile installation or changes to existing encrypted vaults are performed by this task. GitHub backup and the master-password encryption format are unchanged.

Date: 2026-10-26


G2G uses a JavaScript-handled form without method/action attributes. The browser reports its default method as GET, which the previous detector rejected. The shared authentication detector now recognizes that structure while continuing to refuse explicit GET submissions, cross-origin form actions and OTP/payment fields for password filling.

The same detector serves inline assistance, explicit toolbar filling and capture. It supports conventional login forms, generated field IDs, autocomplete and label hints, dynamic SPA fields, username-first/password-second flows, revealed password fields, formless controls, open shadow roots and HTTPS authentication frames. Embedded-provider matching uses the provider origin and rechecks its frame/document before filling; merchant fields remain untouched. New tabs and separate browser popup windows retain the 0.7.53 behavior. Filling does not submit a login.

Registration and password-change forms distinguish current passwords from new and confirmation fields. A fresh generated password can fill the new-password fields together; stored current passwords are not silently reused as a new registration password.

Captured login proposals open a compact extension-owned window at the top right. It remains until explicit Save or X/native close, including after source navigation, loss of focus and elapsed time. The user can review the site, username and save/update target. Lock requires unlock before saving; a locked-source capture remains encrypted until then. Proposals are ciphertext in browser-session storage, excluded from sync and exports, and end with that browser session. Saving is an explicit user choice, not proof that the website accepted the login. Protected updates retain master-password confirmation.

WebAuthn/passkey assistance remains a native cryptographic ceremony, with its required cancellation and timeout semantics. Its chooser shares the corrected screen-aware popup placement. This release does not extract passkeys owned by another browser/provider or turn them into passwords.

• Routed HTTPS Chromium matrix: all 17 scenarios pass, covering classic/G2G/SPA/formless/labels/revealed/mixed/shadow/same-origin and cross-origin frames, split WebAuthn-hinted login, explicit GET/cross-origin-action/OTP refusal, generation/confirmation, persistent Save, X and locked intake. Only fictional accounts and credentials are used.
• The save-window screenshot was inspected at 408 × 438 content pixels. The proposal remained available after navigation, focus changes and a simulated 24-hour clock advance; only explicit Save changed the vault.

Date: 2026-10-26


Saved-login suggestions and account selection work in merchant-opened browser popup windows and new tabs, including PayPal-style username-first/password-second forms. The login broker and the picker loading fallback now validate the active tab in the sender's explicit, last-focused window. They no longer depend on the background context's current window.

Switching back to an existing popup triggers assistant reinjection through the browser's window-focus event, including when its page controls are missing. Tab activation uses the event's window ID too. A repair targeted at a specific window never falls back to an unrelated active window. This also upgrades an older in-page assistant without reloading the login document.

Saved accounts still match the child login site's HTTPS origin, not the merchant/opener. The exact tab, window, URL, document, permissions and unlocked session are rechecked before filling. A background popup or a changed page is refused. Account selection fills the requested login stage without submitting it; parent merchant fields remain untouched.

No new permissions, vault schema, cryptographic storage or default unlock-policy changes.

• JavaScript syntax checks and all 896 Node regression tests pass. Five new tests cover a background-current-window mismatch, inactive popup refusal, picker loading, targeted popup repair, and no unrelated-window fallback.
• Firefox: 11 disposable-profile scenarios pass, including a real merchant-opened popup (window type verified), a new tab, both split-login stages, recovery of a stopped assistant by returning window focus without navigation, and existing permission/unlock/manual-Lock checks.
• Chromium: eight scenarios pass, covering standard split/WebAuthn/dynamic/combined forms, merchant popup/new-tab filling, tab reactivation and Lock are covered. This headless Chromium emits no native window-focus events even when its focused-window state changes; the artificially stopped-assistant focus-recovery subcase is reported as skipped, not passed. Native recovery is verified in Firefox.
• Before the fix, five targeted regressions failed; ordinary Firefox popup filling worked, while the stopped-assistant return-focus scenario retained zero assistant controls.
• Browser QA uses local/routed HTTPS fixtures and fictional credentials. No live PayPal authentication or payment is submitted; no real browser profile is changed.
• Release packaging independently rebuilds both browser ZIPs from committed source and verifies byte equality, identities, archive paths and local mirror checksums.

Login forms now offer a readable Unlock AsyVault action when the vault is locked. The inline panel uses a separate row for capture actions and retains its width despite hostile website styles. Locked suggestions disclose no saved account labels, usernames, match counts or saved-site index.

After one successful unlock in this browser profile, trusted HTTPS login submissions can be retained temporarily while locked. Credentials are encrypted immediately with a random AES-GCM key wrapped by RSA-OAEP; the private capture key is itself encrypted with the vault key. The bounded inbox expires after five minutes, supports encrypted username-first/password-only steps, rechecks origin, tab and exclusions, and is cleared when assistance is disabled. Unlocking moves valid captures into the existing extension-owned review flow. Only explicit Save/Update confirmation changes the vault. Empty passwords are not saved.

Settings → Automatic vault lock now includes Keep unlocked on this device (including restart). It is off by default and requires a fresh master-password check to enable. A browser-managed non-extractable AES key wraps derived vault keys in a separate local IndexedDB store; the master password is never stored. The setting is confined to this browser profile and excluded from sync and exports.

This convenience option is not protected by an OS login or hardware: anyone with control of the browser profile can access the vault. Manual Lock revokes the local authorization and requires a master unlock again. Switching to a timed/default policy also revokes it. The default remains browser-close/manual Lock.

Manual Lock now runs through a trusted extension-to-worker request, commits the revocation before acknowledging the unlock screen, and completes even if the popup closes. This fixes a close-immediately-after-Lock race found during real restart testing. Website content scripts cannot request this privileged UI command.

• Standard JavaScript syntax checks and 891 Node tests pass.
• Chromium: seven new scenarios cover default browser restart, opt-in persistence after a complete process restart, readable locked UI under hostile CSS, encrypted capture, post-unlock review, explicit encrypted save, and manual Lock followed immediately by restart.
• Chromium: nine broader site-automation scenarios pass, including account choices, capture/update review, native actions, and cleared locked counts.
• Firefox 157: eight scenarios pass, including native host-permission recovery, the supplied sanitized PayPal/Crunchyroll form structures, actual browser IndexedDB key restoration after session loss, and manual revocation. Complete process restart is exercised by Chromium; the temporary Firefox add-on test exercises session loss and fresh extension contexts.
• Existing Chromium split-form/WebAuthn/dynamic/combined/activation chec

Date: 2026-10-26

• Username-first sign-ins look up saved accounts even when no password field exists yet. Autofocus before content-script injection no longer requires the user to leave and refocus the field.
• Suggestions refresh after page completion, tab visibility changes and reinjection. Newly rendered SPA login fields also refresh account availability. Exact origin, active-tab, document, session and permission checks remain in the broker.
• username webauthn and current-password webauthn retain their actual credential roles when checking and filling forms. The trailing WebAuthn hint does not turn an ordinary username/password input into an unsupported field. OTP, payment and new-password fields remain excluded from saved-password fill.
• The authorized background broker acknowledges and dismisses the chooser over extension messaging using the current opaque capability. This avoids a stale iframe-load fallback or a chooser left over the website's Next/Sign in button.
• Real typing dismisses an open or pending suggestion without reading the typed value. Synthetic events generated by extension filling do not masquerade as user typing. Submit buttons do not trigger field suggestions.

The autocomplete hint behavior follows the HTML autocomplete documentation. No passkey cryptography, credential storage format, extension identities, OAuth configuration or permissions are changed.

• JavaScript syntax checks and all 876 Node tests pass, including the passkey regression suite and new suggestion/fill/lifecycle tests.
• scripts/qa_autofill_suggestions.mjs tests the actual Chromium extension in a disposable profile, with all PayPal-style pages intercepted and served as fictional fixtures. It covers an autofocused email step, trailing WebAuthn hints, dynamic fields, explicit account selection, the subsequent password step, combined login, tab reactivation and lock clearing. Selecting a credential never submits the form.
• scripts/qa_site_automation.mjs exercises the existing multi-account assistant, explicit saved-login fill, password-update confirmation, context actions, password generation and card/identity actions in the same isolated manner.
• Browser tests use fictional records only. No real PayPal login or user browser profile was accessed. Firefox browser acceptance was not rerun for this release; existing automated manifest and passkey tests still apply.

• asyvault-chromium-0.7.50.zip
• asyvault-firefox-0.7.50.zip (unsigned, for AMO submission)
• asyvault-firefox-source-0.7.50.zip
• opera-unpacked/
• Reviewer/release notes, verification report, c

Date: 2026-10-25
Firefox ZIP is unsigned. No store publication or Mozilla signing is implied.

• Fix the confirmed Google request rejection: accept opaque WebAuthn challenges within the existing 64k JSON request budget instead of the incompatible 1 KiB decoded / 2048-character encoded limit. Preserve the exact challenge in signed client data; decoded challenges are bounded to 48,000 bytes and the full request remains bounded to 64,000 characters.
• Infer omitted WebAuthn RP IDs from the browser-verified frame origin. Inherited about:blank documents no longer submit an empty hostname.
• Preserve broker validation and authorization errors. They no longer silently launch Firefox's native USB-security-key dialog.
• Validation diagnostics retain only fixed field/error categories; no challenge, credential ID, account, key or URL values are retained.
• Includes a real Firefox roundtrip harness for ES256, RS256, actual Bitwarden JSON import, independent signature verification, inherited frames and conditional activation/cancellation.

Automated tests and isolated Firefox tests are recorded separately from Google account acceptance in the accompanying validation notes.
A synthetic request on accounts.google.com proves routing only, not Google account sign-in.

• asyvault-firefox-0.7.48.zip — unsigned Firefox add-on.
• asyvault-chromium-0.7.48.zip — Chromium-family add-on.
• asyvault-firefox-source-0.7.48.zip — source and reproducible build.
• opera-unpacked — developer installation directory.
• SHA256SUMS-0.7.48.txt — artifact checksums.

Date: 2026-10-21
Status: Local submission candidates (not signed, uploaded or published).

• WebAuthn PRF with per-credential HMAC secrets stored inside the encrypted vault:
  supports first/second salts and evalByCredential for AsyVault passkeys.
  Imported credentials do not fabricate the original provider's PRF.
• Bounded largeBlob registration, read and write (16 KiB per credential)
  inside the encrypted vault; no plaintext cloud sync.
• RS256 (RSA-2048) signing and COSE key registration in addition to ES256.
• Same-origin iframe passkeys when permitted by browser Permissions-Policy;
  cross-origin iframe requests continue through the browser.
• Hardware/hybrid-only hints correctly use the native browser provider.
• Regression tests for signatures, PRF stability, encryption, iframe
  boundaries and native fallback.

• npm test: passed (exit code 0) on asypc.
• npm run build: passed (exit code 0), both Chromium and Firefox.
• Archive CRC, manifest 0.7.12, entry-by-entry dist comparison: passed.
• Independent rebuild from submitted Firefox source archive: exact byte match
  for Firefox and Chromium release ZIPs.
• No live Google sign-in, production account login or AMO acceptance was verified.

• asyvault-chromium-0.7.12.zip — Chromium / Opera / Opera GX store submission.
• asyvault-firefox-0.7.12.zip — Mozilla AMO submission (unsigned).
• asyvault-firefox-source-0.7.12.zip — matching human-readable source + build scripts.
• FIREFOX-REVIEWER-NOTES-0.7.12.txt — copy into AMO Notes for Reviewers.
• README-REVIEW.txt — full source rebuilding instructions.
• SHA256SUMS-0.7.12.txt — artifact hashes.

AsyVault does not replace the operating system's global FIDO2 provider.
Cross-origin frames, unsupported WebAuthn extensions, external hardware
authentication and attestation requests can use the native browser provider.
Google passkey success is not yet confirmed on the affected Opera session.
This package is not a signed Firefox XPI or an automatic update.

Date: 2026-10-21
Status: Local submission candidates (not signed, uploaded or published).

• Improves WebAuthn/passkey interoperability by implementing AuthenticatorResponse.toJSON()
  on the AsyVault response adapter in addition to existing credential serialization.
• Conditional passkey chooser now recognizes accessible button labels and additional
  localized names for passkey/security-key actions.
• Adds regression tests for response serialization and a localized, trusted
  passkey activation click. Fallback to the native browser provider remains intact.
• Keeps the existing vault encryption, RP ID/origin validation, explicit account
  confirmation, and key signing rules unchanged.

• npm test: passed (exit code 0) on asypc.
• npm run build: passed (exit code 0), both Chromium and Firefox.
• Archive CRC, manifest 0.7.11, entry-by-entry dist comparison: passed.
• Independent rebuild from submitted Firefox source archive: exact byte match
  for Firefox and Chromium release ZIPs.
• No live Google sign-in, production account login or AMO acceptance was verified.

• asyvault-chromium-0.7.11.zip — Chromium / Opera / Opera GX store submission.
• asyvault-firefox-0.7.11.zip — Mozilla AMO submission (unsigned).
• asyvault-firefox-source-0.7.11.zip — matching human-readable source + build scripts.
• FIREFOX-REVIEWER-NOTES-0.7.11.txt — copy into AMO Notes for Reviewers.
• README-REVIEW.txt — full source rebuilding instructions.
• SHA256SUMS-0.7.11.txt — artifact hashes.

AsyVault does not replace the operating system's global FIDO2 provider.
Cross-origin frames, unsupported WebAuthn extensions, external hardware
authentication and attestation requests can use the native browser provider.
Google passkey success is not yet confirmed on the affected Opera session.
This package is not a signed Firefox XPI or an automatic update.

AsyVault 0.7.10 – Security, Backup & Sync Improvements

This update brings improvements to security, encrypted backups, synchronization, and overall usability.

What's new:
- Improved encrypted backup and restore functionality.
- Enhanced local-first vault synchronization and conflict handling.
- Added improved vault item history and recovery capabilities.
- Improved handling of concurrent changes across devices.
- Optional Authenticator (TOTP) unlock for previously authorized browsers.
- Enhanced password management and website integration.
- Improved interface responsiveness and usability.
- Additional security hardening, bug fixes, and stability improvements.

Your vault data remains encrypted, with the master password serving as the primary authentication method.

Thank you for using AsyVault!

AsyVault 0.7.9

• Added optional vault unlocking with six-digit Authenticator codes.
• Added local QR enrollment, a manual setup key and code verification before activation.
• Each new browser must first be authorized with the master password.
• Authenticator configuration syncs inside the encrypted vault; browser authorization keys remain local.
• Added code replay prevention and a five-attempt limit.
• The master password remains available for unlocking and recovery

AsyVault 0.7.7

• Added a complete type filter: Login, Card, Identity, Secure Note, SSH Key and Passkey, including empty categories.
• Added individual passkey display-detail editing and deletion while preserving passwords and other keys.
• Prevented stale device copies from restoring deleted passkeys during synchronization.
• New-item creation now defaults to the selected editable category.

AsyVault 0.7.5

• Moved login-field icons outside input borders so they no longer cover the fields.
• Improved save-login suggestions for supported SPA forms and submit buttons.
• Added compatibility for WebAuthn passkey requests that also include the legacy U2F AppID option.
• GitHub sign-in is now required when setting up a new vault. After authorization, AsyVault automatically creates its private backup repository if needed. Existing backups still require review before syncing.
• Reduced periodic synchronization from five minutes to one minute while the vault is unlocked and GitHub is connected.

Automatic account suggestions and matching counts in the toolbar and beside login fields. Field icons now sit outside the inputs and switch sides when space is limited. Changed passwords can be reviewed and updated after confirmation. The browser context menu provides fill, copy, password generation, and card/identity actions. Passkey dialogs use larger text and a compact layout. Includes compatibility fixes for the GitHub WebAuthn library and session-key handling improvements.