Google set to limit Chromium usage of Google APIs

[danielfullmer]

In this blog post [1], Google states that after March 15, 2021, they will be limiting access to various Google APIs that they are now describing as "private" and "only intended for Google's use". The most notable of this apparently includes "Chrome sync" which allows syncing bookmarks / browser history / etc. across multiple browsers logged-in to a given Google account.

Additionally, emails [2] have been sent out to chromium maintainers from other Linux distros stating that users of their chromium-based browser will no longer be able to sign in to their Google accounts. They recommend these chromium-based browsers remove google_default_client_id and google_default_client_secret from the build configuration, or alternatively, set --allow-browser-signin=false at startup.

@edolstra Did we get a similar email as the one shown in [2]?

[1] https://blog.chromium.org/2021/01/limiting-private-api-availability-in.html
[2] https://groups.google.com/a/chromium.org/g/chromium-packagers/c/SG6jnsP4pWM/m/HdoGEO0qCwAJ

CC @primeos @thefloweringash @bendlas

[samueldr]

Further discussion

• https://groups.google.com/a/chromium.org/g/embedder-dev/c/NXm7GIKTNTE/m/ec6ArH9SBwAJ

With actual "answer"

• https://groups.google.com/a/chromium.org/g/embedder-dev/c/NXm7GIKTNTE/m/Qxcew5lfCAAJ

---

edit looks like this was cross-posted across two lists... I was confused by the interface... the content was already in the previous link.

---

Basically, unless Google backtracks, the API key will become unusable for a distro-level deployment. We could continue providing the derivation, with bring-your-own API keys. This would be expensive to build for end-users.

I wonder if the keys are trivially replaceable in the resulting binary though. If they are, we could produce prebuilt unusable binaries, and let users "finish" the build with their own keys.

edit: The archlinux devs state that environment variables can be used for those.

---

Pinging @jonringer and @worldofpeace as we probably will have to apply the same resolution to 20.09.

[samueldr]

Some will poo-poo the thought because "not FLOSS" and similar ideologies, let's think about end-users first here.

---

We're smaller than those distros, but if there's a common front to talk with Google about it, we should participate or approve of such a front.

• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972134
• https://twitter.com/fedora/status/1351631726791983105
• https://lists.archlinux.org/pipermail/arch-dev-public/2021-January/030263.html

This will end-up hurting a part of our end-users.

[jonringer]

Personally, I don't use chrome. Google does, what google wants.

I don't think we have much of a choice, and will just provide what we can. I'm sure users will be aware that the limitation exists regardless of platform.

[danielfullmer]

Yes, we should be able to pass these API keys from the environment instead of baking them in. From https://www.chromium.org/developers/how-tos/api-keys

Providing Keys at Runtime

If you prefer, you can build a Chromium binary (or use a pre-built Chromium binary) without API keys baked in, and instead provide them at runtime. To do so, set the environment variables GOOGLE_API_KEY, GOOGLE_DEFAULT_CLIENT_ID and GOOGLE_DEFAULT_CLIENT_SECRET to your "API key", "Client ID" and "Client secret" values respectively.

(This of course doesn't change anything about our API keys becoming unusable after March 15, 2021)

[danielfullmer]

Quoting a couple lines here from the email thread, since it was initially unclear to me exactly which keys we needed to remove:

The change we announced impacts the ability to "Sign into Chrome" and consequently first party features that depend on being signed into Chrome. This does not include Safe Browsing, which doesn't depend on being signed into Chrome, and is available to third parties for non-commercial use (cf https://developers.google.com/safe-browsing).

and

This is a (partial) list of APIs Chrome depends on, including APIs available to third parties. The changes we announced affect the OAuth 2.0 client id and secret which are used for signing into Chrome, not the API key.

So, we'll just need to remove google_default_client_id and google_default_client_secret, but not google_api_key from our builds.

[primeos]

I drafted a PR: #114977. Feedback is welcome (I lost track of this for a bit).
Thanks for this issue btw :)