Hi Mike,

I am facing an issue with Wi-Fi sync. Let's assume you have device A , device B, and a Master Computer C, each loaded with the appropriate mSecure app. I am encountering a bug in which if a record is modified on device A, but not synced right away, and if later the same record is touched or copied (but not modified) on device B, somehow when the devices are synced to the Master Computer, the record that was modified on A is not captured and what you are left with after the synchronization is the original unmodified record. It appears that the effect of touching the record on device B made the record on device B appear to be the latest record even though it was not modified in any way. It does not matter if A is synched first or B is synched first - the end result is the same and any modifications made on A are lost unless those modifications are made at a later time.

I believe what happened is that the synchronization takes the date/time from the recents list rather than the modified list. This is probably why the Master Computer overrode the record with the data from device B as it was touched at a later time.

This issue might not be restricted to Wi-Fi sync alone. I can think of a scenario whereby if device B were to lose its connection to the cloud server, for example, at a low signal area or when B is on roaming and intermittently connected to Wi-Fi hotspots, any changes made on device A and synched to the cloud would likely be reverted back to B if B's record was touched at a later time than when the modification was made on A.

Hi Mike,

OK, let me explain what I mean by "touching" a record. I am borrowing the term from the Linux "touch" command which on Linux helps to update the timestamp on a file so it will be recompiled into object code. Similarly, on mSecure such a record would just appear to jump to the top of the Recently Used list. This could happen by copying the password, username, notes, etc, or it could happen by just clicking on the options icon at the end of a url field and performing any of the functions to open the url or to copy it, and by doing so, resetting the Recently Used timestamp of the record to a new date and time.

I hadn't actually thought of some of those scenarios you portrayed in your third paragraph, but I have just done a quick test. And indeed, the issue is happening even in those scenarios: by simply tapping the reveal/conceal toggle on a field or tapping the star to set a record as a favorite, or as I have mentioned by copying a field or opening a url.

The same issue is also occurring if you "touch" the records on device C before synching, so this suggests it is not a platform issue. In my case, it happens on both Windows and Android.

Hi Mike,

I am afraid I have to bring up this issue to your attention once again, but this time I found that the issue is also manifested while syncing with mSecure cloud and is not purely affecting Wi-Fi sync as I had previously thought. It is also not restricted to the rare occasion where the device is not able to contact the mSecure cloud server in a low signal area or while roaming.

To be absolutely clear that we are on the same page regarding the issue, I am detailing the exact steps I used so you can replicate them at your end.

1. Create a test record with username and password on device A and sync it to the cloud. Sync device B and make sure the test records match.

2. Change the password on device A. Check that device B is synced correctly. Thus far there is no problem.

3. Now remove mSecure app from memory on device B - you can either force stop the app or launch the recent apps and swipe the active app to the right. This is to simulate the event that mSecure has not been actively in use for some time on devices that you do not normally access.

4. Now change the password on device A and press the sync button to make sure the password is updated to the cloud.

5. If you now open device B, you will see the previous password is still shown in the test record. Copy the username or password or toggle the favorite icon without changing the password.

6. Open the test record on device A - the new password that was changed in Step 4 has reverted to the original password that was entered in Step 1.

In Step 5, if the data was synchronized first before any task was performed, the correct password would have been saved into device B. However, it should not be a prerequisite for the user to perform the sync manually on devices the user has not used in a while.

What do you think? Is this something that should be addressed ASAP?