it will be useful feature! how to create pull request for this feature?
I m agree it s mandatory. I use Keepass on Mobile phone and I usually remove/add/adjust my database offline. I can t use bitwarden without this feature. I m disappointed i will abandon it :’(
It seems like it would be much more user friendly for bitwarden to work completely offline, similar to keepass, with no need for a separate host.
It would be easier to develop as there would be no sending of info over the internet, more secure, and use less resources.
Hello Guys, any news on this topic ? I’m new here and I think that is a mandatory feature for me for on-premise environnement if we don’t want to make it available from outside. Does a feature request have been created ?
Same here, it is especially important for folks using the mobile app as one can get spotty reception during commuting for instance. it also seems far from complex to address given the fact that saving conflicting data would be blocked anyway by the site it applies to… as a minimum you can avoid the merging headache completely by rendering the record unique in the DB by tagging it with a timestamp and a dup counter
mysite vs mysite-dup-2-created-on-21/03/2019
no need… just save both entries, the second one being marked as duplicate and a unique incrementing number.
Hi I just want to point out that it is not that uncommon, in my case I have a fairly long commute on a train line with spotty network connection, and I happened to me 4 times over the past 6 months…
In my case, I ended up having to store the password on my keepass client while waiting to cut and paste it back in birwarden when I got back on the network but this is a bit of a showstopper to migrate the rest of my family from RF to bitwarden…
I agree. I would also request the ability to add/edit in offline mode. The conflict resolution doesn’t need to be very complex as long as it is documented properly. Uers should know not to use it if they don’t want to. You could also make it so that you have to turn on “edit” mode to avoid accidental modification.
I travel on the underground a lot with spotty network connectivity and quite a few times have needed to make modification but was unable to because I was offline.
I believe 1P handles this by creating and noting Conflicts… I want to move team to Bitwarden but this gives me pause to not want to tackle this even with its complexity after 2 years. I get it software is about trade offs, but should be high on the list. A few times a year users need to update an account while offline. Have to save it temporarily to ANOTHER PW manager (shakes head) seems absurd. Why is adding a NEW login disabled? No conflicts there…
Combination locks, PINs: there are several secure data types that may need to be saved while offline.
Like others have stated, we don’t want to expose our password manager to the internet which is what had us evaluating Bitwarden as an on-prem solution. Not being able to create new objects while offline is a show-stopper for our needs. Hoping that feature gets added soon.
IMO, this issue should be next up on the docket, since the heart of this issue is that Bitwarden is weak to race conditions that can lose user data.
All you need is two devices using the same account, or two devices sharing a collection and one or more of them has a shoddy 3G connection etc. and you have a considerably high chance of data loss.
Each device should be holding a local and remote state for each item, if local state is changed, it first changes the local state, leaving the remote state in the state of the last time we grabbed state from the server.
If online, after saving local state immediately grab state from server, compare to the remote state stored locally. If the same, then send a lock grabbing command with 3 pieces of data: 1. item UUID, 2. state identifier (counter? fingerprint? etc) and 3. lock timeout.
Server should have a maximum timeout for locks of 1 minute. When the server gets a lock, it checks that the item is the state that the lock request says it is, if so, it prevents any other client from writing to it.
The client gets the lock, then sends the local “local” state. And once it gets a success response, releases the lock, updates the local “remote” state to the state just sent, and deletes the local “local” state.
If the local remote state and the server state are different, you would normally need to merge, instead, create a new item, full copy, with the local local state and add (1) at the end etc.
No need for merging. a user can manually go through and clean up duplicates as they see fit.
Just ran into this where I had I was on a LAN but no internet access and needed to save a new password. The web vault only, no adding locally while offline makes it a PAIN when you come across it and encourages using weak passwords or reusing passwords, or using ANOTHER password keeper in addition to Bitwarden which is absurd.
I work on ships and am away from internet-land for, sometimes, months. I keep a variety of encrypted data on my phone and laptop and I want to keep separate encryption keys + passphrases for each (eg. diary, notes, ship computer(s), LUKS keys, etc.)
Guess what keepass(X(C)) can do that BitWarden cannot? : Read+Write the database while offline and sync when reconnected to the internet (admittedly, it relies on an external sync agent.)
Yes, the Keepass interface is clumsy compared to BitWarden, but it works and it works very well.
Also, for this use-case, merge conflicts are stupidly easy handle:
- field does not exist? – apply change.
- field does exist? – if date+time stamp is newer than last, apply change; else do not
[EDIT: fix the stupid markdown auto-create © character.]
Can’t add safe code when working with artists on cruise ship. Safe keeping item for client.
+1 for that feature, lack of that offline feature prevents me (and my team) to fully migration to bitwarden.
Guys, can we just agree on having any offline saving here with simplest possible implementation (copy on conflict) and move complex conflict resolution schemes and UI to separate feature request?
+1 for offline edits and saves. I have been using Roboform for many years. I never encountered an issue with conflicts when syncing so it can be done. The BW dev’s need to look at GoodSync and SyncBack Pro for ideas. I self-host BW and do not allow access from the Internet. It sucks that I cannot edit or save logins on my mobile devices when I’m not on the internal network. Before anyone suggests using a VPN… I do but I cannot use it on a couple of company devices nor in some secured facilities.
Not being able to edit the vault offline is an absolute deal breaker. I’m overpaying for my main password manager solely because Bitwarden lacks this.
Or simply just provide an offline mode in the app or option to disable sync…
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.