Dropbox unlocking takes several minutes

[vladox]

Describe the issue you're having

When opening vault stores in Dropbox unlocking takes several minutes

What were you doing when the issue occurred? How do we reproduce it?

Connect to a Dropbox stored vault and try to unlock it

What OS version are you using

Android

What version of Android/iOS are you using? Eg. Android 8.0 / iOS 12.3.1

Android 9 PKQ1.180729.001 MIUI Global 10.3.7

What device are you using

phone

What phone/tablet are you running the app on?

POCOPHONE F1

[perry-mitchell]

Hi @vladox, sorry to hear you’re having problems. That phone definitely shouldn’t be a slug when it comes to decryption. It takes a little time to unlock usually due to the encryption techniques used - this is all for security’s sake of course. It should not take more than a few seconds.

Unfortunately there’s not much we can do without being able to reproduce it, however. We haven’t seen any slowness when unlocking. I don’t suppose you can try any other source type like Google drive or WebDAV?

[vladox]

Hi @perry-mitchell thanks for taking the time to answer my report. Now I tried copying the file to Google Drive and it's actually worst since after authenticating and trying to connect it remains in connecting for ever. So I'm not able to test Google Drive. Is there a way I can debug this issue? I can install ADB and try to get some logs.

[vladox]

@perry-mitchell here some screen recordings

[perry-mitchell]

These look like issues making the requests, vs actually handling vaults. The google drive one you show is just connection functionality and it’s not even from our app- it’s using a native google module.

Can you confirm that this still occurs on other networks such as wifi? It would appear as if you have extremely slow or throttled internet access.

[vladox]

I tried over WiFi as well with the same result also tried reinstalling the app no difference whatsoever. Do you think there's a way to debug this directly on my phone?

[5k9m]

I can confirm the Google Drive infinite connecting issue on iOS 13.1.2 with iPhone 7 with both Wifi and cellular connection.

[PaoloneM]

Same problem on my device (Nokia 8) with Android 9, after successful auth procedure, connecting to Google Drive infinite wait result in no further action. EDIT: this happens with my account that has 26 of 100GB space used and a long list of folders in root, if I use another account with just a few files and folders, the procedure of connecting successfully ends in a few seconds.

[perry-mitchell]

my account that has 26 of 100GB space used and a long list of folders in root

Ah that'll be it then! The client is taking forever fetching the remote contents because the list is so long. This is quite tricky as no other file storage has this limitation, and preferably we wouldn't code something special just for Google. Seems that we'll need to figure out a way, however.

https://github.com/buttercup/googledrive-client/issues/4

[ialiendeg]

Hello, first of all congrats for this great project, using it since I heard for the first time and more happy every day :)

About this issue, I did a couple more tests and I think that it's not a problem with account size or files number.

In my case I use two vaults, one is private, located in my dropbox account folder, and the other is from work and is located in a shared folder inside the same account. My private vault takes forever to unlock, but the shared one only a few seconds. Then I copied the shared vault in the same folder where the private is and the unlock keeps the same, few seconds. On the other way, if I copy the private one in another folder, the problem still happens. The private one is about 2,6Mb while the shared one is only 480kb, don't know if that can be the problem.

So for me it seems a vault problem, but only in android platform (my device is an Honor 8), because I can successfully use that private vault every day in my macbook pro (mainly in chrome's extension but also tested in desktop app). I can also unlock it in an iPad mini 4, although it lasts a minute or so to do it.

I'll try to hunt down if there's something in my vault that can be problematic, but at this moment I have no more clues in my mind.

[pleswi]

I have same problem with file on dropbox on my phone. (Android 10 / Google Pixel). Unlocking takes soooooo loooooong. Doensn't matter am I on wifi or not. It happens only on phone app -Desktop app or browser extensions doesn't affected.

[perry-mitchell]

I’ve now been able to reproduce this in development, but I see no errors or warnings pertaining to the delay. I’ll have to tear apart the core to place checkpoints and logs, and I don’t currently have the time to do this. Would be excellent to get a hand on this one!

[pleswi]

I made some test cases. I used GDrive and Dropbox, on wifi or on cellular connection.

Results: Doesn't matter on connection type. Doesn't matter which type of cloud I used. Unlocking is the procedure, which take so long. Same archive on pc or browser works fine. Unlocking takes for ie 5 minutes or more, with success at the end Looks like something waiting for something else with long limit.

It's annoying, because if I need password, ussually I need it immidiately, without waiting.

[perry-mitchell]

I think this is starting to sound like a crypto issue.. Perhaps. There might be something running slower on some portion of devices. Just a theory at this point however. We'd really need someone with a problematic device to dive in to debugging it.

[pleswi]

I have problematic device, but I haven't expreriences with debugging android app. Some basic knowledge about adb.

[pleswi]

I think the problem started after I added OTP services

[perry-mitchell]

I think the problem started after I added OTP services

I recall hearing this issue from other users before OTP was released (in fact this issue was made before OTP was out). so I don't think it can be that. OTP processing is extremely lightweight too.

[pleswi]

Any updates? It's really annoying and the issue is quite old...

[dalvarezsmiet]

I have this same issue, quite annoying to say the least. I'll try to clone the repo and try to reproduce it, but since I have not experience with react-mobile, let's see how far can I get.

[perry-mitchell]

We've not been able to reproduce this issue, so we can't help debug it unfortunately. We would need either:

• Access to a device that is producing the issue, so we can debug using development code
• Someone who has access to a device that is producing the issue, and who has the patience to debug it themselves

Anything outside of that I don't see as being constructive, I'm afraid :(

If you've got a better suggestion, please don't hesitate to mention it.

EDIT: If someone would be interested in doing some remote debug setup, with their phone and perhaps some shared environment using VSCode or teamviewer, we might be able to do it this way.

[pleswi]

I made export from problematic vault, create new, and imported it back = no change. But when I change the csv - I deleted all data except important columns like login, password, id, category,... voilà - it works much better (max 30 sec.). My opinion - datatype of user's columns (I use different types - saved by chrome extension), or OTP ( I know, this problem was founded earlier than OTP)

[pleswi]

EDIT: If someone would be interested in doing some remote debug setup, with their phone and perhaps some shared environment using VSCode or teamviewer, we might be able to do it this way.

If you get me instruction, what I have prepare, install and setup, I can provide my phone and notebook through Teamviewer for debugging.

[PaoloneM]

EDIT: If someone would be interested in doing some remote debug setup, with their phone and perhaps some shared environment using VSCode or teamviewer, we might be able to do it this way.

I'm available for remote debugging on VSCode, Android device or browser. Feel free to contact me

[reuterbal]

I made export from problematic vault, create new, and imported it back = no change. But when I change the csv - I deleted all data except important columns like login, password, id, category,... voilà - it works much better (max 30 sec.). My opinion - datatype of user's columns (I use different types - saved by chrome extension), or OTP ( I know, this problem was founded earlier than OTP)

I can confirm that this improves things. I noticed that the file size of the archive shrunk from 2.3MB to 160KB for some 300 entries.

[ialiendeg]

I can confirm too, only exporting and importing from csv has shrunk my archive from 2.8Mb to 246kb, and the opening in android is much better now (about 30 secs.)

[perry-mitchell]

the file size of the archive shrunk from 2.3MB to 160KB for some 300 entries

Buttercup records delta history of all entries and groups, including their attributes. This can result in very large vaults as there are thousands of lines of history in the vault - text.

Let's take an example - A vault that has 300 entries, each with maybe 8 fields (some might be hidden attributes), and each field having maybe 5 lines of history on average - 300 * 8 * 5 = 12000. So this vault would have a minimum of 12k lines, excluding group and vault history items. You might begin to see where the space goes.

Exporting and importing wipes the history - you're only left with the raw items and no history.. eg. 300 * 8 = 2400.

[ialiendeg]

Exporting and importing wipes the history - you're only left with the raw items and no history.. eg. 300 * 8 = 2400.

Good to know it, thx for tell @perry-mitchell . At least this way we can use our preferred password app in our mobile, and saving a backup of our old vault we can always revisit our history when needed :)

I wish I could help debugging the problem, but as a Rails developer, java/android is a bit far of my knowledge, but I will keep aware of the issue just in case I could help with some test.

[perry-mitchell]

Well @ialiendeg this has been extremely helpful already. It tells me that the issue is most likely performance, as decrypting and decompressing a 2+ MiB file is insane on some mobile devices. There's most likely some inefficiencies in there too.

It might help us to update the vault format to move history out into a separate area so that it doesn't weigh down standard operation.

[dalvarezsmiet]

This sounds pretty cool. Sad to say I couldn't debug it as I had no time in past weeks. Luckily, the source of the problem is found. I'll apply the solution and keep using my favourite password keeper

[perry-mitchell]

As it seems we've found the issue - being that larger vaults cause huge delays on some devices, I think the answer lies in that we need to find a way to make vaults smaller. I'll close this in favour of buttercup/buttercup-core#267 which charges the core with having a newer, more space-friendly format.