Issue with Widevine New Version Impacting Existing Offline Persistence License and Ineffectiveness of --disable-component-update in CastLab Electron Version 17

[ranjithrr]

Environment Information:
CastLab Electron Version: 17
Offline Persistence License Downloaded with Widevine Component: 4.10.2557.0
Offline Persistence License Not working New Widevine Component : 4.10.2662.3 and 4.10.2710.0
Offline Persistence License Validation Period : 1 year
Operating System: Windows

Issue Description:
I have encountered a significant problem with the Widevine component in CastLab Electron version 17. It appears that the new version of Widevine is having a detrimental effect on my existing offline persistence license, causing previously accessible content to become inaccessible. Additionally, it seems that the --disable-component-update flag is not effectively preventing updates, which is compounding the issue.

Context:
I have been using CastLab Electron version 17 with an offline persistence license that was downloaded approximately six months ago. Up until now, this setup has been working seamlessly, allowing me to access and play content offline. However, recently, it seems that the Widevine component has been updated to a new version, and as a result, my previously downloaded content is no longer playable.

Specific Issues:

1.Widevine New Version Effect on Existing Persistence License: The new version of Widevine appears to be affecting my existing offline persistence license. As a result, content that was previously accessible offline is no longer functioning. This issue has had a notable impact on my ability to view content that I had expected to be available offline.

2. Ineffectiveness of the --disable-component-update flag: I attempted to mitigate the issue by using the --disable-component-update flag, with the expectation that it would prevent component updates, including Widevine. However, it seems that this flag is not working as intended, and the Widevine component is still being updated.

Questions:

1. Is this behaviour with the new Widevine version and offline persistence license expected, or is it possibly a bug or unintended behaviour?

2. Why is the --disable-component-update flag not effectively preventing component updates, particularly in the case of Widevine?

[khwaaj]

1. When the CDM is updated, depending on exactly what changed, all persisted licenses may be invalidated (with major security updates this is always the case). When this happens they will need to be refreshed with the new CDM. Disabling updates is one way to delay this, but once the installed CDM is revoked all bets are off.
2. I've not had any reports of problems with --disable-component-update (this option is inherited from Chromium), but I'd need to look into it to be sure. As an alternative the components API we added provides a way to disable updates more directly.

[ranjithrr]

Our primary objective in reaching out to castlabs is to seek information and potential solutions related to the impact of Widevine component updates on existing persistence licenses. Specifically, we are interested in understanding whether there is a way to ensure that Widevine component updates do not adversely affect existing persistence licenses, or if there is a mechanism for updating old persistence licenses without requiring manual intervention.

[khwaaj]

There is no way to entirely prevent the licenses being invalidated. As you already have been trying to do, a band aid solution is to disable updates entirely to buy some time. This can't be used indefinitely though since the older CDM will be revoked after a large security update, which means it will stop working sooner or later. The timeframe for this is entirely defined by Widevine, and not public information.

What can be done is to implement a scheme to test and update the persisted licenses when a CDM update occurs. This might not be as easy as it sounds though, in part because the EME CDM API is rather rigid and hard to work with, but also since you'd need to maintain the required information to be able to refresh the licenses yourself (e.g CDM session-id mapping, content key identification meta-data (probably in manifest), DRM service configuration, authrorization, and so on). Exactly how to do this, and what you need, would differ depending on the streaming and/or DRM service in use.

A few approaches have been discussed in several older tickets, but high-level it would generally go something like this:

1. When a CDM update is detected, loop over all offline content and try to load (and unload) the matching persisted license.
2. If a license can't be loaded, mark it for update (or maybe rather the offline content it belongs to, unless the content has expired for a valid reason, of course).
3. If there is no internet connection, save the list for later and warn the user that the content licenses have expired.
4. Once a connection is available, loop over the list again and and trigger license requests to refresh them. Make sure to update the CDM session-id mappings for the offline content with the new session.

Using a scheme similar to what is described here could mean that updates can be done without manual intervention assuming the requirements to get a new license is fulfilled. If service authorization has expired though, and can't be automatically refreshed, manual intervention will be required to re-authenticate.

On another note, I see you also mentioned being on ECS 17, which is rather old. Google has recently more strictly started observing their policy to keep CDMs available for a years worth of Chromium releases. This means you are well out of the supported window with ECS 17, and you can't be sure to receive CDM updates (or even a CDM at all on a first install, see #169).

[sudharsans85]

Thanks for your detailed response

Any idea, why this is so complex to manage in Windows alone?. We have same application with offline support for Android platform- We havent faced any issues - we do not see any updates on CDM - i guess it happens only via OTA based OS updates which is very rare. In Windows, we see multiple updates and theres no public info on the same and it invalidates the license and causes more issue from end user. Unlike a OTT application where user gets to download a handful of videos, users downloads few hundreds-thousands of videos - educational content in our application and this will become a nightmare if there are frequent updates that invalidates the license.

[khwaaj]

You are essentially right, browsers on desktop platforms (Windows, macOS and Linux) all use the Widevine Browser CDM (L3), which is not the same as the CDMs used on something like an Android device. Many Android devices even have a L1 CDM, which has a higher security rating since it relies on hardware to protect the keys and media. Typically the browser CDM needs to be updated much more often than the types of CDMs used on devices, so this is why the problem is more prevalent for desktop implementations.

Unfortunately this is a necessary evil for Widevine to be able to maintain the security of the Browser CDM. The update schedule used to be public information, but was also made private because of security concerns. DRM is messy, but often a requirement from content owners, so it is something that media playback solutions need to deal with.

[ranjithrr]

I have a specific query related to the identification of differences between the version of Widevine for which a persistence license was downloaded and the current Widevine version. Is there a method or mechanism that allows us to determine whether there is a difference between the two versions? This information is crucial, as it will enable us to inform our users about any potential compatibility issues.

[khwaaj]

Is there a method or mechanism that allows us to determine whether there is a difference between the two versions?

The only approach I know for sure works is the one I described above, i.e. that after an update you try to load the previously persisted licenses and check the result.