Give your feedback on Browserpass v3

[maximbaz]

Browserpass v3 was written from scratch, and is quite different than the current version. Please give it a try, and let me know your thoughts!

The release date is set for Saturday, April 13

Post feedback directly in this thread, I will triage and create follow-up issues when necessary.

It is not backwards compatible, so you'd have to install a new version of the host app as well.

Native app: How to install Browser extension: How to install (install manually, don't use policies-* make targets as v3 is not in Webstore yet!)

I recommend you reading the entire README of the browserpass-extension project, it contains description of some new behavioral changes.

If you really hate the new Browserpass, don't worry, the current version will not be removed from the Github, so you will always be able to keep using it.

---

If you use Arch Linux, to get Browserpass v3 you can add my repo or just fetch the compiled package from here.

[subdavis]

Great news, thanks! Looking forward to giving it a try.

[ghost]

Huge fan. Do you have a write-up of the changes yet?

[maximbaz]

I think the best documentation I have is both README files in browserpass-native and browserpass-extension repos, it doesn't list changes per-se, but it explains everything that's now possible. My favorite change is of course how popup looks and behaves now, much fewer keystrokes needed for daily operation. In addition, a lot has changed internally in the communication protocol between extension and the host app, it's richer and more extensible (if you want to dig into it, see PROTOCOL.md).

[DamienCassou]

@maximbaz Thank you very much for your hard work. Some initial feedback after reading the documentation and before installation.

I really like the anti-phishing protection. It seems to be really well designed, both its UI and UX. Good job.

I've been waiting for v3 for quite some time now as I thought it would help me with all these multi-steps authentications forms (e.g., with otp, or with username in a form and password in another). I'm sad that it seems v3 won't help after all (at least for otp). It's perfectly fine not to implement a feature if you don't want to but I'm not sure about the reason you give. If it's only for security reasons, then I think you should let the user decide what is best for them (it can be through an option protected by a big red warning text). Because I'm more frightened to stay connected on websites and to leave cookies around, I clear cookies as soon as I close a browser tab: using my phone for OTP would be too cumbersome.

I'm very surprised that installing the native application requires sudo (at least that's what the README says). I would prefer to install locally under my own user. I already give browserpass access to all my passwords, I don't want to give it access to all my system :-).

[mithodin]

Hi, my install of brave (on funtoo) does not react to the host being installed with hosts-brave and policies-brave. It does, however, work with host-chromium and policies-chromium.

I like the new UI. However, did you remove support for OTP? Because I could not figure out how to generate tokens, which worked in the 2.x release.

[maximbaz]

Thanks for the feedback!

I've been waiting for v3 for quite some time now as I thought it would help me with all these multi-steps authentications forms (e.g., with otp, or with username in a form and password in another). I'm sad that it seems v3 won't help after all (at least for otp). It's perfectly fine not to implement a feature if you don't want to but I'm not sure about the reason you give. If it's only for security reasons, then I think you should let the user decide what is best for them (it can be through an option protected by a big red warning text).

Multi-step authentication is still planned #286 (up until now I was trying to at least reach feature parity with v2, so that I can finally focus solely on v3), but yes OTP was intentionally not re-implemented in v3. I simply don't want to have a feature that I don't want people to use, spending time implementing something and then covering it up under settings with big red warnings is a waste of energy. In v2 I was both unhappy with having the feature in the first place, and the way it was implemented (e.g. static digits that were not updating). The reason I put in README is attempting to explain why I won't accept a PR; I think Browserpass should not promote pass-otp.

I'm very surprised that installing the native application requires sudo (at least that's what the README says). I would prefer to install locally under my own user. I already give browserpass access to all my passwords, I don't want to give it access to all my system :-).

You need sudo because the default location is set to /usr/bin and /usr/lib, which can only be written by root. Thanks to open source, you can see exactly which commands will be executed on sudo make install 😉 But it's also possible to install Browserpass in a custom location, I haven't thoroughly tested that, but something like this should work: make DESTDIR=$HOME/bin install, it won't require sudo and it will install Browserpass binary in $HOME/bin/usr/bin/browserpass. I believe by running sudo make install you are not giving Browserpass access to your entire system, only the commands listed in the install goal will be executed as root, nothing else 🙂

My install of brave (on funtoo) does not react to the host being installed with hosts-brave and policies-brave. It does, however, work with host-chromium and policies-chromium.

That's quite weird, could you please investigate some more? I took the target paths from your PR https://github.com/browserpass/browserpass/pull/295, but maybe the paths for Brave browser are not correct? Could you please remove the symlinks created by hosts-* commands that you executed and try to prove again which paths does Brave browser actually support? For example, if you executed hosts-chromium target, remove the symlink /etc/chromium/native-messaging-hosts/com.github.browserpass.native.json.

[maximbaz]

Oh, just realized I didn't write it anywhere, don't use policies-* targets yet, because I haven't pushed v3 to Webstore yet! Follow the "manual installation" for browser extension.

[mithodin]

but yes OTP was intentionally not re-implemented in v3.

In that case, I'm probably going to stick to v2. I understand where you're coming from with the reason to not include it, but I'm not trying to protect myself from someone getting into my passwordstore. I'm trying to protect myself against someone who pwned some service's password database, and in that case, it doesn't really matter where my OTP is coming from. If I'm at the point where someone has gained control over my computer to the point where they can access pass, I'm fucked either way.

[maximbaz]

I understand your point too 👍

There's also an option to implemented a dedicated pass-otp browser extension, if someone feels passionate about it 😉

[DamienCassou]

Maxim Baz notifications@github.com writes:

There's also an option to implemented a dedicated pass-otp browser extension, if someone feels passionate about it 😉

in this case, would you accept a PR adding OTP support to your native application? This would be less work for the volunteer who would only have to maintain a browser extension and the end users.

-- Damien Cassou http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

[DamienCassou]

It worked before, but I now get "Error: Attempt to postMessage on disconnected port" in the popup.

[maximbaz]

in this case, would you accept a PR adding OTP support to your native application? This would be less work for the volunteer who would only have to maintain a browser extension and the end users.

Native application will require no changes, it is intentionally implemented in such a way that it contains almost no logic, everything is done on javascript side. I will gladly assist the volunteer on how to integrate the existing native app with their extension 👍

In particular, there is a fetch request that will return the entire contents of the password entry. Then on the javascript side you would need to find the line that starts with "otp", extract the otp URL, and use some js library to generate actual codes (first Google result for me was this library: https://github.com/jiangts/JS-OTP).

If someone starts the work and has questions, please create a new Github issue for focused discussion.

It worked before, but I now get "Error: Attempt to postMessage on disconnected port" in the popup.

Sounds like the host json file is either misconfigured or contains incorrect path to the binary, how did you install it and what changed since it worked?

[DamienCassou]

Sounds like the host json file is either misconfigured or contains incorrect path to the binary, how did you install it and what changed since it worked?

I found the reason. Because browserpass v3 is not on AMO yet, I installed it as a temporary add-on. This got reverted to v2 when I restarted the browser. I fixed that by re-installing (now 3.0.1). But this is soon getting to be annoying because I regularly restart Firefox. Do you know when AMO will get the new version?

[maximbaz]

I'll release as soon as I get at least few people to try and confirm in this thread that everything works. Also hoping I get all OS package maintainers to respond in https://github.com/browserpass/browserpass-native/issues/31.

Since this is a big breaking release, I want to build at least some amount of confidence that users will be able to upgrade seamlessly, especially because as soon as I publish extension on webstores, users will receive auto-update and will need to go and install new native host right away. So ideally I would synchronize the update with OS package maintainers, and do it on Thursday or Friday, so folks have weekends to sort this out and I'm around to help debugging urgent issues.

[maximbaz]

The release date is set for Saturday, April 13

[maximbaz]

Hey guys, please see a follow-up to the discussion about OTP in a new thread: Support OTP in Browserpass v3 (#333)

[maximbaz]

Update: the latest RC are browserpass-extension v3.0.3 and browserpass-native v3.0.2.

[abooij]

0. I am very grateful for your hard work, and use browserpass daily. It is a real security solution for me. I am looking forward to v3. Thanks a LOT.

1. I normally use firefox. I just opened chromium and received a notification about this update. It's not good I did not get this notification on firefox. I must have missed something. But this is very important as I use browserpass daily and it's a shame I only know about this update because of some small notification. Can this news be made more visible, for example by updating the current browserpass extension, giving it some kind of permanent "update news" badge?

2. The update procedure is not nice. I have to sit down on a specific date and wait for the browser extension to update, then update the native application, and hope that I manage to do that, which is not guaranteed. "Yes but you can do something in the developer options to delay the update" is not a solution for the vast majority of users, and I'm not sure it actually solves the problem, because you still need to do something very specific on a specific date. Perhaps this update can be opt-in for now? A backwards compatible native host would solve a lot of problems. A backwards compatible extension would solve a lot of problems. It doesn't need to be fully featured, it just needs to have the essentials, while other things are waiting to be updated.

3. After having problems with version mismatches, I finally managed to get browserpass working on my partner's Ubuntu machine. The problems stemmed from the fact that browserpass was installed manually a long time ago, and the extension got updated, but the native host did not (of course), as the package manager did not see any package to update. Now, barely a week later, it looks like I'm back to square 1. This time it's worse because there is no package to install on Ubuntu. For me, this feels like a downgrade rather than an upgrade: I'll be forced to install the native application manually, which will guarantee that I'll have version mismatch problems somewhere down the line. I'd love to stop the upgrade until there is an Ubuntu package, but I'm not sure the proposed workaround of "temporarily" installing an extension is a solution. Going into developer options every time you start a browser should not be a requirement of a package that intends to improve usability.

4. Please don't let the above three points take anything away from point 0, namely that this is a fantastic piece of work that solves real-life problems, for which me and undoubtedly many other people are very grateful.

[maximbaz]

Thanks for the kind words @abooij!

It's sad that Firefox didn't show you a notification, it definitely should have. I think it's a bit too late to implement some persistent update message for the old extension, but definitely something we must consider for the future.

Believe me, I am well aware of the ugly upgrade procedure 😞 Backwards compatibility was considered, but I gave up on this given the amount of available time to implement and especially test all possible combinations. With the upgrade notification I was hoping to just let people know that yes, an ugly breaking update is coming, don't be scared about the Saturday release, if you know you won't be able to update, download the unpacked extension, try out now to load it via developer tools, at least you will have a working extension until you find time to update. It's totally possible to have both old and new native hosts installed side by side, if that's what you want to do. I know it's not perfect, but I hope it's temporary (not more than a few days) and to be honest it's the best I could offer to finally get v3 out of the door 🙂

Luckily it's going to get better starting from v3, I have found ways for users to freeze the versions. For Chromium, I'm now offering extensions with two different IDs, browserpass-webstore.crx (same ID as on Webstore, will auto-update) and browserpass-github.crx (never auto-updates, users must watch Github release notifications), so in the future I will be able to say "if you can't upgrade, for now switch to browserpass-github.crx". Sadly I can't do it for v2, as this requires updating native host app. For Firefox it's even simpler, you can unpack the contents of firefox.zip in /usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/browserpass@maximbaz.com/ folder, and Firefox will use this extension regardless of what's currently on Webstore (actually, let me document this in the top of README in this repo).

What I described above is also packaging-friendly, for example on Arch Linux I'm packaging browserpass (native host app), browserpass-chromium (which installs browserpass-github.crx) and browserpass-firefox (which installs unpacked Firefox extension in /usr/share/mozilla). This way, starting from v3 I as a package maintainer am finally able to control when exactly users receive updates for native host app and browser extensions, I am finally able to release them together.

I do hope other distros pick up the same pattern, but it isn't the case yet. I was able to reach Browserpass package maintainer on NixOS and they prepared a v3 release for native host app (not browser extensions though), maintainer on Debian responded in a thread but haven't prepared any package updates yet (to my knowledge), and I was not able to reach Ubuntu or macOS package maintainers.

For me, this feels like a downgrade rather than an upgrade: I'll be forced to install the native application manually, which will guarantee that I'll have version mismatch problems somewhere down the line

I'm planning to have very few updates for v3 native host app after the Saturday release, it was a pain forcing people to often update it, so one of the big v3 design goals was to shift as much functionality as possible to the browser extension side, which is easier to update.

But in case there is a new version of a native host app, Browserpass v3 will notify you:

So, as much as I would love Ubuntu folks to update browserpass package, it's okay if you install it manually.

[abooij]

Thanks for your extensive reply, @maximbaz. It is clear that you have exhaustively searched for solutions!

[abooij]

@maximbaz, Will the new extension detect when an old native host is installed, and give (a link to) appropriate update instructions? (As opposed to the old "Error: Native host has exited".)

[maximbaz]

not really, partially because it's a completely different native host, with different ID, the new extension doesn't know anything about the old native host because it must be configured with new json files; but also because theoretically v2 and v3 can run side by side so it doesn't make sense if v3 starts to complain about the presence of v2 app.

What will happen though is once browser extension gets installed or upgraded to v3, it will show notification with a link to Github with instructions on how to configure the new host app.

[frihamn]

Hi @maximbaz

The installation process on Mac seems quite a bit more burdensome in v.3 with additional packages having to be installed etc. After running into issues I tried https://github.com/gopasspw/gopassbridge (which also supports OTP) and the installation process is much smoother.

My main point though, now that the backend has been separated from the browser plug-in, wouldn't it make sense to just adapt it to gopass with its json api and native messaging? This would make the installation process easier across all platforms and allow more development effort for improving the browser plug-in as well as potential for synergies with gopass bridge. I have no issues with running both pass and gopass on my system.

[maximbaz]

Thanks for the feedback 🙂 If by "additional packages" you refer to the fact that you had to install browser extension manually - this is because we are in pre-release mode, but starting from tomorrow the new extensions will hit Web Stores 🎉 But if you refer to the "native host app", just like in v2 we have to have this extra app in order to give browser extension access to files on your local system - however both v2 and v3 have a user-contributed homebrew tap for Browserpass for macOS, so installation should hopefully be smooth.

I had similar idea about gopass json api, in fact I did propose at some point to align with gopass api, but this idea didn't get any interest. However, remember that we also want Browserpass to work for people who only use pass, not gopass - in fact, right now Browserpass does not depend on either of them, it only requires gpg installed. And finally I need to be able to have some decision-making/control powers over the way native app is implemented, that's definitely simpler when having our own native host app. In fact, even if gopass folks suddenly became interested in aligning our APIs, I'd probably choose to stay with our own app - besides the benefits explained above, I have some features implemented which are not present in gopass api, and one other very nice benefit is that our app is very small (because it's doing only one job), and less code means less bugs, less often releases and easier to audit.

The switch from v2 to v3 is painful, but we learned a lot and I do believe future updates will be much smoother.

[abooij]

@maximbaz, The extension just got updated for me. It gives an error message: "Error: Error: Attempt to postMessage on disconnected port". No update instructions.

[maximbaz]

Was there no update notification? 😞

Please follow the instructions in this repo, you need to install and configure a new native host app: https://github.com/browserpass/browserpass-native

[abooij]

@maximbaz There was a notification that the extension got updated, but this disappeared after a few seconds and could easily be missed. It would be better if the extension gives a useful error message :)

Edit: by the way, I can't find browserpass in community on Arch.

[maximbaz]

I'm pushing it right now 😉 If you are on Arch, I would highly recommend you uninstall extension from Web Store, and instead install browserpass-chromium or browserpass-firefox from [community] (am preparing these packages now as well), this will make sure that you will never experience breaking releases anymore, as browser extension and native host will update at the same time.

EDIT: packages are available in [community] now (browserpass, browserpass-chromium and browserpass-firefox), and I also pushed browserpass-chrome to AUR.

[abooij]

The packages you pushed seem to work, thanks!

[dg01d]

Package updated to broken state without warning.

New package has completely removed OTP functionality.

No simple manner to revert to the functioning OTP-aware version of package.

[maximbaz]

Make sure to read FAQ for what happened to OTP and how to revert to a legacy version.

[dg01d]

Make sure to read FAQ for what happened to OTP and how to revert to a legacy version.

Doesn't work on MacOS. Adding a temporary extension every time I use my damn browser isn't happening. You have deliberately broken the extension which was installed in good faith. A breaking change like this should not have been forced on people, rather a new extension should have been made available and a 'nag-screen' added to the existing functional extension.

Your FAQ on OTP is, frankly, insulting. otp-pass exists for good reason, bringing otp functionality inside the gpg-encrypted password store.

Your extension, amazingly, doesn't even rely on passwordstore any more.

[erayd]

@dg01d

1. The old extension has been displaying a warning popup on startup for the last week, explaining that this upgrade was coming.
2. You don't need to add it as a temporary extension every time you start your browser. If you wish to continue using v2, it can be installed permanently, once. This is explained in Q3 in the FAQ.
3. There will be a separate OTP plugin for v3. We agreed that this was an acceptable compromise; it mitigates the problems inherent with continuing to support OTP within the main extension, while still providing full support and integration with the fill workflow. If you would like to contribute to this effort, your input would be welcome - the issue currently tracking the OTP stuff is here.
4. The v2 plugin doesn't rely on pass / passwordstore either. It has a native host component which calls gpg directly, just as v3 also directly uses gpg.
5. Yes, v3 is a breaking change. There have been breaking changes in the past too. A breaking change is not a reason to roll an entirely new extension ID in the webstore every time it occurs - it would result in an awful lot of clutter, lose user settings (because they'd be stored under the old extension), and also break auto-update of the extension, which the vast majority of browser users expect to happen without requiring them to go to the webstore and install a completely different extension.

You have deliberately broken the extension which was installed in good faith.

We have deliberately provided a significant upgrade in good faith. If you don't like it, you are welcome to continue using the legacy version - nobody is stopping you, and we have even provided documentation explaining how to do so.

If you have additional constructive questions, please feel free to post them here, and we will address them. This is not a forum for general ranting and ad-hominem however.

[erayd]

@dg01d

Doesn't work on MacOS.

If this isn't working for you on MacOS, could you please open a new issue on this repo explaining the problem, and we'll look into it. Permanent install on MacOS should definitely be possible.

[dg01d]

The old extension has been displaying a warning popup on startup for the last week, explaining that this upgrade was coming.

Yes, a popup occurred. On macs, the popup stated that v3 was a major upgrade, and provided a non-clickable link to github. It did not specify that this was a breaking change.

The first I knew that a new additional program element was being introduced was this mornings "New major update is out", which appeared after the extension had updated. The first time I was informed that OTP functionality had been removed was when I came to github to find out how to make the extension functional.

There will be a separate OTP plugin for v3. We agreed that this was an acceptable compromise; it mitigates the problems inherent with continuing to support OTP within the main extension, while still providing full support and integration with the fill workflow. If you would like to contribute to this effort, your input would be welcome - the issue currently tracking the OTP stuff is here.

If this is the case, why is this not specified in the release notes for this release? Instead there's a lot of, frankly, hectoring notes regarding why using OTP is bad and noone should do it. There's no indication, at all, that OTP support is something which is actively being pursued, just very insulting language about why it isn't.

Yes, v3 is a breaking change. There have been breaking changes in the past too. A breaking change is not a reason to roll an entirely new extension ID in the webstore every time it occurs - it would result in an awful lot of clutter, lose user settings (because they'd be stored under the old extension), and also break auto-update of the extension, which the vast majority of browser users expect to happen without requiring them to go to the webstore and install a completely different extension.

The popup should have specified, in the lede that autoupdating should be disabled until the user had the opportunity to evaluate the new, and non-functional, extension. Not everyone has the time or the headspace to follow the development cycle of every app, extension and program which they are using. Presuming that people do is not a good look.

Moreover, the extension updated itself to a broken state. You can say that you had a popup, but that popup was not informative, and did not provide (at least on macs) anyway of following, or even seeing the full content of, the link. I've attached screenie of the popup for information.

The only information I had was the error message Error: Error. Attempt to postMessage on disconnected port. That was it. Nothing else.

We have deliberately provided a significant upgrade in good faith. If you don't like it, you are welcome to continue using the legacy version - nobody is stopping you, and we have even provided documentation explaining how to do so.

Having had this discussion, and having had things outlined in such a frank and engaged manner, I am perfectly happy to try the new extension. This whole thing should have been handled in this manner from the off.

[erayd]

Yes, a popup occurred. On macs, the popup stated that v3 was a major upgrade, and provided a non-clickable link to github. It did not specify that this was a breaking change.

Normally major version numbers are only changed on a breaking release. That's the whole point of semantic versioning. However, I freely admit that we're seeing that from a development perspective, and perhaps that wasn't sufficiently obvious to everyone else. Feedback taken on board - we'll try to be clearer about that next time.

Why is this not specified in the release notes for this release?

It's not in the release notes anywhere because v3 never did anything with OTP in the first place - there was no release of v3 in which OTP changed, it was absent the whole time. Our release notes generally list PRs that have been merged since the previous release. The lack of OTP in v3, and the reasons why, are detailed in the FAQ.

There's no indication... that OTP support is something which is actively being pursued.

Good point - we overlooked that, so thanks for pointing it out. This information has now been added to the README.

That popup... did not provide (at least on macs) anyway of following, or even seeing the full content of, the link.

That's really good to know. Our testing did show the whole message, but it looks like something may be a bit different on the Mac side, even though the browser is the same. That the link was truncated on your system is troubling (thanks for the screenshot), and something we need to address.

I am perfectly happy to try the new extension.

Sounds good. Let us know if you encounter any issues with it - we've ensured we have round-the-clock eyes on the project during the release (hooray timezones), so if you find anything major, we should be able to address it reasonably quickly.

[symonds]

Error: Error: {"status":"error","code":14,"version":3000006,"params":{"action":"configure","error":"lstat /home/matt/.password-store: no such file or directory","message":"The default password store is not accessible","storePath":"/home/matt/.password-store"}}

And i cannot find where to change the password store location any more

[maximbaz]

In extension options, click on "Add store", fill it in and hit "Save":

[symonds]

Thats not possible as the error blocks that window from opening.

I mkdir /home/matt/.password-store, at which point the error disappeared and I could add the store location and remove the temp directory.

Should be fixed so that if the directory doesn't exist you can still set those options.

[maximbaz]

Nice finding @symonds, will fix 👍

[erayd]

@symonds Fixed in browserpass/browserpass-extension#94.

[mithodin]

Hi, my install of brave (on funtoo) does not react to the host being installed with hosts-brave and policies-brave. It does, however, work with host-chromium and policies-chromium.

The problem seems to be fixed now.

[aral]

1. Launched Firefox.
2. What the fuck is that unrecognised icon doing in my browser bar? Have I been hacked?
3. Oh, it’s a new icon for browserpass. Ok.
4. Press
5. Error!
6. 🤔
7. spend the next fifteen minutes figuring out why the extension broke and how to install the new native binary

I feel the transition could have been handled far more eloquently.

1. Without breaking all existing installs by default (but prompting them to install the new, non-backwards compatible extension as an option).

2. By providing a far more streamlined migration process (especially for the native binary).

Thank you very much for Browserpass, it is absolutely awesome. And I hope the above feedback helps make it even better.

[erayd]

@aral Thanks for your feedback - I feel your pain, it's frustrating! We did try to warn people - we've been displaying a launch popup about this for the last week - but there are aspects of the transition and the warning process that we could improve on for next time something like this comes up.

1. Without breaking all existing installs by default (but prompting them to install the new, non-backwards compatible extension as an option).

Releasing an entirely new extension under a different ID every time a breaking change occurs is simply not practical. Ideally, we'd have it check the native app version and delay the upgrade until the native app is upgraded, but sadly the various webstores don't provide us any mechanism for implementing this.

If you have a suggestion for how this could practically be achieved, without cluttering up the webstore with multiple extensions, we'd love to hear your ideas.

2. By providing a far more streamlined migration process (especially for the native binary).

Normally this will be the case. We couldn't do it in any practical manner for the upgrade from v2 to v3, because the entire protocol for communication with the native app has fundamentally changed. However, we designed the v3 protocol specifically with this issue in mind, because breaking changes are frustrating for everybody involved.

Going forward, it should be possible to update the browser extension, and have it continue to function correctly with an older native app. There might be the occasional new feature which doesn't work until the native app is updated (although most new features will not require an update at all), but none of the existing functionality should break.

[dg01d]

Why is this not specified in the release notes for this release?

It's not in the release notes anywhere because v3 never did anything with OTP in the first place - there was no release of v3 in which OTP changed, it was absent the whole time. Our release notes generally list PRs that have been merged since the previous release. The lack of OTP in v3, and the reasons why, are detailed in the FAQ.

Look - I can understand the semantic explanation here. What you're saying is the same as Dennis Hopper on the set of Apocalypse Now arguing that he hasn't forgotten his lines because he never learned them. However:-

• v2 of browserpass handled OTP.
• v3 of browserpass does not handle OTP.

That should be in the release notes. It is a major change to the program. It is the removal of essential functionality for many people.

Like others, I am tremendously thankful for all that the team has done with browserpass. I don't understand why you've chosen to be this actively hostile to users, and so defensive when users react to being treated like this.

[DamienCassou]

I don't understand why you've chosen to be this actively hostile to users Your FAQ on OTP is, frankly, insulting

even though I regret the support for OTP, I don't see any hostility or insult in the maintainers' writings. In my opinion, the maintainers have done quite a good job at explaining their reasoning and at taking into account every feedback they got.

[erayd]

@dg01d OTP functionality now exists.