Repository navigation
Passkeys: hide WebAuthn and explain when a page asks for it; build 5 - #20
Merged
Merged
Conversation
WKWebView runs WebAuthn only for apps with Apple's web-browser
entitlement, so passkeys and security keys always fail here. Pages still
offered them: Google's 2-Step Verification asked for a passkey or a phone
nearby and failed with "make sure Bluetooth is on".
- The polyfill deletes window.PublicKeyCredential, so sign-in pages that
check for it offer another method.
- navigator.credentials.get/create with publicKey reject at once with
NotAllowedError and, once per page, post {type: "webauthn"}. Passkey
autofill (conditional mediation) fails quietly. Other credential
requests pass through.
- The app answers with a toast saying to choose another way to sign in,
shown over the sign-in popup when that's where the request came from.
- The GeForce NOW and Figma sign-in tips and the README say the same.
- Tests: four polyfill tests on an https page (WebAuthn needs a secure
context). Three fail without this change.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01W5tzx8GXgMz9DMzc5BF4ND
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Why: WKWebView runs WebAuthn (the browser feature behind passkeys and security keys) only for apps with Apple's
com.apple.developer.web-browserentitlement, which Mouselook doesn't have, so every attempt fails. Pages still see the API, though. Because the page also sees Chrome on a Mac, Google offers a passkey or a phone nearby over Bluetooth, and that's the step that fails.Change
pointerlock-polyfill.js:window.PublicKeyCredential, so sign-in pages that check for WebAuthn (as Google does) should offer another method: an authenticator code, a prompt on the phone, or SMS.navigator.credentials.get/createwithpublicKeyreject at once withNotAllowedError, and once per page post{type: "webauthn"}.mediation: "conditional"), which runs quietly on page load, fails without a message.BrowserViewController: onwebauthn, shows a toast: "Passkeys and security keys don't work in Mouselook. Choose another way to sign in, such as a code from your authenticator app or a prompt on your phone." If the request came from a sign-in popup, the toast shows over the popup, which now has its ownToastView.project.yml: build 5.Checked
npm testpasses locally, with 4 new polyfill tests. They run on an https page, because WebAuthn exists only in secure contexts; on adata:URL the API is absent and a test would pass for the wrong reason.ios-testsjob builds it.Needs a real device
Whether Google then offers another method without the Bluetooth step can only be confirmed on an iPad. Try it in build 5: open a Google sign-in with 2-Step Verification and check which method it offers.
🤖 Generated with Claude Code
https://claude.ai/code/session_01W5tzx8GXgMz9DMzc5BF4ND
Generated by Claude Code