My thoughts on Slackware, life and everything

Tag: netflix (Page 1 of 3)

How to ‘un-google’ your Chromium browser experience

… 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

Disney+ finally works on Linux!

A little more than three weeks after the new Disney+ movie streaming service went officially live, the Disney company has added Linux support to their Widevine DRM protection. No more “Error 83”. No more need to install the Windows version of Chrome in Wine. Watching your favorite movies is now possible in the native Linux browsers – both Mozilla and Google based. Firefox will download the Widevine CDM (content delivery module) automatically, Chrome has the support built-in and for my Chromium package and other Chromium-based browsers you;ll have to install my chromium-widevine-plugin package.

I guess that a sufficiently large group of Linux enthusiasts have been complaining. And with success!

Enjoy! Eric

Chromium 68 with updated Widevine plugin

chromium_iconLast week, Chromium 68 was introduced to the “Stable Channel” with lots of bugs fixed, many of those being security fixes (42 in total). And a few days ago an update was released, so I decided to build Chromium 68 for Slackware.

NOTE: starting with Chromium 68, the browser will show a “Not secure” warning on all HTTP pages. Google announced this in a blog post published on February 8th on Google’s Chromium and Online Security blogs.

You’ll find 32bit as well as 64bit packages for Chromium 68.0.3440.84 in my package repository. They are available for both Slackware 14.2 and -current. I have also updated the Chromium Widevine plugin to version 1.4.9.1088. The older version refused to work with Chromium 68. Note that the Widevine plugin is available for 32bit just as for the 64bit browser, so even those running older computers (or those of you who are in need of a 32bit OS) can enjoy DRM movie playback.

For newcomers: Widevine is a Content Decryption Module (CDM) used by Netflix to stream video to your computer in a Chromium browser window. With my chromium and chromium-widevine-plugin packages you no longer need Chrome (or Firefox if you dislike that browser), to watch Netflix.

Also note (to the purists among you): even though support for Widevine CDM plugin has been built into my chromium package, that package is still built from Open Source software only. As long as you do not install the chromium-widevine-plugin package, your system will not be tainted by closed-source code.

Chromium packages: https://slackware.nl/people/alien/slackbuilds/chromium/ (rsync://slackware.nl/mirrors/people/alien/slackbuilds/chromium/)
Widevine packages: https://slackware.nl/people/alien/slackbuilds/chromium-widevine-plugin/ (rsync://slackware.nl/mirrors/people/alien/slackbuilds/chromium-widevine-plugin/)

Chromium 56, LibreOffice 5.2.5

libreoffce_logoI had rebuilt the libreoffice-5.2.4 packages for Slackware -current last week, because library updates in Slackware had broken the spreadsheet application ‘localc‘. And voila… not long afterwards the Document Foundation blog announced 5.2.5: “all users are invited to update to LibreOffice 5.2.5 from LibreOffice 5.1.6 or previous versions“. Today on the first of february, we can even witness the 5.3 release.

A list of the most significant new features of LibreOffice 5.3 has been published in a separate document (http://tdf.io/lo53features) and you are invited to watch a series of short videos (http://tdf.io/53vids) if you want to get a taste of what’s on the plate. Collaborative editing is the major highlight I guess. A detailed description of these new features is also available as a web page:  http://www.libreoffice.org/discover/new-features/.

I am definitely not building packages right away for 5.3 but I did compile packages for 5.2.5 – albeit only for Slackware -current. I may or may not create these packages for Slackware 14.2 as well and then upgrade the -current package to 5.3. Depends on the other stuff I need to do.

These libreoffice packages are huge in size so please use a mirror for download, and take into account that only the master site and ‘bear’ will have the packages during the first 24 hours.

Note: the LibreOffice browser plugin (NPAPI based) has been removed in LibreOffice 4.4.0:  https://skyfromme.wordpress.com/2014/09/25/killing-the-npapi-plugin/

chromium_iconOn another note, Chromium (and Chrome) 56 ‘stable’ was released. It’s nice to test the HTML5 feature set on a site like HTML5test and see that it is at the top of all the browsers up there (517 points, only Chrome 56 for Windows scores better because it supports speech synthesis).

Packages for Slackware 14.2 and -current are now available from my repository. No ETA for Slackware 14.1 packages, and perhaps it is time for people still using Chromium on 14.1 to upgrade to 14.2?

As always, here are some common download sites:

Have fun! Eric

Chromium 44 available (Netflix still works)

chromium_iconI have made new packages for the chromium browser and its widevine plugin. Chromium version 44 was released a bit earlier this week, and it took me a while to compile, because the new OpenJDK 7u85 and LibreOffice 5.0.0.rc3 packages were ahead of it in the build queue. Guess what… now that I am writing this blog article after uploading the packages for chromium-44.0.2403.89, I notice that there was a second release of Chromium 44 Stable… today. Which makes me wonder if there was a regression in the earlier source release.

That updated version 44.0.2403.107 may have to wait, because I will be unable to do a lot of Slackware related stuff until august; real life is catching up with me. If there are real useability issues with 44.0.2403.89, let me know and I will see if I can shift priorities or make the older 43.x packages available again. My initial (not exhaustive) testing showed no weirdness at least.

Regardless, it took a few iterations before I got the Widevine CDM adapter to compile properly. I had to look at my chromium-dev package’s history to remember what had changed in version 44. Once I applied that knowledge to the stable sources, it all began to come together. Netflix still works 🙂 … well, after you’ve installed/upgraded my chromium-widevine-plugin package of course. which contains the proprietary Content Decryption Module.

The new chromium source I compiled into a package, comes with several security fixes, and here are the CVE’s:

  • [$3000][446032] High CVE-2015-1271: Heap-buffer-overflow in pdfium. Credit to cloudfuzzer.
  • [$3000][459215] High CVE-2015-1273: Heap-buffer-overflow in pdfium. Credit to makosoft.
  • [$TBD][461858] High CVE-2015-1274: Settings allowed executable files to run immediately after download. Credit to  andrewm.bpi.
  • [$7500][462843] High CVE-2015-1275: UXSS in Chrome for Android. Credit to WangTao(neobyte) of Baidu X-Team.
  • [$TBD][472614] High CVE-2015-1276: Use-after-free in IndexedDB. Credit to Collin Payne.
  • [$5500][483981] High CVE-2015-1279: Heap-buffer-overflow in pdfium. Credit to mlafon.
  • [$5000][486947] High CVE-2015-1280: Memory corruption in skia. Credit to cloudfuzzer.
  • [$1000][487155] High CVE-2015-1281: CSP bypass. Credit to Masato Kinugawa.
  • [$TBD][487928] High CVE-2015-1282: Use-after-free in pdfium. Credit to Chamal de Silva.
  • [$TBD][492052] High CVE-2015-1283: Heap-buffer-overflow in expat. Credit to sidhpurwala.huzaifa.
  • [$2000][493243] High CVE-2015-1284: Use-after-free in blink. Credit to Atte Kettunen of OUSPG.
  • [$7500][504011] High CVE-2015-1286: UXSS in blink. Credit to anonymous.
  • [$1337][419383] Medium CVE-2015-1287: SOP bypass with CSS. Credit to filedescriptor.
  • [$1000][444573] Medium CVE-2015-1270: Uninitialized memory read in ICU. Credit to Atte Kettunen of OUSPG.
  • [$500][451456] Medium CVE-2015-1272: Use-after-free related to unexpected GPU process termination. Credit to Chamal de Silva.
  • [479743] Medium CVE-2015-1277: Use-after-free in accessibility. Credit to SkyLined.
  • [$500][482380] Medium CVE-2015-1278: URL spoofing using pdf files. Credit to Chamal de Silva.
  • [$1337][498982] Medium CVE-2015-1285: Information leak in XSS auditor. Credit to gazheyes.
  • [$500][479162] Low CVE-2015-1288: Spell checking dictionaries fetched over HTTP. Credit to mike@michaelruddy.com
  • [512110] CVE-2015-1289: Various fixes from internal audits, fuzzing and other initiatives.

Get my chromium packages in one of the usual locations:

Change the URL a bit to get the chromium-widevine-plugin  package.

Have fun! Eric

« Older posts

© 2024 Alien Pastures

Theme by Anders NorenUp ↑