Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Suggestion] export settings from maintenance go to dowloads folder or straight to google drive #3296

Open
Not-AriStienfeld opened this issue Apr 5, 2024 · 17 comments
Labels
enhancement New feature or request

Comments

@Not-AriStienfeld
Copy link

Without a proper file sorting system, it can be annoying (and potentially confusing) to get the settings export onto the cloud. The option to send it straight to google drive would probably result in more people backing up more frequently, and would be more helpful for people who aren't as good at working with technology.

@MilosKozak MilosKozak added the enhancement New feature or request label Apr 29, 2024
@MilosKozak
Copy link
Contributor

Storing config to some cloud is a way .... But changing diricetory will be impossible with upcomming Android versions anyway

@vanelsberg
Copy link
Contributor

Suggestion: I'm using FolderSsync to automagically sync AAPS settings the (cloud) storage of my choice.
(https://play.google.com/store/apps/details?id=dk.tacit.android.foldersync.lite&pcampaignid=web_share)

@olorinmaia
Copy link
Contributor

xDrip has automatic backup to google drive which is very useful

@andyrozman
Copy link
Contributor

@MilosKozak Could we add some sort of automatic backup like that? And we could see how Xdrip has this handled... My proposal would be to create export in such way that we just add date in readable format to the end (for example settings_20240702_1202.zip) and then copy it to specific google drive directory...
Is it even possible to create export now that we need password for creating export?

@MilosKozak
Copy link
Contributor

the problem is encryption of backup. AAPS doesn't know master password

@KelvinKramp
Copy link

@MilosKozak => maybe we can ask the user to input the password when it's time for a backup?

I recently ran into the same issue. It has also been discussed in 2022 here: #1208 (comment)

The options provided there were:

  1. Automatically save settings on a regular basis (every day, keep last 5 days, last 4 nondays, last 12 months)
  2. Automatically save settings after enabling a new omnipod (or other event requiring data from settings)
  3. Provide an option to keep a copy of the settings in an alternate location
  4. Provide an option to keep a copy of the settings in a predefined cloud location (note IMHO, since we are on android, google drive might be better suited than dropbox)

I would vote for a combination of 1 and 4 and for 4 (although more cumbersome) we could use mongodb via Nightscout for backupstorage
https://www.mongodb.com/developer/products/mongodb/storing-large-objects-and-files/

@vanelsberg
Copy link
Contributor

vanelsberg commented Aug 1, 2024

the problem is encryption of backup. AAPS doesn't know master password

@MilosKozak As far as I can see the (sole?) purpose of encrypting the settings export file is to prevent sharing settings for the purpose of circumventing the need for acquiring the AAPS objectives. Right?

I will not share details, but most of you will know this can be overcome fairly easily without the need for any special tooling.
So I'd say the current solution of encrypting the settings on export (which required the users password) is not as sound as it suggests.

So to enable automatic backup of the settings using encryption the encryption key (e.g. password) need to be available to AAPS. Currently this is not the case and user is always asked to enter the password for exporting or importing settings.

Proposal#1:
Securely store the users password in Android Keystore system. This system allows you to store cryptographic keys in a secure container, making them difficult to extract from the device. Need to study details on implementing this but I think this is quite doable (Try Windows CoPilot for an example ;-)

Proposal#2:
Generate an alternate encryption key based on proof of ownership.
One (sort of minimalistic) way would be to generate the key based on the Nightscout URL and API key configured for connecting the Nightscout site. Requirements:

  1. Use the Nightscout connection specs as configured in AAPS
  2. Require AAPS being successfully connected.

Note: This solution is not fully secure and would require a working NS site. But would make it more complicated to share the encrypted settings file (at least for non-dev users)

Proposal#1 would be my choice.
Let me know your thoughts. I think I could do some draft on how to implement such solution?

@andyrozman
Copy link
Contributor

@vanelsberg Option 1 should be doable, there is simple Android way to Secure application settings and it should be pretty secure.

@KelvinKramp I looked at Google Drive API and is not very simple to use... You would expect that you could specify username and password (or even use settings directly from configured account on phone), but not such luck...
I mean there must be a way to do this, I just haven't found it yet...

Using Dropbox might be much easier, but I would like to avoid that way (person can have just 1 free Dropbox and if person is already is using it for some other stuff, using it for AAPS at same time would be a problem)...

And using Nightscout ... I don't think we should use it... Lot of people stopped using it...

but maybe someone has some other idea... Someone mentioned that XDrip is using Cloud for backup, maybe we should look into that.

@andyrozman
Copy link
Contributor

andyrozman commented Aug 1, 2024

Ok. Update on Cloud backup. I found that Xdrip had cloud backup (added in 2022): https://navid200.github.io/xDrip/docs/GoogleDriveBackup.html , so we could do something similar here, as soon as we can do automatic backup...

Tested and it it is working (but my backup size was 150 Mb, which is why it took so long (and I thought it was broken) - I have been using Xdrip for over 10 years, which explains size of database).

@vanelsberg
Copy link
Contributor

@vanelsberg Option 1 should be doable...

Ok, I'll have a look at that then.

@vanelsberg
Copy link
Contributor

@vanelsberg Option 1 should be doable...

Delay because of personal/family priorities. Just started some work on this. will try some draft/concept and when I like it, go for a draft/PR for dev's to review.

@vanelsberg
Copy link
Contributor

vanelsberg commented Sep 29, 2024

@MilosKozak @olorinmaia
After looking at Android Keystore I must conclude that this does not solve. It is great for storing secret encryption keys but to decrypt an encrypted value it needs a .... "password" :-|

I think the AAPS master password is mostly needed for preventing users to export and share their AAPS settings which include objectives. Will not go into details, but most dev will know there are easy solution for doing this without the need for knowing the password ;-)

So I decide for a solution where the password entered by the user on settings export is stored on the phone's android datastore (which should be acceptable for this purpose when user has a choice). If the stored password is not used for export within N days (default=7) it is removed from the store and user is notified to re-enter.

Now have a working implementation for exporting AAPS settings through (scheduled) automation. Dev should be able to build on this f.i. for exporting to Cloud or triggering exports on pump-activation.

@MilosKozak Planning to do a PR on dev for this week?
I'd prefer some experienced dev to do some review on the implementation. Any volunteers?

Screenshot_20240929_204637_AAPS

Screenshot_20240929_204720_AAPS

@vanelsberg
Copy link
Contributor

vanelsberg commented Sep 30, 2024

Btw: planning to look into writing to cloud storage line Onedrive or Google drive.
But that will be another PR, maybe some time this year?

@olorinmaia
Copy link
Contributor

@vanelsberg Thanks for looking into this! :) Sounds like you are making great progress here on this very useful feature request. In dev there is an automation rule now allowing for certain events to happen if canula age is x hours etc. So, one could say if 0 hours run backup automatically. Since xDrip has a working automatic backup towards Google drive, maybe that's the best place to start?

I can surely help with reviewing/testing PR.

@vanelsberg
Copy link
Contributor

@olorinmaia Tnx!
Currently testing final (DRAFT) PR. Expect soon.

PR caches password on local phone. Stored pass word will expire when not used.
Still thinking about maybe a follow-up on the need to somehow encrypt the (without needing another password/key 🙈 )

@vanelsberg
Copy link
Contributor

vanelsberg commented Oct 2, 2024

@olorinmaia @MilosKozak See PR3296 auto export (DRAFT) #3451

Testing:
Make sure Export Settings automation is disabled (in Maintenance prefs)

  1. Create an automation for auto export (it will fail with an alert)
  2. Enable auto export in settings with expiration of 1 day (it will still fail with an alert)
  3. Manually export from Maintenance (it will ask for the master password)
    As a result settings automation will export settings (confirming with info alert)

Wait at least 1 day (=24hrs):
Export will fail with alert due to password expiry (2). To fix, do (3)

(And most importantly, make sure the exported settings file is importing correctly)

@vanelsberg
Copy link
Contributor

vanelsberg commented Oct 2, 2024

Additional note:
This PR implementation does not feature auto exporting to alternate storage location (like the Downloads folder or Cloud).
This will be subject for maybe a follow-up PR.

As this PR was initiated to start supporting to the original feature request - so it does not match with the original titel of this issue - so naming it PR3296 is bit confusing.

Will move further development on this to a new issue for now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

6 participants