Chromium-widevine snap

Currently, there are two things breaking the user experience of Chromium, compared to Chrome. For advanced users, they are easy to work around, but for novice users, they are not.

The first issue is the non-default user agent that breaks a lot of websites, including many streaming sites, which is why I think it’s related to this request. There is a topic about it here: Chromium: Stop using custom user agent, work towards generic one

The second issue is the lack of easy Widevine integration. While the Chromium snap looks in $HOME/snap/chromium/current/.local/lib/WidevineCdm/ for Widevine binaries, installing them there is still a completely manual undertaking.

I’m currently using a script I wrote a while back. It’s stored in ~/.local/bin/ and called Note that the internet has many comparable scripts, so many others are doing the same thing.


# Chromium root directory

# Create a temporary directory
tmpdir=$(mktemp -d)

# Download Chrome
echo "Downloading Chrome package..."
wget -qO "$tmpdir"/chrome.deb

# Extract the archive
mkdir "$tmpdir"/chrome
echo "Extracting Chrome package..."
dpkg-deb -R "$tmpdir"/chrome.deb "$tmpdir"/chrome

# Copy the Widevine directory tree to the proper location
if [ ! -d "$root"/.local/lib ]; then
  mkdir -p "$root"/.local/lib
if [ -d "$root"/.local/lib/WidevineCdm ]; then
  rm -R "$root"/.local/lib/WidevineCdm
echo "Copying Widevine directory..."
cp -R "$tmpdir"/chrome/opt/google/chrome/WidevineCdm "$root"/.local/lib/

# Clean up
echo "Cleaning up..."
rm -R "$tmpdir"
echo "Please restart Chromium."

exit 0

I run this script every time the Chromium snap is updated a major version (so upstream Chrome and possibly Widevine are updated as well), but for the average user, this is not particularly friendly.

I think many people would appreciate a chromium-widevine snap that does nothing other than what my script does: download a Chrome package to /tmp, extract it, copy the Widevine parts over to the user’s ~/snap directory, and remove the Chrome package.

Another snap is not going to be able to write into the chromium snap’s SNAP_USER_DATA directory. IME, there are two options here:

  1. the chromium snap is updated to provide a writable content interface that other snaps can plugs and write into with the chromium snap being updated to look for widevine there. The chromium-widevine snap could the request an auto-connection for auto-connection
  2. the chromium snap is updated to incorporate

@oSoMoN - thoughts?

There’s also this script, which seems to be able to grab the Widevine plugin without downloading all of Chrome:

Following the steps in that script, I get a 3.8MB zip file:

  Length      Date    Time    Name
---------  ---------- -----   ----
  9304340  2019-11-11 14:22
      375  2019-11-11 14:22   manifest.json
      479  2019-11-11 14:22   LICENSE.txt
---------                     -------
  9305194                     3 files

Of course, the main problem with this is the contents of the license file:

"Google Inc. and its affiliates (“Google”) own all legal right, title and interest in and to the content decryption module software (“Software”) and related documentation, including any intellectual property rights in the Software. You may not use, modify, sell, or otherwise distribute the Software without a separate license agreement with Google. The Software is not open source software.

If you are interested in licensing the Software, please contact

I suspect the same licensing issues would apply to a script that extracts the plugin from the Chrome deb.

I tried the standalone Widevine in the past as well, but I noticed that both and the actual binaries in the repository there were not always updated quickly, sometimes taking weeks to catch up with the distributed in the Chrome deb. And sometimes the version there was even incompatible with the latest Chromium build.

This may have changed though. It’s been a while since I tried it.

As pointed out by James, the problem is not purely technical, it’s got to do with licensing. I am not a lawyer, but I believe that either solution proposed by Jamie would be at best grey area, but more likely frankly in violation of Widevine’s license, and therefore couldn’t be distributed in the snap store.

What about things like flashplugin-installer and pepperflashplugin-nonfree, that used to be in Debian and Ubuntu’s repositories, doing basically this as well?

That still leaves open the licensing issue. It’s spelled out pretty clear that the standalone Widevine CDM downloads require additional licensing to use.

It’s not at all clear that downloading all of Chrome and extracting the same libraries from there would be any different. The terms of service say “You may not copy, modify, distribute, sell or lease any part of our services or software”.

The EULA in force from before April was even more explicit stating “you may not (and you may not permit anyone else to) copy, modify, create a derivative work of, reverse engineer, decompile or otherwise attempt to extract the source code of the Software or any part thereof”. While there is no mention of derivative works in the new terms, default copyright terms forbid them.

We’ve got the additional terms of service to guide us there. It specifically calls out the Flash plugin as an independent work with its own license terms from Adobe. Further more, it includes the following terms:

Flash Player, Version 10.x is designed only as a browser plug-in. Sublicensee may not modify or distribute this Adobe Software for use as anything but a browser plug-in for playing back content on a web page.

Perhaps that was enough for Debian to feel comfortable with the downloader package.

So how does Firefox do this then?

Mozilla has a license to distribute Widevine.

I wonder if @oSoMoN’s work on upstreaming Snap packaging will mean an official Google Chrome Snap sooner than later, which would presumably come with Widevine.