… Aka the future of Chromium based (embedded) browsers
On March 15th 2021, Google is going to block non-Google chromium-based browsers from accessing certain “private Google Chrome web services” by unilaterally revoking agreements made with 3rd parties in the past.
Meaning, every Chromium based product not officially distributed by Google will be limited to the use of only a few public Google Chrome web services.
The most important service that remains open is “safe browsing”. The safe browsing feature identifies unsafe websites across the Internet and notifies browser users about the potential harm such websites can cause.
The most prominent feature which will be blocked after March 15th is the “Chrome Sync”. This Chrome Sync capability in Chromium based browsers allows you to login to Google’s Sync cloud servers and save your passwords, browsing history and bookmarks/favorites to your personal encrypted cloud vault inside Google’s infrastructure.
Extremely convenient for people who access the Internet using multiple devices (like me: Chrome on a few Windows desktops, Chromium on several Slackware desktops and laptop and Chrome Mobile on my Android smartphone) and who want a unified user experience in Chrome/chromium across all these platforms.
In order to boost the development of Chromium-based (embedded) browser products, Google made deals with 3rd parties as far back as 2013 (from what I could find) and spiced the API keys of these 3rd parties with access to crucial Google Webservices providing features that would draw users to these products.
If you offer a product that calls upon Google’s Web Services there is a monetary cost involved once the number of your users’ connections exceeds the monthly upper limit for free usage. So on top of providing us access to these Google APIs (in the case of Open Source Distro Chromium packagers) the Chromium team also substantially increased the non-billed monthly API consumption by the users of our distros’ Chromium browsers. This helped to prevent us poor distro packagers from being billed for Cloud API usage in case our browser packages gained popularity.
And then, early 2021, some Google white-collar people decided they had enough of these freeloaders.
When Google dropped the bomb on us – on the distro packagers in particular – a fierce discussion started in two Google Groups (posts in one group are mostly duplicated into the other group): Chromium Packagers and Chromium Embedders. It’s like talking to corporate drones – every question we asked is replied to with the same bogus standard texts. Arrogance to the max!
Even more poignant is a parallel discussion in Chromium Embedders, where some large electronics manufacturers discovered that some of their commercial products are similarly affected. Consumer Electronic products that ship with browser-based embedded applications like Smart TV’s often use CEF (Chromium Embedded Framework) and Google will block access for CEF products to their “private” Chrome APIs just like it’s going to do with distro browsers – they are all based on the same Chromium source code and are all non-Google products.
If you wonder what happened to the Google motto “Don’t be Evil” – in 2018 that phrase was removed from the employee Code of Conduct. And indeed, looking at the discussions in aforementioned topics the top brass feels completely ‘senang‘ throwing us distro packagers under the bus while at the same time chastising us because apparently we do not adhere to their Code of Conduct.
Enough of all the bullshit – let’s look into the future. What can we do as Linux users, and what will I do as a distro packager.
Let me be clear: I do not want to take choices away from you. You can keep using Chromium, you can switch to Chrome, you can investigate whether Vivaldi or Brave (two chromium-based browsers with their own Google-free implementation of cloud sync) are better options for you.
I will however have to deal with the fact that I can no longer build a Chromium package that offers a synchronization of your private browser data out of the box. So what I will discuss in the remainder of this article are possibilities.
Chromium packages for Slackware are here to stay
… but I will remove my personal Google ID and corresponding secret from my chromium package. They will have been invalidated anyway on March 15 and are therefore useless. What I will leave in, is my “Slackware Chromium API Key” which keeps the “safe browsing” functionality alive if you use my browser.
I want to state here that from now on, I also explicitly forbid others / distros to re-use and re-package my binaries in order to make them part of their own Linux Distribution: thinking of Slacko Puppy, Porteus, Slint and others. If needed I will use “cease & desist” messages if people refuse to comply. I am not going to pay Google for the use of my binaries in distros that I do not control. The use of my API key is automatic if you run my Chromium binaries, and it involves a monthly cost if Google’s Could APIs get called too much. I already had to negotiate several times with the Chromium people to avoid getting billed when their policies changed. So get your own API key and compile your own version of the browser please.
You can request your own APIkey/ID/string in case you did not realize that! You’ll get capped access to Google API services, good for a single person but still without access to Cloud Sync. If you introduce yourself to the Chromium team as a distro packager, they may help you with increasing your browser’s un-billed API usage.
There’s a public discussion in the Google Group threads that I referred to above, about your personal use of the official Google API keys. This could offer a way out of the blockade and would allow you to keep using Chrome Sync in a Chromium browser even after the distro packagers’ API keys have been invalidated. These official Chrome API key/ID/secret strings are contained as clear-text strings in the public chromium source code for a long time already!
While I am not going to advocate that you should do this, it is up to you (the individual end user of a Chromium-based browser) to find those strings online and apply them to your browser’s startup environment.
Let me explain a bit. When I compile Chromium, my personal API key and Google client-ID are being embedded in the resulting browser binary, and that’s why everything works so nicely out of the box. In future I will not be embedding my client-ID anymore, but my API key for the browser will remain. That his how Safe Browsing will still work (it’s associated to the API key) but Chrome Sync will stop working (because that’s associated with the Client-ID).
The good news is that Chromium browsers will check the environment when they start up, and look for specific variables that contain a custom API key and client-ID. My chromium package is built in such a way that it is easy to add such customization, by creating a “.conf” file in directory “/etc/chromium/”.
In the Slackware package for Chromium, you will find an example of how to apply such an APIkey/ID/secret combo. Just look at the file “/etc/chromium/01-apikeys.conf.sample”. If you remove the “.sample” suffix this file will then define three environment variables on startup of Chromium that tell the browser to use a specific service configuration.
And you can also copy the Google Chrome key/id/secret into that file and then it’s as if you are using a Chrome browser when talking to Google’s cloud services.
An ‘un-googled’ browser experience
The above API blocking scenario is a “win/lose” scenario as far as I am concerned. For Google it is a “win”: they still get to collect the data related to your online activities which they can monetize. And you “lose” because in return Google won’t allow you to use their cloud sync service any longer. That is not acceptable. And it lead to a bit of research into the possibilities of turning this fiasco into a “win” for the user.
Turns out that there’s is actually an existing online project: “ungoogled-chromium – a lightweight approach to removing Google web service dependency“.
High-over: the “un-googled chromium” project offers a set of patches that can be applied to the Chromium source code. These patches remove any occurrence of Google Web Service URLs from the source code which means that the resulting browser binaries are incapable of sending your private data into Google datacenters. Additionally these patches bring privacy enhancements borrowed from other Chromium derivatives like the Inox patchset, Debian’s Chromium, Iridium browser and Bromite.
Not just a “win” for the user but a “lose” for Google. They basically brought this down on themselves.
My conclusion was that a removal of Google associations from Chromium and at the same time improving its privacy controls is what I must be focusing on in future Chromium packages.
During my research I did look at existing alternative Chromium browser implementations. They all have their own merits I guess. I do not like to switch to Vivaldi since I think its development process is hazy i.e. not public. Only its complete release tarballs are downloadable. Or Brave – its sources are not available at all and it tries to enforce an awards system where you are encouraged to view ads – I mean, WTF? If I wanted to run a browser compiled by another party that tries to use me for their own gain, I could just stick with the official Chrome and be happy. But that is not my goal.
What I did instead was to enhance my chromium.SlackBuild script with a single environment variable “USE_UNGOOGLED” plus some shell scripting which is executed when that variable is set to ‘true’ (i.e. the value “1”). The result of running “USE_UNGOOGLED=1 ./chromium.SlackBuild” is a package that contains an “un-googled” Chromium browser that has no connection at all to Google services.
I make that package available separately at https://slackware.nl/people/alien/slackbuilds/chromium-ungoogled/
Be warned: using un-Googled Chromium needs some getting used to, but no worries: I will guide you through the initial hurdles in this article. Continue reading! And especially read the ungoogled-chromium FAQ.
The first time you start my chromium-ungoogled it will create a profile directory “~/.config/chromium-ungoogled” which means you can use regular Chromium and the un-googled chromium in parallel, they will not pollute or affect each other’s profiles.
You’ll notice as well that the default start page points to the Chrome Web Store but the link actually does not work. That’s unfortunate but I decided not to look into changing the default start page (for now). Patch welcome.
Which leads to the first question also answered in the above FAQ: how to install Chrome extensions if the Chrome Web Store is inaccessible?
The answer allowing direct installations from the Web Store afterwards is to download and install the chromium-web-store extension (Chrome extensions are packed in files with .crx suffix). You have to do this manually but the instructions for these manual installation steps are clear. Then, any subsequent extensions are a lot easier to install.
Another quirk you may have questions about is the fact that un-Googled Chromium seems to forget your website login credentials all the time. Actually this is done on purpose. FAQ #1 answers this: Look under chrome://settings/content/cookies and search for “Clear cookies and site data when you quit Chromium“. Disable this setting to prevent the above behavior.
Watching Netflix, Hulu or Disney+ content will not work out of the box, you’ll have to install the Widevine CDM library yourself. If you have been a Slackware user for a while, you may recall that I used to provide chromium-widevine-plugin packages, until the capability to download that plugin all by itself was added to Chromium source code by Google. Well… the un-Googled Chromium removed that capability again but I have updated my package repository with a version of the widevine-plugin that works with with the un-Googled browser.
Safe browsing is not available in un-Googled Chromium, since that too is a service provided by Google. Recommended alternatives are uBlock Origin or uMatrix.
Sync your browser data to an online service which is under your own – not Google’s – control
Now that we said good-bye to Google Cloud Sync, can we still sync our passwords, bookmarks and browsing history to a remote server and access these data from multiple browsers? Yes we can!
Even better, we can sync that data to a place that is under our own control. Multiple computers using the same synchronized data will give you the same experience as your prior usage of Google Cloud Sync. This will then also not be limited to Chromium based browsers – Mozilla based browsers are able to access the same centrally stored data. Win!
The question is then: how to implement it? Is this something you can do without being an IT person or a Slackware Guru?
I will show you that the answer is “yes”, in a follow-up article dealing with keepassxc and xbrowsersync.
Have fun! Eric
Thank you, Eric for the update and for all the hard work you’ve put into this. I find your conclusion hopeful that this will drive the open-source/free software community to rally around a richer ecosystem for third-party browser sync.
PS: TIL what ‘senang’ means!
Cheers.
Loan word from Indonesian, or loan word from Dutch? 🙂
Senang – Indonesian/Malay. Google (Ha) translates it as “Happy” or as an adjective, “easy”
There must be some employees there who use it a lot. I would tend to translate it as “satisfied” or “I’m OK with that”. Clearly that is not the case. But now, in the last few days (around the beginning of January 2022) my email account is logging itself in again when i start up Chromium! What is going on? Anyone know?
Hi Eric
Thank you for your efforts in building Chromium over many years and for your clear explanation of what will happen in the future.
On a point of clarification, your Chromium build is not included as standard in any of the recent Puppy Linux builds.
I do however take your publicly available .txz files and repackage them into a squashfs module that can be added to a Puppy Linux installation.
I also do similar repackaging for Chromium builds from: Arch Linux, Debian, Linux Mint and also Snap.
Your 14.2 builds however have the widest compatibility and utility.
Can I take it that any build you make publicly available after 15 March can continue to be repackaged in this way?
I am sorry if through ignorance of the “agreements” you have had in the past with Google, I have inadvertently caused you any problems. This has certainly not been my intention.
Thanks
peebee
p.s. I also do similar repackaging for Chrome, Iron, Slimjet, Vivaldi, Firefox, Seamonkey, & Palemoon.
Hi peebee
My post-15-march Chromium package still embeds my personal Slackware Chromium API Key legally obtained from Google. Anyone who runs my binary will automatically increase the API usage counter on my personal Google account since the browser contacts Google Service APIs multiple times for every online page you access. Once the number of API calls exceeds my account’s monthly free-of-charge usage count, Google will bill me for that. I am fine with that for SLACKWARE users of my package, since that is the distro I help developing. If Slackware gains popularity through the availability of Chromium that is exactly what I intended.
All other distros that offer re-packaged versions of my binaries are basically freeloaders who use the labor of others – possibly even without recognition of the original effort. How many Puppy users realize that the Chromium browser they are using was created for Slackware, not for Puppy? And by whom it was created? I am not willing, nor prepared, to carry a personal cost so that other distro maintainers can sit on their hands.
That unfortunately includes your re-packaging of my Chromium binaries for Puppy users. I would rather see that these users switch to Slackware if they like my packages so much.
I am not condemning your re-packaging activities. And you are not the only one. It seems that it’s common for Live distros to use other people’s work by anonymizing and re-packaging their binaries as Live OS modules. It’s what made these Live distros so popular, you can get all kinds of goodies with the click of your mouse, but I have no high regard of this kind of endusers. They’re the equivalent of script-kiddies using Kali without knowing what they do.
To your defense, it is not widely known how Chromium based browsers and Google’s API services interact, less so even that using the browser costs its packager money even though the browser is free to download and use. But in future (after 15 March in any case) please stop re-packaging my binaries, or at least make it very clear where they come from – and accompany that with a link to my Paypal account.
Hi Eric
Would these startup messages be acceptable?
https://imgur.com/LqBlCjM
https://imgur.com/GxdCMEt
Would it be preferrable to you that only the chromium-ungoogled build was repackaged?
Thanks
peebee
Hi peebee,
My chromium package updates will probably stop once I am satisfied with chromium-ungoogled and a sync setup that works decently: since building a single package takes half a day on my infrastructure, I need to be conservative with the number of package variants I provide.
So it’s a good idea to use 15 March as a cut-over date to stop offering squashfs modules containing chromium and instead switch to chromium-ungoogled.
I won’t run any risk of being billed by Google for the un-googled product.
Eric, you are awesome!
I have been using keepass/keepassxc for a long time and host it on my nextcloud, I am looking forward to your next article about keepassxc and how syncing may be done better.
Karl
PS: I have de-googled my phone, and staying away from google as much as possible.
Thank you, Eric! You did great work in this field.
Looking forward to joining the Un-Googled browser community! Thank you Eric for all your work in supporting Chromium over the years! I personally welcome the additional privacy and much of the same functionality.
Thank you Google for abstaining from being evil for so long! I can’t say that I wish YOU (G) any luck with your new policies!
[rant on]
If you can’t get there with lynx, you can probably get along without it. Duckduckgo.com is good enough for me. Google can violate personal privacy all it wants; google can change search results based upon google’s own political notions all it wants. Google has nothing I want or need. Google be damned as it fades into the dustbin of smart ideas turned stupid by corporate greed.
[rant off’]
Hi Eric,
Thank you for taking the decision to maintain chromium-ungoogled package for Slackware. I’m not much a fan of Chromium/Chrome because of the Google thing, but the ungoogled version made me switch my default browser to it (from Firefox) and my web surfing looks/is smoother (i.e. quicker).
Well thank you Eric!
I was wondering when you were going to post about this, with your thoughts and suggestions on various solutions. I had been following the discussions since your initial announcement about a month ago, and offered up the previous solution that you cogitated over to some folks here and there.
Definitely not the ideal.
This, however, seems like the right track for you to take, and I fully support your endeavor in this regard.
Since it wasn’t completely “On-Topic” for Slackware, I understand why there’s no mention of KeepassDX, my personal choice for Keepass on Android, and after limited joy with trying to sync between KeepassDX on Android and KeepassXC on desktop via one of my Gitea servers, similar to how it is performed with implementations of “pass”, I settled on just using NextCloud and I’ve been happy with that. But…
I had not heard of xBrowserSync prior to your post (So thank you for bringing that to people’s attention), and it appears to be wonderful. It meets all of my objectives in FOSS deployments, considering I can self-host!
So Syncing between desktop, de-googled Chromium browsers on mulitple desktop/laptop machines with Androids does indeed seem like a lose/win, for google/users, respectively.
And that is a win/win in my book.
As always Eric, thank you for your valued contributions and insight. You are much appreciated and a valued member of the Slackware Team!
Kindest regards,
Bradley
.
Hi Eric,
most if not all Slint users who install your chromium package do this using slapt-get, un-commenting the second line below of their /etc/slapt-get/slapt-getrc:
# The sbrepos repository from Eric Hameleers
# SOURCE=https://slackware.uk/people/alien/sbrepos/14.2/x86_64/:DEFAULT
Blacklisting chromium through the EXCLUDE line of slapt-getrc doesn’t prevent to install it typing “slapt-get -i chromium”.
I can of course and will request that users do not install it and remove it if installed, but cannot guarantee that they will. Further, not all Slint users are registered to our mailing list or read the provided documentation.
Would you consider removing the chromium package from the repositories sbrepos? I think that few users would search it in a repository not listed in slapt-getrc, hence my question.
Best regards,
Didier
PS Just a thought: may be you could also suggest that users of your chromium package contribute to pay the associated bills, storing it in a specific repository?
Hi Didier,
My comment about how 3rd parties use or re-use my binaries is born out of a long-standing frustration. I have no issue at all with people using my sources and scripts as long as attribution is given to the original author (mostly that’ll be me), since it involves no more than leaving my original copyright lines un-touched in the scripts.
I feel different about people taking my *binaries* and offering them to their own users without giving proper credit to the person who did all the hard work of debugging the code and compiling the binaries (that would then also be me). It happened more in the past, and I have been very explicit in how I view this behavior.
In your case, Slint is basically a fully compatible mod of regular Slackware. Your configuration of slapt-get mentions the owner of the repository. People who install my packages through slapt-get, will get the full un-modified package. In that sense I should not have mentioned Slint as a ‘freeloader’, I am fine with that mechanism.
However, users of Chromium on Slint do contribute to the usage of my personal Google API key and therefore potentially push that usage beyond the cost-free upper boundary. And Slint is not Slackware, and I am only prepared to pay for people who actually use Slackware.
Between wednesday (when I wrote the draft text of above post) and today (when I had time to evaluate the responses), I have come to the conclusion that I will wait and see what happens with the usage patterns and not ask anyone to ‘cease & desist” as long as users of my Chromium binaries are explicitly informed about the package’s origin and the potential cost involved for its creator.
Maybe Google will not remove the distro-specific increased number of cost-free API calls per month which is associated with my API key, and then my wallet is safe. But I have not seen that guarantee yet.
I am not going to remove any package from my repositories for the sole reason that a 3rd-party distro which I do not control, added my repository in their package management tool. I will leave it up to you and others to find ways to deal with my wishes.
Hi and thanks for your answer Eric.
To explicitly inform Slint users not only of the package’s origin (which is already done) but also of the potential cost involved for its creator, the most efficient way is probably to add a comment about that in our default slat-getrc. This can be done simply, just uploading to the Slint repository a rebuilt slapt-getrc package including the edited slapt-getrc. I can do that today, and will unless told otherwise by you.
Hi Eric,
[nearly one year later…] May I tell Slint users that they may use your chromium-ungoogled package like the one here: https://slackware.uk/people/alien/slackbuilds/chromium-ungoogled/pkg64/14.2/ as in this case you do not have to pay something to Google? I would also point them to the FAQ https://ungoogled-software.github.io/ungoogled-chromium-wiki/faq
Best,
Didier
Un-googled Chromium does indeed not use my Google API key.
Maybe not directly relevant to Chromium and the unGoogled life but the below perhaps explains some of Google’s browser moves. Google wants to move a lot of spying and tracking into Chrome, and perhaps no accident that getting as many people as possible Chromed up properly (and away from plain old Chromium) is the point:
https://www.eff.org/deeplinks/2021/03/googles-floc-terrible-idea
“We emphatically reject the future of FLoC. That is not the world we want, nor the one users deserve. Google needs to learn the correct lessons from the era of third-party tracking and design its browser to work for users, not for advertisers.”
https://daringfireball.net/linked/2021/03/04/eff-google-floc
“This helps explain Google’s message yesterday. They’re moving their tracking from third-party cookies that they process through the cloud to tracking that’s done in Chrome. Basically I think that’s it.
If you prefer a Chromium-based browser, you should use one other than Chrome. I like Brave for my (occasional) Chromium browser needs, but Microsoft’s Edge might be a good choice too. Brave bills itself as a privacy browser; at this point it seems fair to say Google is turning Chrome into an anti-privacy browser. It’s that simple.”
Dear Eric: First and before all I would like to state that I fully agree with your sentiment.
However: IANAL but does not your “I explicitely forbid” clash with the BSD 3-Clause License the ungoogled source and your package are distributed with? Whether or not you can add a 4th clause on the use of your keys to the license or even in a separate license I am not knowledgeable enough about to answer.
Kind regards, Dick
Hi Dick,
Note that I have added the BSD license terms only to my scripts, not to the resulting packages. The 3-Clause BSD license in the Chromium source allows me to change the terms of usage for the binaries compiled from the Chromium source as long as the original copyright statements are preserved.
And even the use of my binaries in re-packaged form is OK with me as long as it’s immediately obvious that I am their creator and not the 3rd party who redistributes them.
The Chromium case is the exception because yes, *your* usage of my binary involves a cost that is directly affecting *my* finances.
As long as the Chromium binary is used on a Slackware system, I am OK with that, not just because of the donation money I get from Slackware users, but also because of the deal I struck with the Chromium team to allow wider usage of the browser without me getting billed immediately; my personal API key is aptly named “Alien’s Chromium for Slackware” in the Google Cloud console which means, it is meant to be used in the context of Slackware. Not beyond.
Koodos, Eric! I’ve been waiting for this for a long time.
Hi Eric.
I always enjoy reading your posts as your code… Clear and very well written. It helps me a lot in my slackware learning curve. I really appreciate that approach instead of many “quick and dirty” information… from other sources.
I truly hope an unGoogled life, a browser is a key starting point. Many thanks for this.
Hi Eric,
Thanks for all your great work.
My “chrome:components” in Chromium says:
“Widevine Content Decryption Module – Version: 4.10.1610.0”.
Your version: 4.10.1582.2
Any change you could update it, or does it do that automatically once installed in Chromium-ungoogled?
Groet, Marco
P.S. At the moment using your Chromium 89 build because of known exploit. In Windows I was already using Chromium-ungoogled build from https://chromium.woolyss.com/
If you are unsatisfied with the package for Widevine I supply you can extract Chrome’s Widevine CDM library from the official Chrome binaries. Good luck with that but I will stick with the version that’s publicly available and not tied to Google’s browser if I am making it available for Un-googled Chromium.
The version in my package is the same that’s being used by Firefox and it’s the latest version you can download.
But it does not really make sense, right, that you now switch to my Chromium package after you felt you must ditch Google’s platform and rather use un-googled Chromium? That defies the purpose. Perhaps you should stick with just Chrome.
And I can compile only so many packages my in 24/7, Chromium is not the only package I provide to Slackware.
I was only asking if it was possible. Didn’t know (or rather, didn’t check) the version in Firefox. I know it’s a PITA to get the right Widevine package, been doing that myself because Firefox didn’t want to automatically download and install it in Linux.
I never used Chrome (and never will). Lately been using Chromium-ungoogled instead of Firefox because it’s more stable. The only reason I use your Chromium build now (with as much of the Google stuff disabled in the settings as possible) is because your Chromium-ungoogled build for version 89 is not yet there (I’m waiting patiently 🙂 ) and there’s a known exploit with version 88.
Cheers, Marco
The thing that may set you off: Widevine is also owned by Google. I assume they add some stuff to their private Chrome version of the CDM library. The version that’s publicly available and also used by non-Google browsers (and which is inside my chromium-widevine-plugin) has not changed for quite awhile. Usually a version bump is triggered by new DRM requirements imposed by content streaming platforms. Until that newer version arrives, the current somewhat older version in my package works just fine.
I will at some point make a newer version of my chromium-ungoogled package but what’s out there now is a proof-of-concept, not a package that I will religiously keep up to date. I guess, stay away from the shady side of the internet, right?
Hi Eric,
Thanks for sharing your insights. A comforting idea that you understand what is going on inside the tools I use everyday.
I became aware of the personal licenses granted by Google when I used youtube-dl (not in Slackware distro ofcourse).
With a fresh install the program worked for a few days and than suddenly stopped.
The solution was to create a personal developer account at Google and get a key. I shared that key with my students. From your experience obviously a dangerous move, besides the profiling on the content that was downloaded.
I did not know something like that was happening in Chromium too.
Luckily I do not have a billing account at google.
Greets,
F.P. Vonck
With a Google developer account that has an API key that exceeds its allotted quota of API calls, the program configured with that API simply stops returning results if it queries the Google API. If your usage hits that limit every month, it could be that you’ll get an email from Google at some point advising you to configure a billing account, but that is not mandatory.
So I think your students’ key usage will be harmless but yes, Google can associate the stuff your students downloaded with your personal profile. The same will of course happen with the stuff people do using my Chromium browser but I have never seen any effects of that, so it is doubtful whether these associations are actually being made.
Thanks for this comforting reply. To demonstrate a text-based search engine i use mps-youtube. The hardware and bandwidth at school are so limited that even a 128p stream on firefox and chrome is not possible. Limited resources stimulate creative improvising.
Hello,
Speaking of “Sync your browser data to an online service which is under your own – not Google’s – control”, personally to keep passwords in sync across browsers and platforms I use a self-hosted Bitwarden instance.
It has Android app, Firefox/Chrome extension and Linux desktop client.
I run the instance in a docker container on a server having accessible public ip and dedicated hostname.
I understand this is just about passwords and nothing else, but that’s the only part of browsers that I’ve always considered important to be kept in sync.
Regards
Hello alienbob,
just a little message to thank you very much helping with this article and for all the work around that issue. It is very much appreciated. Keep safe and take care.
Eric, thanks again for publishing all of this work you’ve done showing us Slackware users how to have Chromium after mid March. If I read it right, a relatively small time investment will get me an unGoogled Chromium (at least until Google changes things again.) Agree that it’s a win for those users who want to use Chromium this way.
All the best,
TKS
Hi Eric,
Running 14.2. The chromium-ungoogled package will install and startup. Dropping the chrome-extension.crx to the extensioin window didn’t work. Had to convert the crx to a zip inorder to manually install. It was a simple matter of using unzip -l Chromium.Web.Store.crx, which showed 593 extra bytes and then dd if=Chromium.Web.Store.crx if=Chromium.Web.Store.zip bs=1 skip=593. Then unzip the file and use the Load Package and everything was fine. HTH someone else trying to use your chromium-ungoogled.
Thank YOU for your diligent work on Slackware. Cheers, BrianA_MN
The chromium-ungoogled package in my repository was actually built on Slackware -current but you are able to use it on Slackware 14.2? That is amazing.
The current package was meant as a proof-of-concept while I was working out how to sync my data to something else than Google’s cloud. Once I drop the chromium package I will likely build chromium-ungoogled also for Slackware 14.2, not just for -current.
Are there tests which you’d like me to run under 14.2 just to verify it is fully working? I typically use ublock origin, HTTPS Everywhere, and Kee. They all install with the chrome-extension and function properly. Youtube seems to play without issue. Vimeo works without issue. Casting, even with the FAQ changes, doesn’t work. I’ll have to continue to try and understand why.
Just wanted to follow-up. Apparently the missing Cast pop-up window is only an issue under FVWM. Fluxbox, blackbox, XFCE all show and cast. If I can’t identify the missing connector I’ll bring the issue to the FVWM developers. Cheers,
I am running chromium-ungoogled now also on Slackware 14.2 and indeed it works flawlessly even though it was compiled on Slackware-current. Probably because chromium.SlackBuild first compiles llvm using the system gcc and then compiles chromium with that custom llvm. No dependencies on system gcc or glibc that way.
You don’t have to do that. I got the error message “Package is invalid: CRX_REQUIRD_PROOF_MISSING” after enabling developer mode and trying to drop the Chromium.Web.Store.crx.
Turns out you need to restart Chromium and then it works! Something that wasn’t necessary before and which Chromium doesn’t warn you about (like with changing flags).
Look at “Known issues” at this website:
https://github.com/ahwayakchih/crx3
That should be
CRX_REQUIRED_PROOF_MISSING
All of this gave me a headache, makes me want to build a cabin on a lake and disappear. There must be a much simpler way to just un-google your life, that’s probably a pipe dream, you can’t unpregnate once pregnated.
I’ve been trying so many browsers, this getting more challenging by the moment, trying to find the easy road. Regardless, Eric….you are a Slackware / Linux Warrior, I thank you for your insight, and your work, it helps me get through my day.
Blessings,
Owen
Hi Eric,
most grateful for the chromium-ungoogled package. Since I do not need the sync function, it gives me everything I expect of a browser.
One small thing, though: After noticing that Spotify requested widevine, I installed your chromium-widewine package. However, Spotify still insisted that widevine must be installed.
I then noticed that the symlink /usr/lib64/chromium/libwidewinecdm.so had no equivalent in /usr/lib64/chromium-ungoogled/
I ran
ln -s /usr/lib64/chromium/WidevineCdm/_platform_specific/linux_x64/libwidevinecdm.so /usr/lib64/chromium-ungoogled/
and afterwards Spotify started as it should. So apparently, and unless I’ve missed or misunderstood something, that symlink is needed.
So there *are* still applications that look for libwidewinecdm.so in the Chromium directory… Chromium itself looks in the WidevineCdm/_platform_specific/linux_x64/ subdirectory these days.
I’ll create an updated package with that legacy symlink.
Hi Eric. Can I know copyright info of ur articles?
I wanna link or quote what u wrote in my website or media.
Good question Seongbin. That information was missing from the blog.
I have now added a widget in the left sidebar labeled “License” which describes the license for the content on my blog: Creative Commons BY-NC-SA (Attribution-NonCommercial-ShareAlike). I hope that is sufficient for you.
I’ve been using ungoogled browser for a little over 5 years and I’m glad that you will be building it for Slackware as well. Much appreciated!
Eric,
With the instructions you gave here, and those on the ungoogled-chromium FAQ and NeverDecaf chromium-web-store github site, on Slackware64 14.2 I’ve installed chromium-ungoogled with the ability to install extensions directly from the Chrome Web Store and automatic extension update checking.
This works perfectly for me. (On Slackware64 -current, I’ve installed chromium-ungoogled but still have to set up the Chrome Web Store.)
Thanks for making chromium-ungoogled available to us, and for your instructions to make it easy!
TKS
Thank you Eric. Google has been going the way of Microsoft and Apple. That way is inevitable.
“Sync your browser data to an online service which is under your own – not Google’s – control”
That’s been the option of my choice for a while. I only keep a gmail account around so I can sign in were needed.