Google has announced that it is cutting off access to the Sync and “other Google Exclusive” APIs from all builds except Google Chrome.
[…] They’re not closing a security hole, they’re just requiring that everyone use Chrome.
Or to put it bluntly, they do not want you to access their Google API functionality without using proprietary software (Google Chrome). There is no good reason for Google to do this, other than to force people to use Chrome.
More info (Google’s shitty explanation/justification): https://groups.google.com/a/chromium.org/g/chromium-packagers/c/SG6jnsP4pWM (Mirror)
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.
- ) 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.
- ) 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.
- ) 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:
.
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?
This reminded me of a conclusion I reached in:
“Google wants to do away with third-party cookies and replace it with something worse”
if you’re in Chrome you’ll be signed in to Chrome across all your devices I would assume. wouldn’t it be convenient if Google doesn’t fund mozilla in 2022 and the only safe browsers left are Chrome and Safari.
I need to think about how they might be related
they’re just requiring that everyone use Chrome.
No thank you, Google can fxxk off.
Well, I mostly use Firefox. I just use Falkon (also Blink based) when Firefox fails on some corporate web pages where I work, and Chromium if nothing else helps. I’ve never used the sync features, and nothing special from Chromium, since I prefer to stick with Firefox.
So to me, the lack of chromium might be an issue on some corporate web pages. Perhaps by not being my main browser, I would think users might still find chromium useful without those features.
But now, 6 days after the discussion started on Arch, at least, it seems Arch is close to conclude Arch will drop Chromium, and proposing to get in talk with other major distros to encourage them do the same…
https://lists.archlinux.org/pipermail/arch-dev-public/2021-January/030295.html https://lists.archlinux.org/pipermail/arch-dev-public/2021-January/030296.html https://lists.archlinux.org/pipermail/arch-dev-public/2021-January/030300.html
Looking at how the Arch thread is trending, Chromium most probably will get dropped from Arch. And I’m not sure about other distros, but the legal limbo seems something most distros would like to protect from.
I’d love to see this as an opportunity to increase the Firefox use base, gaining something against the google monopoly long term, but I’m afraid that’s not what will end up happening…
I’d love to see this as an opportunity to increase the Firefox use base
The pessimist in me thinks this will do more to get people to move from Chromium to Chrome, hence why Google is doing it.
Well, playing devils advocate here: how would you feel about this if this was an open-source password manager (which this functionality of Chrome basically is) and the main developer would say: “I don’t feel comfortable with 3rd parties advertising their own modified clients (which I have no way to know if they don’t leak all passwords) as drop in replacements of the official client using the same API”?
Then I would tell them:
- that we all know there’s no warranty on open-source, much less so on some random fork.
- to release the server-side code, so that people can host their own servers.
I think I might say:
“Please go ahead and bump your version up a notch, we’re fine with just continuing to use it as is, and under the existing license and perhaps, at our option, even forking it”
eww! That kinda smells like OOo and MySQL and ownCloud to me ;)
Neither of you address the core issue I raised, which is that unsuspecting users utilizing 3rd party clients could be at risk of having their passwords exposed (from Google’s perspective and again playing devels advocate here).
