urge11
My feedback
38 results found
-
1,614 votes
An error occurred while saving the comment urge11 supported this idea ·
-
214 votes
urge11 supported this idea ·
-
186 votes
urge11 supported this idea ·
-
1,380 votes
urge11 supported this idea ·
-
787 votes
urge11 supported this idea ·
-
778 votes
urge11 supported this idea ·
-
428 votes
urge11 supported this idea ·
-
275 votes
urge11 supported this idea ·
-
20 votes
An error occurred while saving the comment urge11 commented
A local LLM is already bundled in the mail app. The tech exists today to run a LLM in the browser. Agentic frameworks exists in TypeScript. Small LLM (SML) are good enough today to filter elements based on medium complexity rules. Finally, a LLM is now bundled into Windows, macOS and even Google Chrome. That’s not a tech issue!
urge11 supported this idea ·
-
847 votes
urge11 supported this idea ·
-
213 votes
urge11 supported this idea ·
-
258 votes
urge11 supported this idea ·
-
370 votes
urge11 supported this idea ·
-
544 votes
urge11 supported this idea ·
-
612 votes
Work on this feature has started, beginning with iOS availability.
urge11 supported this idea ·
-
634 votes
urge11 supported this idea ·
-
628 votes
urge11 supported this idea ·
-
688 votes
urge11 supported this idea ·
-
670 votes
urge11 supported this idea ·
-
726 votes
urge11 supported this idea ·
Biometric unlock in Safari extension is technically feasible today -- here's how
As a Proton Pass user and software engineer, I wanted to share that this feature is not blocked by an Apple limitation. The Safari Web Extensions API fully supports biometric authentication through a well-documented native messaging bridge pattern. Both 1Password and Bitwarden already ship this in production.
How it works (TL;DR):
Safari extensions can't call Touch ID directly (error -1004: "Caller is not running foreground"). But they can communicate with their native Swift handler (SafariWebExtensionHandler) via browser.runtime.sendNativeMessage(). That handler runs in its own XPC process with full access to LocalAuthentication and the Secure Enclave. The extension asks the native side to authenticate, Touch ID fires, and an encrypted vault key is returned.
Proton Pass already has a native Swift MacPlugin that communicates with the desktop app via nativeMessaging -- the plumbing is in place.
Apple documentation proving this is supported:
- Messaging a Web Extension's Native App: https://developer.apple.com/documentation/safariservices/safari_web_extensions/messaging_a_web_extension_s_native_app
- Messaging between the App and JavaScript: https://developer.apple.com/documentation/safariservices/messaging-between-the-app-and-javascript-in-a-safari-web-extension
- LocalAuthentication framework: https://developer.apple.com/documentation/localauthentication
- Protecting Keys with the Secure Enclave: https://developer.apple.com/documentation/security/protecting-keys-with-the-secure-enclave
- biometryCurrentSet access control (auto-invalidates on fingerprint change): https://developer.apple.com/documentation/security/secaccesscontrolcreateflags/biometrycurrentset
Competitors already shipping this:
- 1Password -- Touch ID in Safari, standalone, no desktop app needed. Uses Secure Enclave key wrapping: https://support.1password.com/touch-id-apple-watch-security-mac/
- Bitwarden -- Touch ID in Safari via native messaging proxy to desktop app: https://contributing.bitwarden.com/getting-started/clients/browser/biometric/
High-level implementation (8 steps):
1. SafariWebExtensionHandler receives { action: "biometricUnlock" } from the extension's background script via browser.runtime.sendNativeMessage()
2. Calls LAContext.canEvaluatePolicy(.deviceOwnerAuthenticationWithBiometrics) to check availability
3. Generates a P-256 key pair in the Secure Enclave with .biometryCurrentSet + .privateKeyUsage access control -- key never leaves hardware, auto-invalidated if fingerprints change
4. At enrollment time (user enables Touch ID): ECIES-encrypts the vault key with the SE public key (SecKeyCreateEncryptedData, cofactor X963 SHA256 AES-GCM), stores the ciphertext in the shared Keychain
5. At unlock time: ECIES-decrypts with the SE private key (SecKeyCreateDecryptedData) -- this is when Touch ID fires automatically
6. Returns a session token (not raw key bytes) to the extension over the XPC channel
7. Extension stores the token in chrome.storage.session (in-memory only, clears on Safari quit)
8. On fingerprint enrollment change, the SE key is automatically invalidated -- user re-enters master password -- new SE key generated
This is exactly the pattern 1Password uses. The architecture is proven, the APIs are stable since Safari 14 (WWDC 2020), and Proton already has the native messaging layer (MacPlugin) in the Safari extension.
This feature has been on the roadmap since Winter 2024 and promised for 2025 across three separate blog posts. The community has given it ~1,600 votes. The technical path is clear -- it's a matter of prioritization.