Implementation via tertiary extension is unwise.

[subdavis]

First, thanks for your contribution to the community! I do not intend for the following to be personal, diminish the value of your work, or insult you in any way. Please regard as an open critique from a fellow experienced extension developer who totally respects what you've done here.

---

Extending an Extension

I get the desire to follow unix philosophy and do 1 thing well, but web extensions cannot and should not enjoy the same separation of concerns that native tools like pass do.

Resource waste

It's kinda nuts that I have to have an entire process on my machine dedicated to listening to 1 event and putting stuff on the clipboard. Chrome lets you do event-based pages (and you probably should for chrome/chromium), but Firefox is still stuck with persistent backgrounds.

User experience

Subsection A: finding and installing

Browserpass already has a very high bar for "hoops to jump through" before you get to a working configuration. I consider a lot of it to be documentation bugs, and I'd like to help with that in the near future, because I think it can be improved. This model, though, is highly unusual -- users aren't accustomed to installing extensions for their extensions. I've never done it in my whole life.

Subsection B: actually using it

browserpass-otp, as a "satellite extension" is restricted in what it can do.

Either a) its abilities will be severely limited by the necessity of having to react to events produced in the core. I can't just open this extension popup and get the OTP token I want, I have to open the core-extension and do some kind of semi-unrelated user action which I have to remember to create the magic behavior over in the background page. The relationship between what I have to click and the result is impossible to describe with any design language (buttons, iconography, animation, relative location, etc.)

Or b) the developer(s) will end up paying for the separation by embedding more and more granular event hooks into the core-extension to make extension-plugins like this support a wider variety of things a user wants to do.

That brings us to:

Maintainability (most important, IMO)

Here's an example of something that might come up within the next few weeks:

'Let's add an event hook for after the user has successfully entered their password so that any plugins can perform additional actions like placing new data on the clipboard like OTP tokens! That would solve #1!'

This is a bad excuse to grow the API surface, and will make releases more of a pain in the ass because you have to know and plan for breaking changes between core-browserpass and the extensions it talks to and the schema of messages it sends them.

You have to release them in lock-step and document more stuff and nobody has time for that.

Final thoughts

It's kinda cool that the browser lets you do this. There are so many reasons not to do it. This functionality should absolutely be baked into browserpass-extension and only show up if you have entries with OTP configured. I don't agree with the argument that browserpass should try to protect users from breaking separation of 2FA. Pass itself lets you do literally whatever you want. The feature poses no risk to users who choose not to use it, and preventing people from using their password store the way they want is not browserpass's place.

cc @erayd @maximbaz

[subdavis]

symlink browserpass/browserpass-extension#76, because I don't want to hijack discussion on that thread, but also I think core support should be reconsidered.

[erayd]

Thanks for your feedback! Let me take this one piece at a time...

Please note that many of my points are rebuttals - this is mainly because most of what you have raised, we have already discussed, and these are some of the points that came out of that discussion. However, your feedback is valuable, and if you think my arguments are weak, please say so (and explain why) - another perspective is generally a good thing.

My personal position is that I'd rather see it integrated (disabled by default and with a huge warning when users turn it on), but I do consider this an acceptable compromise, and I care more about making sure the OTP functionality which many users have a strong desire for is present, than whether it's implemented as one extension or two.

Resource Usage

It's kinda nuts that I have to have an entire process on my machine dedicated to listening to 1 event...

I agree. But isn't this the same concern as any single-purpose utility? Admittedly this one is more focused than most, but can you expand a bit more about why this is a problem? The resource usage should be minimal - there's a small amount of RAM (or potentially swap, if your system is under memory pressure) associated with a running process, but most of the time it just sits there and does absolutely nothing.

A nice counter-example is systemd - in my opinion it tries to do far, far too much in a single package.

UX Concerns

browserpass-otp, as a "satellite extension" is restricted in what it can do... putting stuff on the clipboard.

That is not all it will do. It's all it does at the moment, because we had enough users who cared about having OTP functionality that we considered it important to release something ASAP which would give them that. Dropping it on the clipboard was a very fast and expedient way to put the generated code somewhere useful without having a UI. Once we have a UI, that behavior will change.

I agree completely that right now, the UX is terrible. This is a large part of why the release notes say "...still under heavy development, and is not yet suitable for production use... More comprehensive functionality will be available in future releases."

This model, though, is highly unusual -- users aren't accustomed to installing extensions for their extensions.

Agreed. I don't think I've encountered it anywhere else either.

Browserpass already has a very high bar for "hoops to jump through" before you get to a working configuration.

We are working to simplify that, in large part through better OS packaging of the native host app, and also through better documentation. We would like, as much as possible (and are actively working towards) a scenario where most users will simply be able to install one package from whatever standard package manager / repository their system uses, and one extension (or two if they want OTP) from the Chrome webstore. In some cases (e.g. Arch), we're able to distribute the extension via the OS package manager also.

Compared to the complexity of setting up GPG (which the whole concept of pass relies on anyway), this seems pretty reasonable. We aren't there yet though, and it will likely be a while before everything works quite that smoothly, but things are trending in the right direction.

Its abilities will be severely limited by the necessity of having to react to events produced in the core. I can't just open this extension popup and get the OTP token I want, I have to open the core-extension...

As per above, this is a development release with no UI. Give us a few days, and it will have a UI that lets you do exactly what you just described - i.e. open the popup and do whatever with the OTP token, without requiring any additional interaction with browserpass. The code will refresh the way you'd expect, you'll be able to copy it, look at it, close it and open it back up again, etc.

Invoking browserpass tells the OTP extension "use this OTP secret for this tab", but it doesn't need to be invoked again after that point. Noting that login almost always occurs before TOTP entry anyway, it's pretty much guaranteed that the user will have already invoked browserpass by the time they are ready to do something with OTP.

It's also worth remembering that this workflow would be exactly the same if it were integrated into Browserpass (and in fact that's how OTP in v2 worked), because there's no way to know if any given entry has an associated OTP until that entry has been decrypted - which we are not ever going to do speculatively, in large part due to the performance issues inherent in decrypting the entire password store on something like a Yubikey.

Maintainability

Can you expand on this one a bit more please? The scenario you've described feels somewhat contrived; the whole point of implementing this as a separate extension was to keep it as far away from Browserpass as possible. There is no intention to ever expand the API surface between the two extensions, and from the Browserpass side of things it's just a fire-and-forget message that says "On this tab, with this current hostname, Browserpass found this OTP secret".

Other Thoughts

I don't agree with the argument that browserpass should try to protect users from breaking separation of 2FA. Pass itself lets you do literally whatever you want.

But if you want OTP functionality, you have to install the pass-otp extension. How is that any different to what we're doing here?

...preventing people from using their password store the way they want is not browserpass's place.

Agreed. But handling credentials as safely as possible, and implementing a UX that encourages safe handling of credentials, is absolutely Browserpass' place. That's why we have features like requiring users to confirm a foreign-origin fill, graduated auto-fill form selection, anti-phishing filtering in the search popup, autosubmit disabled by default, etc.

There are so many reasons not to do it. This functionality should absolutely be baked into browserpass-extension and only show up if you have entries with OTP configured.

Do you have any suggestions for how this could be part of Browserpass, while still addressing the concerns that lead us to separate it?

This entire extension is a compromise. We spent months talking about how to do this, and whether OTP functionality belonged in the core extension. The following factors are the main reasons we chose to go down this path:

• It solves a disagreement between the developers. There are strong feelings both for and against having OTP as part of Browserpass, and a separate extension was seen as the best way to meet somewhere in the middle.
• 2FA that isn't 2FA is risky.
• The user should be able to make an informed choice as to whether that risk is acceptable, but we don't want to encourage it - integration within Browserpass is an implicit endorsement. The problem is less "poses no risk to users who choose not to use it", and more "poses a risk that more users will decide that using it is a good idea".
• Autosubmit is risky too, and we hate it with a passion. Yes, it's off by default, but it's still present, which results in users seeing the option and deciding it looks appealing. Unfortunately, the demand for it is so overwhelming that if we didn't integrate it, it would likely lead to a fork situation - so we feel that the best position is for us to do it natively, where we can ensure it's done as safely as possible.
• Unlike autosubmit, OTP can still maintain a good UX when separated from the core extension.
• Pass itself already sets a precedent by implementing it as a separate extension; it's not part of the pass core.
• 'Install one webstore extension' is a simple hoop to jump through for those users who do still want OTP functionality.
• A separate extension is a very clear separation of concerns.

@maximbaz I've probably missed some stuff here - feel free to chip in.

[subdavis]

@erayd thank you for that very thoughtful response. I totally understand that the dev team has stalemated on this discussion and that I'm somewhat of a johnny-come-lately to this party. I don't wish to re-hash that here.

I'd prefer to just focus on whether or not this implementation is a good idea, so for arguments sake I retract my endorsement of putting it in core.

But isn't this the same concern as any single-purpose utility?

In reality, browserpass-otp isn't going to make or break anyone's hardware, but it's a total abuse of the extension platform. If everyone developed controversial features like this, we'd all be drowning in extensions. Is this really such a special case?

the whole point of implementing this as a separate extension was to keep it as far away from Browserpass as possible

Separation necessitates formal interfaces. Where are those interfaces documented? If I wanted to contribute to what is effectively a plugin framework, where would I look for how to do that? Are you going to maintain docs? I can seem some future developer coming along with a new feature they want to add, looking at the precedent set here, and following it.

Compared to the complexity of setting up GPG...

GPG was worth learning because it's a hugely popular tool with ubiquitous support. Users won't feel the same way about this super niche ecosystem.

My real point is that this is not only time-consuming to set up, it's conceptually foreign. You have to figure out a way to explain to people what the interaction between these extensions even is. Is this talking to the native messenger too? Do they have to have pass-otp installed?

The cognitive burden on users is super high, and it was already high because nobody knows what a native message host is.

Give us a few days...

Sure, I'll wait and see how this takes shape.

Finally, I'm going to do something I said I wouldn't, and re-hash some stuff:

Pass itself already sets a precedent by implementing it as a separate extension

I think the motivation @ pass was totally different. Pass is super intentional about maintaining a well-scoped core and a clean plugin system. pass-OTP as a feature is easily separable within the context of their plugin system. It's easy to isolate as bash, and pass is already committed to maintaining pluggability.

Browserpass is exactly the opposite. You're inventing a plugin system for the sole purpose of ostracizing a feature. You aren't endorsing the onExternalMessage pattern, it's just a concession.

It solves a disagreement between the developers.

Maybe, but it does so at the expense of users, whose needs are objectively more meaningful.

poses a risk that more users will decide that using it is a good idea

I would tend to believe that intersection of "people who can effectively use GPG and Git" and "people who don't know much about 2FA" is really small.

All that said, I don't think it's productive to keep going over it. Just like, let it be here known that someone without an ax to grind on either side thinks this approach is misguided.

Thanks for the discussion, cheers, and godspeed.

[jbalme]

One "solution" would just be for anyone who believes strongly enough that the functionality should exist in the main extension to maintain a fork with OTP support.

[erayd]

@jbal91 That scenario is precisely what we are trying to avoid.

@subdavis Thanks for your response. @maximbaz and I have discussed this further offline, and we feel that, although it's not ideal, our current approach is the best compromise available, so we would like to move forward and continue with this approach, even though you have made some very good points against it.

If a significant number of users complain about having OTP in a separate extension, then it might be worth revisiting - however so far, you are the only person to object.

...but it's a total abuse of the extension platform... is this really such a special case?

That's a fair criticism. Unfortunately, the choice here is realistically between OTP as a separate extension, or no OTP at all (which means forks) - so we've decided on the separate extension approach as the least-bad option.

Separation necessitates formal interfaces. Where are those interfaces documented? ...Are you going to maintain docs?

The interface between browserpass and browserpass-otp will be documented in this repository on or before the first non-development release. This documentation will be maintained, although we don't expect the interface to change beyond the initial release.

If I wanted to contribute to what is effectively a plugin framework, where would I look for how to do that? ...I can seem some future developer coming along with a new feature they want to add, looking at the precedent set here, and following it.

You don't. This is not a plugin framework (nor will it become one); it's one API call to outsource a single, specific feature, to resolve a specific disagreement in a case where doing nothing would likely have resulted in project forks.

The only other vaguely relevant scenario is a developer who is interested in providing direct smartcard functionality and the native host interface via an extension (because ChromeOS is incapable of running the regular native host + gpg + smartcard stack). That extension would use the same API as the native host, which is documented here.

My real point is that this is not only time-consuming to set up, it's conceptually foreign. You have to figure out a way to explain to people what the interaction between these extensions even is.

"If you wish to use OTP, please install the Browserpass OTP extension, which provides this functionality. That extension will provide an OTP code whenever Browserpass uses an entry which contains an OTP secret." Perhaps not in quite those words, but it's fairly simple to explain.

Is this talking to the native messenger too?

No.

Do they have to have pass-otp installed?

No. Similarly, Browserpass doesn't require that pass be installed - it uses gpg directly (albeit via the native host, because browser extensions can't execute arbitrary binaries).

I think the motivation @ pass was totally different. Pass is super intentional about maintaining a well-scoped core and a clean plugin system. pass-OTP as a feature is easily separable within the context of their plugin system. It's easy to isolate as bash, and pass is already committed to maintaining pluggability.

Good point; I agree.

Maybe, but it does so at the expense of users, whose needs are objectively more meaningful.

If you have an alternative proposal which would solve the issue, please feel free to suggest it. We know that the current approach isn't ideal - other options are always worth considering.

I would tend to believe that intersection of "people who can effectively use GPG and Git" and "people who don't know much about 2FA" is really small.

Based on the number of people we've both talked to about this who have not understood why storing 2FA secrets in the password manager, and possibly also using the password manager to generate the tokens, is a problem... this is likely to be significant. It's also a behavior recommended by some other password managers, and by some notable security names (Troy Hunt is a particular example - he pushes this behavior on haveibeenpwned.com, which gets very wide coverage).

All that said, I don't think it's productive to keep going over it. Just like, let it be here known that someone without an ax to grind on either side thinks this approach is misguided.

Thanks for the discussion, cheers, and godspeed.

Thanks for your input - we do appreciate it, and have taken it on board. At this point, we are unlikely to change the way we're doing things, but it was still a discussion that was well worth having, and you raised a number of important concerns.

[aeris]

If a significant number of users complain about having OTP in a separate extension, then it might be worth revisiting - however so far, you are the only person to object.

Objecting too 😂

Using ternary extension is quite a mess for some cases, and doesn't add so much security you say.

It's a mess because OTP extension assumes the OTP is store on the same entry than the login.
It's surely mainly the case, but it's not always the case.
Personally, I have the trouble with SSO services (using LDAP for example). I have one login/password entry for example.org, and multiple OTP entry for each services ({service}.example.org).
Log in to a service with OTP is quite a pain now:

• Use example.org to fill login & pass
• Submit login form
• Get the OTP form
• OTP extension see nothing
• Have to select {service}.example.org
• Click on OTP to select it
• Past on the OTP form
• Log in

Previously, I already got the OTP on the OTP form, because extension view all entries, not only the one used before, and directly on the corner of the pane.

And this without a lot of more of security.

OTP is not to protect for full database leaks (password manager or service or end-user), but for online service bruteforce.
Password manager attacks are quite rare and target mainly online/cloud backend storage, which doesn't exists in the case of browserpass/gopass/password-store. On the service side, leaks of password database also means OTP database leaks, generally stored on the same database if not the same table.
Direct client attack are so much quite rare, and assuming your browser is infected a way the attacker can access your password means you must assume too the attacker can access your OTP. End-user compromission is the most serious level in security, and generally accepted as a "doomed" situation, where nothing can really be done to close the hole.

So having the OTP directly managed on the same extension doesn't seem to me a trouble at all.

[max-baz]

Log in to a service with OTP is quite a pain now:

• Use example.org to fill login & pass
• Submit login form
• Get the OTP form
• OTP extension see nothing
• Have to select {service}.example.org
• Click on OTP to select it
• Past on the OTP form
• Log in

Previously, I already got the OTP on the OTP form, because extension view all entries, not only the one used before, and directly on the corner of the pane.

Hey, thanks for raising this, let me understand your use-case better, could you please clarify what was your workflow in v2? I imagine it was something like this?

1. Select example.org in browserpass to fill login & pass
2. Submit login form
3. Get the OTP form
4. Select {service}.example.org in browserpass to show OTP
5. Manually type it

And today steps 4 and 5 are replaced with:

4. Select {service}.example.org in browserpass to copy OTP
5. Press Ctrl+V

Am I right or am I missing something? Sounds like your workflow has actually improved? 🤔

[aeris]

I don't really remember what I did on v2, but seems more like :

• Select example.org in browserpass to fill login & pass
• Submit login form
• Get the OTP form
• Already have the OTP displayed on the top right corner of the page (no need to select {service} entry, because browserpass already search for the OTP entry of the current website), with the ability to copy it immediatly

Will try on an old setup to confirm that.

[max-baz]

Please do, I'm fairly certain it wasn't the case - OTP numbers appeared in the top right corner only if OTP URL was part of the selected entry, browserpass was not decrypting other password entries behind your back.