[Bug] aTox cannot be included in backup about atox HOT 10 CLOSED

Isn't it a disrespect towards the user?
The program shouldn't behave like Crapdows 10-11 or Apple and decide for the user / pretent to be smarter than the user.
It is up to the user to decide how it operates on his/her device, and if the user is making a system backup, no program should stick the sticks in the wheels and be present in "programs that do not allow backup".

This app is a lot about security, not about doing crazy cowboy hat stuff. As the user expects a by default secure product, doing this was basically the user's expectation.

The 'feature' "programs that do not allow backup" as a whole should be removed completely from AOSP.

I think, you haven't quite fully understood the issue really, yet. The feature was disabled in 2019 to disable an insecure way of having the app backed up automatically by a third party, which is not even under the user's control. So, keeping the feature enabled would go against parts of this app's purpose & we would have more people complaining about it being enabled rather than one user complaining about not allowing more insecurity by default.

That is my point.

from atox.

Greetings 👋🏻

Please, check out the reason, why this functionality was originally explicitly disabled.

b2845d4

from atox.

It would be interesting to support SeedVault though, and I have been thinking about enabling backup if your phone can do client-side encryption: #439

from atox.

Greetings 👋🏻

Please, check out the reason, why this functionality was originally explicitly disabled.

b2845d4

Greetings :-)
Do you mean the text "Disable backing everything up to the Google cloud"?
This is not related, Google cloud is the last thing I would use.
The issue is about local backup managers, in particular Seedvault.

It would be interesting to support SeedVault though, and I have been thinking about enabling backup if your phone can do client-side encryption: #439

Doesn't aTox encrypt the user profile already? According to what I know, user files should be encrypted on the disk by the program...
Which means that both unencrypted and encrypted backups are good to go

Seedvault is encrypted backup, yes :-)

from atox.

Wait, so it is not a bug, but was done intentionally?

Isn't it a disrespect towards the user?
The program shouldn't behave like Crapdows 10-11 or Apple and decide for the user / pretent to be smarter than the user.
It is up to the user to decide how it operates on his/her device, and if the user is making a system backup, no program should stick the sticks in the wheels and be present in "programs that do not allow backup".

The 'feature' "programs that do not allow backup" as a whole should be removed completely from AOSP.

That is my point

from atox.

I completely disagree, and lean towards the freedom way. The user is the one who should choose and control.
I'm very sad that I cannot backup everything I want and that in some programs someone else decides that for me, and find it to be quite disrespectul

But in any case, Seedvault is not "an insecure way of having the app backed up", however I still cannot backup.

"This app is a lot about security, not about doing crazy cowboy hat stuff":
Does it encrypt the user profile by itself, like qTox does?
If yes, then there's no crazy cowboy hat stuff and anti-security, right? :-)
(and again Seedvault is encrypted, so still no anti-security)

from atox.

I completely disagree, and lean towards the freedom way.

Okay, then perhaps you picked the wrong app. Security is a lot about restriction. If you want pure freedom, then you need an app that focuses on freedom, rather than security.

The user is the one who should choose and control.

Enabling Google breaking your system automatically means actually less control for the user.

But in any case, Seedvault is not "an insecure way of having the app backed up", however I still cannot backup.

(and again Seedvault is encrypted, so still no anti-security)

The feature was disabled because of Google Backups. It just happens, that Seedvault uses the same mechanism. The arguments about security still stand & are not refuted in the slightest way.

If yes, then there's no crazy cowboy hat stuff and anti-security, right? :-)

You repeatedly said you "lean towards the freedom way" and "[t]he user is the one who should choose and control". This includes & implies crazy cowboy hat stuff or else it wouldn't be "free" in the way you suggest, either way.

Anyway, I feel like we are going in circles now. I gave you several chances to make your point & you have engaged in every chance of doing so, successfully. We have gotten your point & everyone is able to read it here.

For the sake of issue organisation, I am closing this issue in favour of #439, as this is more or less a call to action regarding this original issue.

Thank you for reminding us of #439! 🙂

from atox.

Have checked the issue #439,
Its name says "enabling Android's backup for app files",
does it include the built-in Seedvault?

from atox.

Okay, then perhaps you picked the wrong app. Security is a lot about restriction

The user must have a choice, and the final choice is up to the user.

I can do whatever I want with my qTox files, and of course backup them. "Security is a lot about restriction" turns to not be applicable.
And it is very weird that I cannot do this with aTox, because a developer decided this for me, instead letting the user decide.

"What the application developer wants should be considered as a friendly request. The user should be presented with the appropriate warnings. However, these are user devices. It should be the user who should have ultimate control over what the device should do and what not"

"Users should have the right to extract all information which was created on, stored on their devices. Even if they have to click through scary warnings. Even if in secure. Perhaps it's just for testing purposes, auditing applications"

from atox.

You apparently still didn't do any research about this topic or you simply stubbornly do not want to understand it. Which is why I mainly explain this to potential future readers for clarity purposes, as I doubt you will get it suddenly now.

There is a general backup feature. It is an utterly generic on/off switch for backups in general.

So, if this switch is set to on, it means that backups in general are permitted.

This includes automatic backups via Google Cloud.

Therefore, if the feature would've been allowed in 2019, when the app had way less features, than now, then we would introduce a security risk by letting Google Cloud casually back up this up into its cloud.
Which in turn also means, the user would have less choice, if the feature was enabled, because of Google Cloud Backups.

Any normal security conscious user is not relying on any Google, Microsoft or whatever cloud, especially if we are talking about communications accomplished in a secure communications tool.
Just saying "it's encrypted, duh", does not solve the problem, because we have not (yet) proven, that the encryption is absolutely perfect. Every software has bugs (except a handful proven ones on the entire world). Even secure software, like SSL & encryption implementations.

Secondly, Google & such companies have so much money, they could literally simply monetarily afford a huge password cracking computer cluster. You obviously do not even try to imagine the amount of money such companies can just randomly throw at shit like that.

Thirdly, those are American companies, so nobody is going to protect you. Non-USA citizens are basically free game. They can be digitally raped in the USA & that is officially allowed & permitted by law. For USA citizens, there are more laws & rights, but they still can get digitally raped with the proper hunch. For example, if you buy a generic cooking pot, which theoretically in some circumstances could be used to stir up some bomb material, your home can be SWATed within hours after your purchase. This case already happened.

Concluding from that, if you have a problem, go to the AOSP project & complain, that there is only a generic on/off switch for this backup functionality. If we would be able to provide a way, to only allow Seedvault to backup the app's content, while #439 is still in progress, we could literally fix it right now.
However, the Android Open Source Project does not provide this feature.

With security, it's simple: if in doubt or something's not waterproof yet, then don't allow it.

I can do whatever I want with my qTox files, and of course backup them. "Security is a lot about restriction" turns to not be applicable.
And it is very weird that I cannot do this with aTox, because a developer decided this for me, instead letting the user decide.

Again, you are carelessly misrepresenting facts. This sounds like the developer just randomly, to annoy users, disabled a feature, when in fact it was due to security concerns in 2019, when the app was much less mature & had much less features. If you are going to be annoying about it, then please stay with the facts, at least.

"What the application developer wants should be considered as a friendly request. The user should be presented with the appropriate warnings. However, these are user devices. It should be the user who should have ultimate control over what the device should do and what not"

"Users should have the right to extract all information which was created on, stored on their devices. Even if they have to click through scary warnings. Even if in secure. Perhaps it's just for testing purposes, auditing applications"

Absolutely correct. Which is why we need more support & help from the community, to improve this app & let it grow!

I expect your pull request fixing #439. Thank you very much. 👍🏻

from atox.