Open digitalkram opened 7 years ago
It shouldn't be possible unless your database has grown uncontrollably. Please check the size of your kdbx
On Thu, Jul 27, 2017, 12:29 AM thy1985 notifications@github.com wrote:
How is that possible?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/pfn/keepshare/issues/44, or mute the thread https://github.com/notifications/unsubscribe-auth/AAfQxStJdQXaS3vrPPX58g0jVw5zd68tks5sSDw_gaJpZM4Ok5No .
Hmm. Strange. It is only 107KB in size. Just out of curiosity: What is Keepshare doing with the database so that it size matters in regards to data usage? (For now I disabled internet access via iptables to avoid further data usage and it still seems to work as expected)
There's really no way for that to happen. It must be an accounting problem in android.
If you store your kdbx on google drive (or any other SAF provider). The file can be downloaded when opened (only if changed, typically). On any swipe down to refresh, and any time you save the file.
In order to use up 1.6gb of data, it would have had to have done this... 1,600,000,000 / 100,000 (16,000) times during the month. I don't see this as possible.... keepshare alone would have destroyed your battery life while mobile.
If you don't store your kdbx on any cloud SAF provider, absolutely no internet that should occur, aside from the small 32 byte file request from google drive if you don't use the offline-mode hardware token. Perhaps the google drive sdk is buggy and makes endless network requests when they don't respond quickly...
The file is stored locally on my phone. I do not use offline-mode. Very strange indeed. I really used that volume when I check my data volume usage on my providers website it confirms the sum that Android shows roughly. No idea how likely it is that the accounting on android is broken. I run 7.1.1
Yeah, keepshare does 0 internet access if you use hardware token and a local file. I don't even know how this is possible: if you look through keepshare sources, you can see that it does no internet intrinsically....
My only suggestion might be to switch over to using the offline mode to prevent any access to google drive at all.
I had a similar occurence this month. Keepshare is reporting 335mb data usage in the background. I have since disabled background data usage. Seems odd. This was on a Samsung S7. I can send a screenshot if needed.
@digitalkram may I ask how you were able to measure this?
I did not. That is just what android shows under data usage "mobile data plan" (to exclude wifi traffic). There is the amount of data each app used (only downstream so your provider will charge/count more). I never did anything to verify that data but as my monthly volume was consumed also on provider end I tend to believe it is true. But as @pfn wrote theoretically not possible. I never resolved the issue and did not investigate further but just "iptabled" kerpshare so that it cannot have any connection.
Having the exact same issue. Android is reporting 1.6gb and the huge spike in usage is confirmed with what the carrier is showing for the same time period.
I'm not sure why keepshare would be causing so much data transmission. There's only, potentially, 2 pieces of data sent to the network: 1. partial decryption key (16 bytes), can be set to off-line only if the hardware supports it, and it's only supposed to be downloaded once per session. 2. the kdbx file if using a cloud storage provider (google drive, onedrive, etc.) this should only be downloaded once per change at most, unless there's some bug somewhere that's causing it to synchronize much more aggressively.
Personally, I have seen mobile-data usage in the 100-400mb per month, which is fairly excessive. I'll try to figure out why this happens when I get some time.
I forgot to mention, it should be completely safe to the app to disable "background data usage" for keepshare. Any data access should occur entirely only when the app is open, and when it does, it shouldn't be using much data.
How is that possible?