Recreate backup transfer device message for a week after backup transfer ends

[link2xt]

On backup transfer, config option should be written with a timestamp of the last backup transfer. For a week after backup transfer, the message created in #4301 should be recreated to prevent its deletion.

This does not protect against direct database modification, but if attacker can modify the database, they can as well copy the database with their own tools that bypass any protections.

To protect against rewinding time back before doing backup transfer, timestamp should be checked not to be in the past compared to the previous backup, the last received message and other similar timestamps.

[r10s]

On backup transfer, config option should be written with a timestamp of the last backup transfer.

maybe we should write the config option already when transfer has started, so that one cannot abort backup at 90%.

that could also be used to differ between successful and failed transfer, even when the app crashes in between.

To protect against rewinding time back before doing backup transfer, timestamp should be checked not to be in the past compared to the previous backup, the last received message and other similar timestamps.

at least on macos, you need the system credentials to modify the time. +1 for additional plausibility checks, however

[iequidoo]

For a week after backup transfer, the message created in #4301 should be recreated to prevent its deletion.

Deletion of the message by the user? If we can't protect from attackers having access to the db, who else can delete it?

[link2xt]

Deletion of the message by the user?

Yes, the purpose is to notify user if someone has access to the device for 5 minutes, enough to copy do second device setup but not to disassemble the device, copy the database etc.

[iequidoo]

The device chat can also be archived, notifications muted, so the user may miss the backup transfer message.

EDIT: The first measure should be asking for the user's system password / screen lock before showing a backup QR code, which is already done on Android, but i'm not sure if/how that should be done on Desktop.

EDIT: Another question -- when to recreate the backup transfer message? E.g. an attacker may read it, but not delete, so again, the user may miss it. But if we recreate it even if it already exists, it will annoy users.

[r10s]

The first measure should be asking for the user's system password / screen lock before showing a backup QR code, which is already done on Android, but i'm not sure if/how that should be done on Desktop.

note sure as well for desktop, but that is another issue :)

E.g. an attacker may read it, but not delete

then, there are good chances, the user will notice - the device-message chat is sorted quite up, and it is also not that rare that the user enters the archive, if they are using it. if the user was not using the archive before, even more, as there is suddenly an "archive" button.

when to recreate the backup transfer message?

keep it simple to move forward: just re-add the message after a week when it was deleted before.

the if-not-deleted should be good enough to not annoy or surprise users

as said, even in archive, the user has a chance to notice it (usually, user enter archive from time to time - and on re-adding there is even a badge in case the device chat is archived+muted).
an important thing about all that effort is also that the attacker cannot be sure not to get get caught. in another iteration, we can consider to un-archive or so, but i would not do that initially to move forward.

it is all not 100% but "best effort". doing sth. is an improvement, we can always iterate.