diff --git a/meetings/2026-02-18.md b/meetings/2026-02-18.md
index f114473..373dff6 100644
--- a/meetings/2026-02-18.md
+++ b/meetings/2026-02-18.md
@@ -6,7 +6,7 @@
 * Darrell Roberts (1Password)  
 * Darwin Yang (Google)  
 * David Henot (Dashlane)  
-* Jon Prusik (Bitwarden)  
+* [Jon Prusik](https://github.com/jprusik) (Bitwarden)  
 * Olivier Desalliers (Devolution)  
 * Rene Leveille (1Password)  
 * Robyn MacCallum (Bitwarden)  
@@ -52,8 +52,8 @@
     * Yoav: We can definitely do that, I haven't thought about it. Would also be great just to hear from yourselves in future discussions on these proposals, to get extension perspective and that feedback.  
       * We want Autofill to work well for our users no matter what the browser or Autofill provider is.  
     * Jon: Having some ability for extensions to behave in a space where the host page also doesn't have access to would be very useful. Today we have to operate in the host page space, so malicious script/etc or just an antagonistic page can be very difficult for us.  
-      * Extensions have permission models, but users \[missed this\] for autofill extensions.  
-      * Think we need some path to a user-directed privilege execution.  
+      * Extensions have permission models, but users don't typically have to approve any permissions on a host page for the kinds of concerns that impact autofill security/efficacy.  
+      * Think we need some path to a user-directed privileged execution.  
       * Yoav: So you're talking about different APIs to let extensions interact with autofill in some way?  
       * Jon: Yes, but I don't see them as mutually exclusive to the current things you're proposing. I assume the web developer is often trying to protect against automated scripts, and we're saying "no, the user directed this".  
     * David: Possibly more of a question for the \[missed this\], I suspect Autofill is not the only use case for having a privileged space for   
@@ -74,7 +74,7 @@
     * David: Some websites like to present things in web forms in multiple steps. One page for user name and another for passwords. Would be nice to have a way to connect those dots  
       * Also wanted to clarify expectations \- don’t expect that we’d get enough adoption in medium term to get rid of all the hacks. But ideally we can create an easier path  
     * Rene: For certain autofill things we have to monkeypatch some APIs, which ruffles some feathers. Provide a better way to provide credentials and autofilled things (under a dedicated extension API) could be interesting  
-    * Jon: Core to that and to the autocomplete issue \- it conflates developer wishes and user wishes. For autofill providers our job is to follow the user’s wishes. Understanding why that is is also something we’re running into  
+    * Jon: Core to that and to the autocomplete issue \- it conflates developer wishes and user wishes. For autofill providers our job is to follow the user’s wishes. Understanding why [the developer used that option/signal] that is is also something we’re running into  
       * Some orgs don’t want users to use autofill on a certain portal. Tricky balance  
       * Yoav: Any idea how we can find more data? I doubt developers are doing this for fun, so… yeah, gathering more actual data would be great.  
       * Brandon: I don't have suggestions on getting data, just thought the bank one is interesting since its the biggest single source of problems for a website type for us. They really fight us on passwords.