Change:
- `firefox-devedition`, `firefox-beta`, `firefox-esr` executable file names for now match their package names, which is consistent with the `firefox-*-bin` packages. The desktop entries are also updated so that you can have multiple editions of firefox in your app launcher. <ins> - `chromium` and `ungoogled-chromium` had a long stanging issue regarding Widevine DRM handling in nixpkgs fixed. `chromium` now no longer automatically downloads Widevine when encountering DRM protected content. To be able to play DRM protected content in `chromium` now, you have to explicitly opt-in as originally intended using `chromium.override { enableWideVine = true; }`. This override has been added almost 10 years ago. </ins> - switch-to-configuration does not directly call systemd-tmpfiles anymore. Instead, the new artificial sysinit-reactivation.target is introduced which allows to restart multiple services that are ordered before sysinit.target

Discussion:
Describe the bug Nix installs a version of Chromium with Widevine on NixOS, despite not being enabled and goes through unfree license checks. To Reproduce Steps to reproduce the behavior: to system configuration in Chromium Expected behavior Widevine is not installed if not explicitly enabled. or Chromium trips nonfree license checks and forces user to allow unfree packages. Screenshots ! ! Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(patrycja): channels(root): nixpkgs: Maintainer information:
Chromium downloads the binaries itself and stores them in It looks like it's a known issue:
Oh, that's bad... :o Seems like Debian fixed this with a custom patch () but from your linked issue that doesn't seem really good either: It won't remove WidevineCdm automatically for existing users It won't be updated -vulnerabilities will never be fixed (which is very bad!) It might break other stuff: I don't think this applies to us though ( should manage it via the Nix store) Brief update: is also present on my system: ! Apparently not but looking at this version is already more than one year old! I cannot get any DRM demos to work so maybe the code will only download the binaries but not execute them (which is still bad but at least a bit better). https://shaka-player-;textlang=en-US;uilang=en-US;panel=HOME;build=compiled This even happens with chrome://settings/content/protectedContent set to "Blocked". It's disabled then but it will still be (re-)downloaded automatically.
I've submitted this to upstream: Let's see what happens.
If you set enablewidevine you need a license to distribute it. See Over to the encrypted media folks to comment, but this sounds like WAI. Does Nix have a Widevine license? If Nix does not, and Google is unwilling to change how Chromium and Widevine are licensed together, the best course of action IMO would be to disable it in Nix's binaries (ie. if enableWidevine is false, enablewidevine is unset. If enableWidevine is true, enablewidevine is set and license is changed to unfree.)

I understand that building Chromium is not something the average person can do on their toaster, but I don't think the group of people that need Widevine and are unwilling to use the official proprietary Chrome binaries is very large.
I marked this as stale due to inactivity. &rarr;
I am unable to reproduce this more than 3 years later on M124. Closing this, assuming this has been fixed a long long time ago.
I can confirm this is still an issue. Followed instructions in OP.
Okay, thanks, I managed to reproduce it now. Might have been a fluke or specific to my use of back when looked into this before. I want to clarify that this is not violation of the BSD-3 license uses. I do however understand that some prefer having not download additional unfree blobs.
There is now. It disables the automatic download and prevents previously downloaded blobs from being loaded and executed. With that PR, Widevine only works when going through the wrapper (). I hope this resolves the concerns raised in this issue here and makes both non-DRM and DRM users happy.
This issue has been mentioned on NixOS Discourse. There might be relevant details there: