That’s not actually true. <ahem… cough, cough!> The one reason they are citing for doing this is to “improve user data security…”

“As part of Google’s efforts to improve user data security, we are removing access from Chromium and Chromium OS derivatives that used google_default_client_id and google_default_client_secret on their build configuration to Google-exclusive APIs starting on March 15, 2021”

Yah, if you can believe that. Yo Google, You no can haz #Cheezburgerz! :hamburger:

What servicess, if any, are going to be affected in Kiwi Vivaldi, and the Brave browsers? For the most part, they’re using their own services for syncing and the like.

Well one thing is certain, not doing anything about it (Like the simple workaround below) will mean death to the 32 bit Chromim based platforms, for which there is a huge user base. So… Good news for Firefox, yes?

As AlienB0b said, he’s contemplating just including documentation in the packaging about, …the public availability of Google’s own API keys, plus the fact that you just have to export them in your shell environment as values for the GOOGLE_API_KEY, GOOGLE_DEFAULT_CLIENT_ID and GOOGLE_DEFAULT_CLIENT_SECRET variables before you start Chromium.

Easy peasy.

I think that this would be a good time to mention that complicating you life with differnt sync engines specific to each different browser you use is, well, it’s another complication! To simplify things, I see three attractive solutions, two of which I incorporate into my daily workflow.

1. ) Self-hosted BitWarden Too much hassle for me, although I certainly believe in self-hosting any services that I can for myself and my customers. Does this mean that using their free service compromises your security? Not at all, there’s no reason to think that your data would be any less secure if you used their free tier subscription

There’s also no reason to expect that you won’t need more for your service in the future, at which point you’ll have to pay, or that your free service will sunset and you’ll have to pay a subscription fee for your basic service. That seems to be what inevitably occurs, and it just happened with Dockerhub, but it’s not necessarily a bad thing, as long as you’re fine with paying for what you’re being provided.

2. ) Keepass (.kdbx) Very simple. And there’s a lot of different choices to make based on your own preferences but here are mine:

• KeepassXC - cross-platform desktop Keepass client. Looks good, tastes great, and even smells nice. This comes with a companion browser plugin that works in both Firefox and chromium based browsers like Vivaldi and Brave. I sync mine to a private Git repo on one of my Gitea servers. Keybase private encrypted git repos are also quite functional and convenient.

• KeepassDX - Android Keepass client. Also yummy. Same thing, I sync it to a private git repo.

3. ) Pass This could really require a whole article in and of itself, which is odd, considering just how dang simple it really is but support and the client base available is rather large. Numerous choices for cross platorm clients set up with or without self-syncing to private git repos, etc. but a couple of lesser known Android utilities should be mentioned here which are the combination of two products available at F-Droid:

• Password Store
• OpenKeychain

In fact, All of the above are available at F-Droid (You can get G-Droid there and use that too), except for Bitwarden, which is one of the main reasons I wouldn’t use that product unless I opted for a self-hosted version of it - but why, when all you need is a little db file that you can sync with whatever you already use to sync your files anyway?

I hope that helps! :)

:sailboat:

.