Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Nazar Mokrynskyi <nazar@mokrynskyi.com>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: wireguard@lists.zx2c4.com, David Cowden <dcow@pm.me>
Subject: Re: Allow client-side encrypted backups for Android app
Date: Wed, 8 Feb 2023 14:38:16 +0200	[thread overview]
Message-ID: <e9f33d60-4553-0795-16d8-83b54b7822d0@mokrynskyi.com> (raw)
In-Reply-To: <7SV3pRtTQ0fygsJjyhdMRte9uso_M0G_jTfDeqnELBrym4Z_3NeGeIvgNYpEdXttpmafNk_A2NqH26O6VF_8pgrXjzUOmrCVPehRX7Iu_eE=@pm.me>


[-- Attachment #1.1.1: Type: text/plain, Size: 1820 bytes --]

I know there is an export feature in the app and I used it successfully, but it doesn't make much sense to me to have that and disable OS backups at the same time.
There are use cases for one-off copying of things for which exporting as zip is great, but there are also others.

I don't want to have set a reminder and regularly go though every single app manually, use their flavor of backup feature (that doesn't necessarily store everything BTW, including in Wireguard), then collect the files somehow, encrypt them and send to the destination.

What I want is automation: configure the tool (SeedVault in my case) to create backups of all apps every day and store them in encrypted form on my private Nextcloud instance with ability to restore backups easily later on.
The issue is that some apps like Wireguard prevent me from enjoying that workflow fully and right now I don't see why would it be beneficial for Wireguard to intentionally prevent that.

With that context I hope it is clearer why I'd appreciate for current design decision around that to be re-evaluated.

Sincerely, Nazar Mokrynskyi
github.com/nazar-pc

08.02.23 04:19, David Cowden пише:
> On Android 12+ you can configure which files are backed up (among other things) at runtime using the BackupAgent API https://developer.android.com/guide/topics/data/autobackup. Would you be opposed to this being a configurable option that defaults to off?
>
> David
>
> ------- Original Message -------
> On Tuesday, February 7th, 2023 at 7:03 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
>
>>
>> I think I'd prefer to still keep this a bit more locked down. There is
>> the "export tunnels as zip" feature (which requires an explicit
>> authentication step each time), which you can use for backup/restore.
>>
>> Jason

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 4753 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

  reply	other threads:[~2023-02-08 12:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-21 13:22 Nazar Mokrynskyi
2023-02-08  2:03 ` Jason A. Donenfeld
2023-02-08  2:19   ` David Cowden
2023-02-08 12:38     ` Nazar Mokrynskyi [this message]
     [not found]       ` <CALuYY17r9eh_eAc2KRUnQXS1Fd9rCqVJR4aNaupL=W8P710qVA@mail.gmail.com>
2023-02-08 14:00         ` Nazar Mokrynskyi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e9f33d60-4553-0795-16d8-83b54b7822d0@mokrynskyi.com \
    --to=nazar@mokrynskyi.com \
    --cc=Jason@zx2c4.com \
    --cc=dcow@pm.me \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).