After reading through this painfully long thread, can you clarify what the current “official” position on this is? I think it is:
- Too complex to deal with
- Rare edge case, not worth the effort regardless of complexity
- Will not do unless someone else wants to do it
- Will do, but it’s behind 100 other things on the priority list
I assume this is not a “will never support this feature” situation or this would be closed.
Having the benefit of reading this massive 2 year old thread, I would like to now throw my accumulated cents in.
I will start with some obligatory but sincere respectfulness. Thank you for BitWarden. I really like the architecture and the soundness of the crypto; self-hosting is not at all painful; the mobile app works great; development efforts are transparent on GitHub and contributions are welcomed, unlike many other projects of this size. There is no personality cult and it’s not a toxic environment. These things are easy to take for granted. Kudos on all of these points.
Now, on with the discussion.
The complexity issue seems to be primarily (or at least partially) a concurrency issue that ought to be solved eventually, right? Editing an entry offline and having it “sync” to the server later is functionally equivalent to two authenticated sessions creating an entry at roughly the same time. The latter case is obviously a very rare edge case (perhaps it has never even happened) but the point stands. Applications dealing with critical and sensitive data should be resistant to known race conditions. Ideally, they should handle them simply and gracefully.
As far as use cases go, I find I am generally a walking edge case but a some of the examples used in this request affect me. I also want to give one that I think is underrepresented here, probably because less technical users don’t understand what the issue is and have just learned to live with the app being “broken” half of their day.
The case I am talking about is a major issue for me and probably many other people who work in medium-large corporations. BitWarden is obviously a password manager, and it is very well known at this point. Therefore, many commercial and open-source web categorization systems tag it as “Password Manager”. This means that policies can (and often are) applied at corporate egress proxies that prevent users from accessing BitWarden servers specifically, while still allowing access to the majority of the Internet. In my experience, the risk management department decides which categories are allowed and which are not, with some guidance from legal, technology, etc.
The “Password Manager” category is usually completely blocked with the exception of any specific services that the corporation has blessed as official, managed solutions. They obviously do not want to encourage employees to “steal” passwords or handle them “improperly” by putting them into their own personal password manager without having to think twice. The logic behind this is asinine; it’s a best effort control and everyone knows that. But it’s there. If the employee has a personal BitWarden subscription, they are shit out of luck, or have to switch over to cellular to update/create entries during work hours, which is painful. This isn’t about enabling employees to subvert policy, it’s about allowing users to use the application as they would normally use it when outside of a restrictive environment.
A very common case is also during travel in metro/subway systems that operate underground and through tunnels. This may be a matter of 30 seconds without coverage or 5-10 minutes. I can take a 45 minute subway ride and have service in aggregate for about 35 minutes, with it cutting out in a few specific areas. It all depends on what city you are in and how good they have implemented cell repeaters or city-wide WiFi networks. Some have neither, others have partial coverage of one or the other, etc. This may sound like a really unrealistic race window, but devices get finicky when losing and regaining coverage in these situations (especially cellular) and will tell the app they are offline for a few minutes after the connection is reestablished. At this point you’re fighting with your phone and throwing time away you’d like to be spending reading something (hopefully) useful on the Internet. Nobody creates accounts during their entire commute, but some people commute well over 2 hours per day. This is an actual issue, I think.
That’s all I have as far as use cases that I feel are worth considering solving this for. They potentially affect large user populations, and not just people writing diaries on vacation, or sysadmins trapped in cement walls, building servers and manually recording passwords in their phone
If the issue behind the lack of movement on this is simply the priority, maybe this can be reconsidered (maybe even moved up the list) some time soon. I think after two years it is fair to ask that it be reconsidered. If this has already happened, please forgive me as I do not follow the development process of BitWarden very closely
That’s really all I had to say- hopefully I’m not just adding more noise to this giant wall. I feel like little progress has been made and the points being made are not very good on either side as you get to the end of the thread.