I uploaded a set of chromium packages to my repository today. Chromium 88.0.4324.96 sources were released two days ago.
The release notes on the Google Chrome Releases Blog mention 36 security fixes with at least one being tagged as “critical” but the article does not mention that Flash support has been entirely removed from Chromium now.
Adobe’s Flash was already actively being blocked for a long time and you had to consciously enable Flash content on web pages, but after Adobe discontinued Flash on 1st of January 2021 it was only a matter of time before support in web browsers would be removed as well.
Let’s also briefly revisit the topic of my previous post – Google will remove access to Chrome Sync for all community builds of the open source variant of their Chrome browser: Chromium… thereby crippling it as far as I am concerned.
To test my own hypothesis, I built a Chromium 88.0.4324.96 package without using my Google API key. This evening I have been testing that package in private (the package in my repository does include my API key!). As expected, the browser starts up with a warning about missing API key and reduced functionality as a result, pointing you to their support page at https://www.chromium.org/developers/how-tos/api-keys . Also as expected, adding a .conf file in /etc/chromium/ directory in which I export the values for my API key, ID and ‘secret’ passphrase to the shell environment restores the original functionality of the browser. Good to know that my advice actually was correct.
Then I removed my API key/id/secret and substituted them for Google’s own API key/id/secret (which you can find without too much effort among others in the Chromium source code where they are included unmodified since the beginning). I can confirm that the browser still worked correctly – I just had to re-authenticate to Chrome Sync to get the sync process un-paused.
Let’s see where this leads. Arch Linux is challenging Google Chromium team about the legal implications of using the public Google API key. I myself believe that using these keys in a distro package will land us in murky waters and that this is not the way forward. If anything, I will offer a API-key-less Chromium package and encourage users to request their own API key for private use.
Now, go fetch that new chromium package! And give Pat a chance to upload more than 1500 recompiled Slackware-current packages in the meantime.
Fri Jan 22 19:17:44 UTC 2021 Mass rebuild against the new glibc complete. This batch consists only of rebuilds - no new packages or upgrades. Enjoy the fresh binaries!
Good to know that you keep our tools sharp that we use everyday.
Google has a way of luring developers to their product and than suddenly change the terms and arrangements.
Or kill the project completely. I’ve seen it happening with the speech to text module, the youtube-dl api and it will happen with their cloud iot services.
I’m afraid that the now free services of Google Classroom which I use almost every day will go into that direction.
Microsoft Teams could also be an example of abuse of technological lock-in. Yesterday suddenly the input from my microphone was mangled into horrible sound and my students complained that my voice was to harsh to listen to.*
I’ll do a re-install of Teams on Slack-Current and start a thread on Linux Questions.
* the students did not complain however when I put some visual elevator music on between the assigmnents on Tinkercad:
https://youtu.be/nqlxFbv2pyM
I also have Slackware-Current rolling release running flawlesly on a 32 bits Celeron with 1 MB memory. XFCE and even youtube . <=240p which is actually enough to grab the essence of the performance of the Ray Conniff Singers.
Thanks Eric. So far Chromium runs smoothly here.
Yeah, last night’s update was something else. LOL. I had to plug my switch in before it was done. (To be fair, the switch lite has crappy battery life.)
Hi Eric, As long as you’re happy to continue compiling Chromium without your current keys, I think this is the best compromise in allowing users to add their own keys. Thanks
Version 32-bit for Slackware 14.2 works great. Problem with fullscreen mode in Netflix vanished without trace. I thank ye heartily.
As long as the only people complaining to Google are the distro packagers (currently represented by less than the fingers on your hand), Google is not going to take Chromium users seriously.
Which means in 6 weeks there will no longer be a package for Chromium browser in any relevant Linux distro repository if the proposal from Arch Linux is followed by the other distro packagers.
When I switch to Firefox I will setup a private Sync Server for it and write a blog post about it. Sorry 32bit Chromium users, there is no 32bit Chrome.
HI, Eric,
I know that’s not the point here ,
what do you think of brave ?
https://brave.com/
I do not use Brave, it it a commercial project i.e. no different from Google, they just want to earn money with the product. In addition I conclude from checking online Linux distro repositories that it is hard to compile properly and distros use the provided binaries by default.
Unfortunately Brave’s official binary version is 64bit only and the AUR (Arch Linux) page on Brave mentions that the Sync feature does not work for self-compiled binaries. That settles it for me – I could just as well keep using Chromium then.
I see no difference between storing your browser data on a Brave server or on a Google server – both sets of data can be stored encrypted, however for Google you need to explicitly enable a sync passphrase in the preferences.
Brave claims to be faster and more resource-friendly, I did not run benchmarks to validate and Brave have their own benchmark results online and I have no reason to doubt them. Claiming that this is the result of blocking ads by default looks a bit weird. I use Ghostery, a Chromium plugin, which blocks ads/cookies/bad stuff by default very efficiently too.
In the end it is about which ecosystem you want to buy into. I bought into Google’s.
Thanks, Eric 😉
Well, I guess there is a big difference between Brave and Chrome: The business model of Brave is not based on monetising user data. (In fact, their business model is rather unique, and frankly a bit difficult to understand, and it yet has to prove itself in the market).
As to ecosystems, with Brave you can use almost every Chrome add-on or Plug-in. Also, Chrome, Edge and others transmit data to Google or Microsoft unsolicited, and you cannot prevent them from doing so and you have to trust them (or not) that these telemetry is only used for product improvement. AFAIK Brave does not do this. So, among Chrome based browsers, Brave stands out, IMHO.
Thanks Eric for having quickly provided a package at version 88.0.4324.150, bringing a security fix.
Dunno if this is the right place to ask, but I have noticed a different behavior between Chromium and Chrome when using Skype online (web.skype.com): in Chrome the Settings window includes an Audio and Video sub-menu on the left column of the window, but not in Chromium. This is unfortunate for me as I use Skype to communicate remotely with my grand son Lucas (nearly 3.5 yo). Does someone observe the same behavior, or is it just me? I have Chrome at the same version as Chromium: 88.0.4324.150, re-packaged in Slackware format using the latest-chrome script from ruario.
I think that at this point, Skype Web only works fully on Google Chrome and Microsoft Edge. I don’t use Chrome on Linux so I cannot confirm, but even after spoofing the USerAgent to Chrome 88, Audio and Video configuration does not show up in Settings.
Hi Eric
> If anything, I will offer a API-key-less Chromium package and encourage users to request their own API key for private use.
I think this is good. I personally don’t have a Google account and stay away from all things Google so the sync feature is not something I need but I’m sure other users will appreciate being able to add their own keys
It may indeed be about what I decide to do on March 15th. The “distro packagers unite” died silently.
Since the only thing that’s really needed is the API key (for safe browsing) I will change the secret passphrase of my Client ID and stop providing that clientid/secret in my builds. Hopefully that will silence the “missing API key” warning upon startup of Chromium, and it will prevent access to the Google Sync also (plus some other ‘Google private’ features that are not that important).
Hi Eric and thanks for the chromium-ungoogled package. Your arguments in the changelog makes sense and this is probably the way forward.
Personally I don’t care about google synchronisation features (even if I realise that many users find them important). However, after installing I noticed that the ungoogling goes so deep that it also prevents installing extensions from chrome.google.com. Slightly disappointing, but that was easily solved by simply copying the /Default folder from ~/.config/chromium to ~/.config/chromium-ungoogled
Hi KG Hammarlund,
You can add extension to chromium ungoogled.
Please look at this comment: https://alien.slackbook.org/blog/google-muzzles-all-chromium-browsers-on-15-march-2021/#comment-39945
Thanks a lot, gegechris99! The extension solves the issue beautifully (it was necessary to restart chromium-ungoogled for it to take effect, though).