New phone "stole" old phone's ID?

MarcMush · June 5, 2025, 8:42pm

My old phone tried to swim so is currently unavailable. I install syncthing-fork on my new phone. Different ID (of course), similar config but slightly different. After a few days, syncthing on my new phone asks if I want to overwrite a folder that was only synced with my old phone… when trying to understand why, I realise that my new phone appears as my old phone on my other syncthing devices. Sure enough, I check my new phone and it has the old phone’s ID, with the old phone’s config

how is that possible?

could google/android have tried to be smart and get me the same config? (same google account) both where installed with f-droid

both are Redmi phones, but I didn’t connect to the MI account/cloud so it would be very strange

I didn’t sync my syncthing config

It’s not a big issue for me, I’ll fix it, but it is a very confusing and could be very problematic in some cases

Catfriend1 · June 5, 2025, 9:22pm

I would also think that when reading what happened. Was the Google One / Backup to Google Drive feature enabled on your phone that died? Syncthing itself does not store your device ID (technically spoken private key stuff) anywhere outside of your phone.

I’ve never got to the point to test this scenario as I’m not using Google Drive backup at all.

MarcMush · June 5, 2025, 9:52pm

Yes, that’s my best guess too. But I’m confused, it would be litterally the only app google was able to restore, everything else I had to reconfigure myself

Also why only after 5 days

Could there be a way for syncthing to detect that and at least notify the user?

Catfriend1 · June 5, 2025, 10:17pm

If we would know more about the mechanism behind that google restore, we could handle that.

Do they ask you as the user if you want to restore explicitly? Could you select which phone backup to restore from gdrive in the process? I assume, a user can backup multiple devices to their service.

Just an idea for first aid here: we could exempt the crt/pem files from gdrive backup and then Syncthing should generate a new device ID because those files are regenerated. Question is, how do we get rid of the “old” device ID then which is still present in config.xml and shows a device entry in the UI?

MarcMush · June 6, 2025, 7:16am

yes, they probably asked if I wanted to sync back from my old phone, and I approved without paying much attention

Catfriend1 · June 6, 2025, 8:09am

I guess there might also be another problem: if it was installed by fdroid, “google restore” might not have had the app installer package (apk) available until you manually grabbed it?!

Reasons, decision and change PR:

github.com/Catfriend1/syncthing-android

Disable gdrive backup feature / allowBackup=false (fixes #1469) (fixes #1228)

main ← f0

opened 09:48AM - 06 Jun 25 UTC

Catfriend1

+12 -22

This does not work okay, regarding many things, e.g.: - If gdrive's mechanism r…estores the app prefs and SyncthingNative's config, users are unaware if they need to generate a new device id (because of a new phone where they meant to "copy" when first using it what they already had to get a duplicate of the app env) or if the old phone was dead so they "move" to that system - thus requiring the same Syncthing config as before. - The app currently does not detect when gdrive's mechanism restored the config. - gdrive doesn't restore the files from internal storage and that's a key feature and requirement to use the backed up config. If files aren't there that is 50% useless (if not looking at receiveOnly scenarios which could fill up again) - Users may have installed the app from F-Droid. Gdrive's mechanism can't bring back the app from there. We had a [user report](https://forum.syncthing.net/t/new-phone-stole-old-phones-id/24448/6) that this leads to weird behaviour if he later installs the app from F-Droid and then gdrive's restore kicks in and overwrites the (fresh) config. Plus: - Syncthing-Fork app now provides a better export/import feature on its own, integrated within the app. Because it's also able to encrypt those config exports, users can safely add them to their synced folders which eliminates the need to use the gdrive ecosystem for that. As users are already part of the Syncthing world, why not use it here, too. 🙂 This led me to the decision to turn off gdrive backup API support by setting "allowBackup=false" in the app manifest.

Thank you for your feedback on this . I’ve also re-read past GitHub issues on the matter and came to the conclusion that the (recently) improved export/import feature will suffice and integrates better with the Syncthing ecosystem (user’s don’t need gdrive if they can sync the config in an encrypted archive).