since `account.ceb` might have previously been created by a different application
(for example f-droid and user is on play now) or copied over via the file
manager Conversations might not have permission to write over an existing file.
we include the date so we always get a new file
fixes#105
This switches the SQL based backup format to something JSON based.
The SQL based format has always been prone to SQL injections that, for example, could delete other messages or preexisting accounts in the app. This hasn’t been a concern this far because why would anyone purposely try to restore a faulty backup? However the argument has been made that a user can be socially engineered to restore an exploited backup file.
Before version 2.12.8 a third party app could even trigger the restore process, leaving the backup password entry dialog the only hurdle.
On top of that it has been demonstrated that a backup file can be crafted in a way that puts preexisting credentials into a 'pending' message to an attacker ultimately leading to that information being leaked.
While destorying information has always been deemed an acceptable risk, leaking information is one step too far.
Starting with Conversations 2.12.9 Conversations will no longer be able to read v1 backup files. This means if you are restoring on a new device and you have a v1 backup file you must first install Conversations <= 2.12.8, restore the backup, and then upgrade to Conversations >= 2.12.9.
ceb2txt¹ has support for v2 backup files. Conceivably ceb2txt could be extended to convert between v1 and v2 file formats. (ceb2txt already recreates the database from v1 files; It is relatively straight forward to create v2 files from that database. Pull requests welcome.)
¹: https://github.com/iNPUTmice/ceb2txt/
On registration the app can pass in a 'Messenger' to get a direct response
instead of having to somehow wait for the broadcast receiver to fire.
The app name can be passed as a pending intent which allows the distributor
to validate the sender.
fixes#38
exposing bookmarks like this was a mistake that Conversations 3 will not repeat
in the meantime we rename this to group chats which might be more broadly understood
when the phone is silent only the first ~three tones are played when
attempting to play out the tone over STREAM_VOICE_CALL
it’s unclear exactly why this is the case (in the past we went back and forth
between STREAM_VOICE_CALL and STREAM_MUSIC) exactly to fix issues around silent
mode.
Apparently we failed to test this past three sounds.
This commit changes the stream back to music - but not generally as this was in
the past - but only for when the phone is on silent
For a long time Quicksy had a privacy policy written by myself that explains
in plain English what data we store and how we use it.
https://quicksy.im/#privacy
Google doesn’t like that and prefers that we use some bullshit template that
is extremely vague, doesn’t explain anything and gives us permission to do
basically everything. (At least I think so. I don’t understand the text I
copy pasted)
Apparantly the text in the app is important as well (BARD didn’t explain
that very well when it reviewed our app) therfor we need a static text (not
allow translations)
Furthermore the data safety section on Google Play now claims we store the
users address book even though we don’t actually. But who cares; nobody reads
this and we just do this to make the machine happy. Cool!
the 2.11.0 release removed support for enabling sm:2
unfortunatly sm:2 was still detected as "server supports stream managment"
down the line leading to resend loops.
fixes#4426
