Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions meetings/2026-02-18.md
Original file line number Diff line number Diff line change
Expand Up @@ -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)
Expand Down Expand Up @@ -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
Expand All @@ -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.
Expand Down