Android zero-tap sign-in restoration: comparing approaches for self-hosted apps

[TimoPtr]

Hi I'm one of the maintainer of the Home Assistant Android app! We’re investigating Google’s upcoming zero-tap sign-in restoration requirement https://support.google.com/googleplay/android-developer/answer/17492799?#zero-tap_sign-in_restoration for Home Assistant, which takes effect in April 2027.

Have you already looked into supporting Restore Credentials in Immich? Since both projects connect to user-hosted servers, we might face similar challenges around RP IDs, domain association, and instances that are only accessible locally or without HTTPS.

We’re tracking our investigation in this Home Assistant discussion. We haven’t settled on an approach yet and would be interested in comparing notes.

This isn’t a bug report or a request for an immediate implementation, just an opportunity to share findings on a requirement that appears to affect both projects.

[danieldietzler]

Hey Timo, thanks for bringing this up! Tagging in @agg23 @shenlong-tanwen. If it's easier we can also move this discussion to our or your Discord though, whatever is preferred. We have a maintainers role on Discord, Joost is already there too

[TimoPtr]

We could have informal discussion on Discord to brainstorm indeed, but I would like to keep things also in Github to be quite public about it. I'm sure other projects will have the same kind of issues.

[danieldietzler]

Yeah that makes sense. We could possibly even both publish technical blog posts about it if we wanted to :) Anyway, I'll leave the specifics to the mobile devs. Thanks!

[agg23]

Thank you for opening the discussion.

My immediate reaction is that this is a bad idea, especially for Immich, which is avoiding GApps dependence at all costs. If done the way Google wants you to do it, you are handing an authed session (maybe deferred, but still authed) to an arbitrary device where the gatekeeper is Google and your PIN, which is not very secure. On top of that, security for both of our projects is more important than the average app, because malicious authed access potentially gains the attacker access to resources on the user's LAN, which likely doesn't have the necessary security posture or resourcing to protect against zero days (which again are more likely to be present in an authed context).

[TimoPtr]

Thanks for joining the discussion :)

I think zero-tap sign-in during device restoration is a nice idea in itself. IMO, it would have been preferable to make it available without requiring Play services.

One detail I didn’t mention in the initial discussion: there is an isCloudBackupEnabled flag. Setting it to false keeps the restore key out of cloud backup and limits restoration to device-to-device transfer. That choice would depend on each project’s requirements, although it doesn’t remove the GMS dependency, and we still need to clarify whether device-to-device-only support meets Google’s requirement.

I don’t think “an arbitrary device” quite reflects the intended flow: the user explicitly starts a restoration onto their new phone. With cloud backup disabled, transferring the restore key requires access to the old phone through the device-to-device migration flow. It isn’t enough to just sign in to a Google account on another device.

That doesn’t eliminate every security concern, but I think it’s an important distinction. I’m not suggesting we dismiss those concerns.

[oddstr13]

I wish there was a proper android backup / transfer solution that didn't rely on Google's cloud, similar to the old Nokia backup app.