Google Photos API changes from March 2025

[nicolabeghin]

Hi, will these changes affect the functionality of this excellent application?

https://developers.google.com/photos/support/updates

thanks
nicola

[gilesknap]

Just got the notification myself and I'm not sure. My first reading says that a read only application like gphotos-sync will be OK but I think we need to look deeper.

[shagr4th]

"You can now only list, search, and retrieve albums and media items that were created by your app."

I hope to be wrong, but to me gphotos-sync will only be able to access photos created/uploaded by... gphotos-sync itself, thus breaking the whole purpose of the app

[gilesknap]

Yeah. If that is true and I have every reason to believe it will be - then I will be archiving the project. (bear in mind that this project is read only for google media and therefore could see nothing!)

[ikwyl6]

@nicolabeghin But there is more info below that part:

**
What you can do:

If your app needs users to select photos or albums from their entire library, use to the new Google Photos Picker API. This provides a secure and user-friendly way for users to grant access to specific content.

If your app relies on accessing the user's entire library, you may need to re-evaluate your app or consider alternative approaches.select photos or albums from their entire library, use to the new Google Photos Picker API. This provides a secure and user-friendly way for users to grant access to specific content.

If your app relies on accessing the user's entire library, you may need to re-evaluate your app or consider alternative approaches.
**

I’m not sure what this really means but I wouldn’t consider it a total dead end.

[michaelsafyan]

I have opened a public Google Photos Library API issue here related to this:

https://issuetracker.google.com/issues/368779600

[gilesknap]

If your app needs users to select photos or albums from their entire library, use to the new Google Photos Picker API. This provides a secure and user-friendly way for users to grant access to specific content.

Thanks - I now recall reading this. The implication is that I need to make a change to the code to use a different permission. Everyone would then have to re-create their secrets using this. It's not going to be that much fun and I imagine there will be lots of headaches.

Google has never wanted us to be able to extract a true backup because that gives you a way to switch to another service. Perhaps it's time to write the Google Takeout library rebuilder (or take a look see if someone else has done this since I last looked)

[michaelsafyan]

I can't speak to the motivations behind this change, but I wouldn't necessarily assume it is because of a desire to prevent legitimate behavior; it could be in response to abusive or privacy-violating behavior by other apps. Note that Google does provide Google Takeout (takeout.google.com) for switching to other services.

Regardless, I'm doubtful that the Picker API will be sufficient here (hence opening up the public issue above) ... the Picker API basically does not give direct access to the user's content. Each time the app wants access to photos, it has to:

• Create a session
• Navigate the user to a given browser URL in Google Photos
• Poll for the user's interactive selection results
• Can access only the subset of media items that the user selected

So, basically, no background syncing capability here.

[gilesknap]

@michaelsafyan thanks for the useful response. I guess this is the end for this project unless your issue is addressed.

The reason for my negative viewpoint is that other issues in the same tracker that have crippled our ability to make a true backup have not been addressed in many years. There were some early responses but they petered out.

But thanks for the support, perhaps having a Google employee on side will help!

[michaelsafyan]

While it is true that I am a Google employee, I am not on the Google Photos team and use gphotos-sync strictly on a personal basis. For that reason, I opened the Google issue tracker with my personal account rather than work account. With respect to this interaction, please consider me as any other GitHub user who depends on and appreciates your project.

[gilesknap]

While it is true that I am a Google employee, I am not on the Google Photos team and use gphotos-sync strictly on a personal basis. For that reason, I opened the Google issue tracker with my personal account rather than work account. With respect to this interaction, please consider me as any other GitHub user who depends on and appreciates your project.

Thanks for clarifying, I shall watch the issue tracker with interest.

[nicolabeghin]

I would suggest commenting in the Google thread to put more pressure - for sure silly but who knows 😅

[mensi]

Personally speaking, it was also a bit of a negative surprise to get this announcement. I think what the Photos team is doing here is similar to what other APIs are doing: Addressing the issue that once you granted an app permissions on your data, it can just arbitrarily access all your data without further consent or involvement on your side until revoked. This is of course great for something like gphotos-sync but more nefarious people can use it to basically get a backdoor to people's data if they manage to trick them into accepting the consent screen or steal/buy OAuth tokens.

We can see this with the Drive API for example too: https://developers.google.com/drive/api/guides/api-specific-auth

Now, what's different with the Drive API is that you can get your app verified to gain access to sensitive scopes. Verification doesn't make sense though for gphotos-sync since everyone sets up their own OAuth Client ID on their own project. The good news there though is that this is not required for personal apps: https://support.google.com/cloud/answer/13464323, so the current setup could just continue working.

--> I think it doesn't make sense to be angry at the Photos team or fight against this change but it would be better to follow the Drive API model with sensitive scopes and unverified apps for personal use.

Another aspect that I could imagine (I did not try to gain insider knowledge on this) is that it's hard for the Photos team to put any numbers on this as I suspect they currently can't tell how many of the currently existing OAuth Client IDs use gphotos-sync vs. which ones are apps that are just fine with the Picker API. So I think it might make sense to ensure gphotos-sync sets a custom User-Agent. That way, the Photos team can probably get usage stats from API logs.

[gilesknap]

The good news there though is that this is not required for personal apps: https://support.google.com/cloud/answer/13464323, so the current setup could just continue working.

I'd like to think you are right. But I'm not convinced. Personal apps approach is what we are using, yes. But we still need to pick a scope for the app secret and that is what is changing.

[mensi]

Oh sorry for the confusion, that's not what I meant. With the current planned changes, gphotos-sync will stop working. But if the Photos team just made the readonly scope a sensitive one that requires app verification, it would continue working. Everyone else who wants to access other people's data via OAuth on a public app would then have to get their app verified.

[ikwyl6]

Getting ‘verified’ - isn’t this what most big corporate APIs do anyways? Are we all saying the same thing?

[gilesknap]

Oh sorry for the confusion, that's not what I meant. With the current planned changes, gphotos-sync will stop working. But if the Photos team just made the readonly scope a sensitive one that requires app verification, it would continue working. Everyone else who wants to access other people's data via OAuth on a public app would then have to get their app verified.

OK I take your point, thanks for clarifying.

[gilesknap]

The Google Photos Developer's reply on https://issuetracker.google.com/issues/368779600
reads:

That you for the report and describing your use case.

Our current suggestion is to use Google Takeout to backup your Photos library.

We understand the need for an incremental backup solution and are looking into that. If we are able to offer this in the future, then I'll leave a comment on this issue.

I think this is a pretty strong indicator of end of life for gphotos-sync.

I'm going to be archiving the project and placing an explanation on the README. Happy to revert that at some point in the future if there is ever any movement on the API.

Will I still use Google Photos? Hell, yes.

Thus, I've been looking for a good Google Photos Takeout rebuilder that can create you a plain folder hierarchy with intact metadata (so like gphotos-sync does except that in this case GPS info will be available). I've not found one that looks to be mature and widely used. So maybe that will be my next personal project. If anyone knows of a good one, please post here.

[gilesknap]

Final post in this repo. Goodbye and thanks everyone.

(until there is movement on https://issuetracker.google.com/issues/368779600 that is!)