From Newsgroup: comp.mobile.android

PSA: Fossify Simple Mobile Tools FOSS replacement apps
<https://www.fossify.org/apps/>

Apparently these are released SimpleMobileTools replacement apps:
<https://github.com/FossifyOrg/Calendar>
<https://github.com/FossifyOrg/Contacts>
<https://github.com/FossifyOrg/File-Manager>
<https://github.com/FossifyOrg/Gallery>
<https://github.com/FossifyOrg/Messages>
<https://github.com/FossifyOrg/Phone>

Here are the Fossify APKs on F-Droid for those which are fully released:
<https://f-droid.org/repo/org.fossify.calendar_20.apk>
Name: org.fossify.calendar_20.apk
Size: 7774487 bytes (7592 KiB)
SHA256: 2ACBD47FA2ABC6DD4846E406ED2FD60C5C01B8613158D10E012135923EE24894

<https://f-droid.org/repo/org.fossify.contacts_13.apk>
Name: org.fossify.contacts_13.apk
Size: 8602985 bytes (8401 KiB)
SHA256: 6A89BE96B5EC39F5E2B11BD61DC7031F4B88261B324AB13AF5743FBC62F0CDDB

<https://f-droid.org/repo/org.fossify.filemanager_13.apk>
Name: org.fossify.filemanager_13.apk
Size: 9982225 bytes (9748 KiB)
SHA256: 9E97D2FAF55FB2702386C3DC51E38A6B073781016B125701D3AB668419A70008

<https://f-droid.org/repo/org.fossify.gallery_28.apk>
Name: org.fossify.gallery_28.apk
Size: 38606538 bytes (36 MiB)
SHA256: AE7E699599E81F70E2B82626BB1DFA883FE096CD938387133E123C116E5641D9

<https://f-droid.org/repo/org.fossify.messages_20.apk>
Name: org.fossify.messages_20.apk
Size: 8276646 bytes (8082 KiB)
SHA256: 9D408488F2400D42F8F25A2663C6D7E7A1E7EC5B9A755DE23486B04A46EB66F3

<https://f-droid.org/repo/org.fossify.phone_22.apk>
Name: org.fossify.phone_22.apk
Size: 9165050 bytes (8950 KiB)
SHA256: D1AD08467034E5138A6E68F03B6E150F0BB010DFCBF490FF3D2BD4822B755728

Apparently these are released only as beta apps:
<https://search.f-droid.org/?q=fossify&lang=en
<https://f-droid.org/en/packages/org.fossify.paint/>
<https://f-droid.org/en/packages/org.fossify.notes/>
<https://f-droid.org/en/packages/org.fossify.home/>
<https://f-droid.org/en/packages/org.fossify.math/>
<https://f-droid.org/en/packages/org.fossify.keyboard/>
<https://f-droid.org/en/packages/org.fossify.camera/>
<https://f-droid.org/en/packages/org.fossify.clock/>
<https://f-droid.org/en/packages/org.fossify.voicerecorder/>
<https://f-droid.org/en/packages/org.fossify.musicplayer/>

Any others?
--
On Usenet, good people help others out of their kindness & generosity.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Maria Sophia wrote:

<https://github.com/FossifyOrg/Calendar>
<https://github.com/FossifyOrg/Contacts>
<https://github.com/FossifyOrg/Messages>
<https://github.com/FossifyOrg/Phone>

True privacy isn't a better lock; it's not giving them a door to open.

Some people don't realize that on a standard smartphone, their contacts are stored in a centralized, unprotected database. If they give a social media
app or a utility permission to see their contacts, it's not just looking,
it's often vacuuming up their mother's home address, their boss's private
cell number and those notes they kept about their gate codes for DoorDash.

Even "responsible" companies, who do hashing, can't protect your contacts because hashing works great for random things, but dialing is not random.

The short string of phone numbers have low entropy.

Contact hashing for 'responsible' sites like WA has to be deterministic. There's no salting involved (AFAIK).

Even if there were a 'secret salt', it could easily be figured out.

A company can pre-calculate the rainbow table for every single possible
phone number but the social graph is the real prize hidden in contacts.

Given privacy is impossible with anything in the contacts sqlite database,
note that the combination of 4 tools below are designed for privacy.

Fossify:
a. contacts
b. messages
c. phone
d. calendar

The contacts are stored locally and the dialer works with them so you can
still see who is calling, and the messages too, as is your calendar.

They don't even have internet permissions to see, keep or sell your data.
--
Only one in a million people truly understand heavily marketed products.
That's because very few people have the background to question the myths.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Maria Sophia wrote:

I'm simply starting my quest with this thread trying to find those apps.

While researching iOS contacts-privacy apps, I found this for Android:
<https://github.com/seenware/savelon-app>
Savelon: Private Contacts
Savelon is a privacy-first contacts app where users can store
confidential contacts safely in a separate encrypted vault.
The app is fully offline: there are no clouds, no backend servers,
and no remote sync. Contact data is encrypted on device and unreadable
to other apps. This project is open source.

Savelon FOSS Privacy-first contacts app
a. 256-bit on-device encryption
b. No cloud, no servers, open source
c. Completely separate contact store
d. Password-protected backups
e. Designed specifically for private contacts
<https://savelon.com/>

Android:
<https://play.google.com/store/apps/details?id=com.seenware.encryptedcontacts> iOS:
<https://apps.apple.com/de/app/savelon-private-contacts/id6755902938>

Below is the article where I first unearthed Savelon, from the iOS ngs.
=====================================================================
The point of this thread is to find a way for better iOS contacts privacy.

The very fact the user has no idea which contact permissions are being
asked for is a problem. And that messages can't be made private is too.

Whether you comprehend it or not, iOS does not granularize permissions by field so the prompt simply does not enumerate what the app will access.

I've known this for years.
But I had never tried to solve this privacy flaw until recently.

It's widely known to people who understand privacy that the only real
solution is keeping contacts out of the system address book entirely,

To solve this privacy issue, I dug deeper to find that privacy-focused contacts apps do exist on iOS, and several of them explicitly solve the
some of the "separate, encrypted, not visible to other apps" problems.

Given the fact that...
a. iOS cannot granularize Contacts permissions by field.
b. iOS cannot show which fields an app will access.
c. iOS cannot granularize Contacts permissions by field.
d. iOS cannot show which fields an app will access.
e. iOS cannot replace the system dialer with a privacy-aware one.

So the only viable path is keeping sensitive contacts out of the system database entirely, which is the goal that I seek to solve in this thread.

The strongest options today appear to be Savelon, Stealth Contacts and GhostContact, all of which create independently private contact stores that are not exposed through the system Contacts framework.

Savelon, for example, (which also works on Android & macOS) has
a. 256-bit on-device encryption
b. No cloud, no servers, open source
c. Completely separate contact store
d. Password-protected backups
e. Designed specifically for private contacts
<https://savelon.com/>

Perhaps better, Stealth Contacts, which allows seeing the caller's name without putting them in the system Contacts database, has a
a. Private vault with Face ID / passcode
b. Caller ID works even though contacts are not in system Contacts
c. Invisible to all other apps
d. Never appears in Spotlight, call history, or search
e. Optional iCloud sync that does not touch iCloud Contacts
<https://apps.apple.com/us/app/stealth-contacts/id6760033667>

Similar to Stealth Contacts but simpler is Ghost Contacts which also
shows caller ID using the CXCallDirectoryProvider, which
a. Creates a second, private contact list
b. Caller ID works without adding to system Contacts
c. Data stored only on device
d. No access by other apps

<https://apps.apple.com/us/app/ghostcontact-private-contacts/id6742730895>

Even after enabling the CallKit extension in
Settings > Phone > Call Blocking & Identification.
there are still unplugged iOS privacy holes in call logs and in messages.

The call log leak:
Even if a contact is in a "Stealth" vault, when the call ends, the phone
number will still appear in our native Phone app's "Recents" tab.
It just won't have a name attached to it. If an app has "Call Log" access
it can see the metadata of the call, just not the identity of the caller.

The messages leak:
Even if a contact lives entirely inside a Stealth-style vault, iOS Messages still exposes the phone number because Messages only consults the system database, not any private contact store. Incoming texts create a permanent thread tied to the raw number, which is then indexed by Spotlight,
suggested by Siri, shown in the share sheet, and stored in the Messages database (and in iCloud if syncing is enabled). The identity stays hidden,
but the number, timestamps, and conversation metadata remain visible to the
OS and to any app with notification or message-related access.

For example, to see "John Doe" in our text messages, we are forced to add
him to the system Contacts. Once we do that, the privacy "wall" is broken.
.
Every other app with contact permission (Facebook, TikTok, etc.)
can now see that contact, and specifically, if they get the Notes
field, if you put a gate code in that field, those third-party
apps can now steal that code (if they request that field).

On iOS, we can have a "Private Dialer" experience, but we cannot
currently have a "Private Texter" experience while using the native
Messages app. To keep our identity safe in texts, we have to use an
entirely different app like Signal, which maintains its own internal
(and private) contact list.
--
Of a million things people should know about privacy, most know 3. .
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Maria Sophia, 2026-05-03 22:16:

Arno Welzel wrote:

Some people don't realize that on a standard smartphone, their contacts are >>> stored in a centralized, unprotected database. If they give a social media >>

Only, if you use a Google contacts/calendar account.

Hi Arno,

It's excellent to discuss where our smartphone stores our contacts and calendar data and what a centralized unprotected database-i really means.

It's fundamentally about data sovereignty, which is the idea of who
actually owns and has access to our personal information.

If you use only a
local addressbook or calendar, then the data stays on the device even
when using the official Google apps.

Yes. But. No. Sort of...

I don't have a Google Account set up on my phone, as you're well aware.
But the contacts-privacy problem doesn't change since there are many
apps with full-read-access to the default sqlite contacts database.

We have a thread on that where almost nobody knows that list, mostly
because you cant' get the full list anyway, without adb queries, and even then, you have to realize that the list is ephemeral even to adb lookups.

So you are correct you can avoid syncing to Google, but it doesn't change
the app-permission issue that most people have no clue exists (likely
because they believe the GUI but the GUI does not tell the whole truth).

This is why apps like Facebook, WhatsApp, TikTok, etc. ask for contacts.
It's a gold mine in terms of their ability to sell your social graph.

Of course your data is then not
backed up as well and you need to take care oft this - for example by
using your own Nextcloud server and DAVx5 to synchronize
contacts/calendar.

I saw your post about <https://www.davx5.com> and I agree with it.
My problem is that Windows just does not do servers all that well.
But for Linux owners, it's a wonderful way to sync things up nicely.

Besides, good contacts apps (like OpenContacts) can be set to automatically back up your contacts to a vcf file on your phone, which is potentially copied via rsync-like mechanisms to our PC (although I have yet to set that up).

I should probably set up a Raspberry Pi as my linux server, huh?

It's your decision, how you backup and use your data.

I prefer having my contacts and calendar accessible on my computer as
well and not just on my smartphone.

[...]

Me?
I never pay for anything for the obvious reason that paying even one cent destroys privacy; but I do understand for most people it's a good deal.

How does "paying" destroy privacy? Did you get your phone, your internet
access and computers for free as a gift?
--
Arno Welzel
https://arnowelzel.de
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Arno Welzel <usenet@arnowelzel.de> wrote:

How does "paying" destroy privacy? Did you get your phone, your internet access and computers for free as a gift?

The problem is that it requires a payment method, which requires details
like real-name, real-address, email, etc. Additionally those are often tied
to an 'account'.

In the real world you can buy with cash, avoiding the first problem, and if
you pay with a card in a shop, the merchant gets some details (name and card number) but they don't get the email, phone number, address or the ability
to cross-reference other purchases (especially if made on a different card). You can also use prepaid cards or gift cards if you wish to give fewer
details. Even if you purchase online, buying a phone/computer/etc from a reseller (or used) means the original OEM doesn't get your details.

Internet access does typically need your address, but there's a limit to how much utility companies can invade your privacy (if everything is HTTPS they can't snoop on your traffic).

On Android, purchases are tied to a Google account which means your other activities on the phone become tied to that Google account too. You can't
just use the account to purchase the app. (I've not tried it, but I suspect paid apps stop working if the account is removed?)

Some apps have their own ways to buy them that aren't tied to Google, but
most don't.

Theo
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Theo, 2026-05-04 12:56:

Arno Welzel <usenet@arnowelzel.de> wrote:

How does "paying" destroy privacy? Did you get your phone, your internet
access and computers for free as a gift?

The problem is that it requires a payment method, which requires details
like real-name, real-address, email, etc. Additionally those are often tied to an 'account'.

Which is the case for internet access as well. And I doubt, that "Maria
Sophia" does not have internet access ;-).

[...]

Internet access does typically need your address, but there's a limit to how much utility companies can invade your privacy (if everything is HTTPS they can't snoop on your traffic).

If you don't trust any company at all, you also must not use hardware
you did not design and built yourself.

On Android, purchases are tied to a Google account which means your other activities on the phone become tied to that Google account too. You can't just use the account to purchase the app. (I've not tried it, but I suspect paid apps stop working if the account is removed?)

It's possible to create a Google account without personal data which
leads to your identity and purchase gift cards in shops using cash which
can be used to purchase stuff on Google Pay.
--
Arno Welzel
https://arnowelzel.de
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Theo wrote:

Arno Welzel <usenet@arnowelzel.de> wrote:

How does "paying" destroy privacy? Did you get your phone, your internet
access and computers for free as a gift?

The problem is that it requires a payment method, which requires details
like real-name, real-address, email, etc. Additionally those are often tied to an 'account'.

Bingo.

Theo answered the question better than I could possibly answer it myself.

Let's not forget that the microsecond that we establish an "account" on
your device, our privacy is toast.

On a phone, there is no single thing you could possibly do for privacy that beats NOT putting an account on the phone (whether that's iOS or Android).

Unless we're super clever with bitcoin (which I'm not), then the simple
privacy rule is never pay a single cent for anything on that phone.

I can't stress this point more than to say that of the million things we
need to know about privacy, not having an account is the first of them.
--
Nobody who complains about privacy has a case if they set up an account.
--- Synchronet 3.21f-Linux NewsLink 1.2