electron-releases
electron-releases copied to clipboard
Persistent license support electron build for linux
We provide content to our customers in ubuntu/debian. These systems are expected to be offline. When can we expect persistent license to be available for linux? Is this item part of existing roadmap?
Unfortunately VMP is not yet supported on Linux by the Widevine CDM and it is currently a prerequisite for securely storing offline licenses. I'll check with the Widevine team about future plans to support Linux for these scenarios.
Linux support for the VMP enabled Widevine CDM is on the roadmap and is being actively investigated, although the ETA is unclear at this point. We are probably looking at the second half of 2018 before it becomes a reality.
Once the required features are available in the CDM we will likely look into providing a Linux build of castLabs Electron Release for Content Security.
Any news about the availability for a Linux build ?
I've not heard anything new on this topic yet, but I'll make sure to bring it up with Widevine again to check the status.
I talked to my Widevine contacts about this and here is the thing: They believe Linux is not currently a large enough Electron platform to warrant spending the time required to make the required additions to the CDM, so it has been put on ice for now.
If you, or anyone, thinks differently I encourage you state your case, either here, so that I can refer to the discussion, or by making the case directly with Widevine (which is likely to give a more immediate response). If enough interest and/or potential usage numbers is shown perhaps they will reconsider.
Bumping this issue. Chromebooks are rolling out support for installing Electron apps built for Linux, at which point I would expect to see the audience for Linux-built Electron apps increase substantially. We were planning on using this as a solution for delivering our widevine-based electron application to a large percentage of our enterprise users, who are standardizing on Chromebooks.
Hi @pix-dgee,
I'll forward the relevant information to the proper people. This use-case of yours, does it entail offline license support?
Support for offline licenses is something that is currently on our long-term plan, but has not yet been added to any internal roadmap. We offer this capability on iOS, so long-term we would want to have feature parity on our Electron-based desktop offering.
FYI, I added experimental Linux x64/ia32 builds of 3.0.2-wvvmp today. Because of the limitations on the Linux version of the Widevine CDM (no VMP/StorageId) persistent licenses are not supported, but scenarios with online streaming of Widevine protected content are.
Thank you for the support of the Linux platform. Could we expect that VMP/StorageID will be supported by Widevine CDM in the near future?
Unfortunately, no, this is not something that will happen in the near future. In fact, Widevine has not committed to supporting VMP on Linux at all at this time. Unless this changed very recently they are still citing the "too small user base" as the reason.
After making our initial Linux release I found out that the ia32 version of the CDM for Linux is deprecated as well, so support for that will go away at some point going forward.
@khwaaj
We have the use-case for Linux box with offline license. This is for digital classrooms.
There are 30k+ classrooms we want to roll out this solution.
Plus we also want to launch it in B2C channel for students.
Noticed the thread last year where status was it would be available in 2nd half of 2018, but missed to followup. Now was looking for update & realized it did not get enough userbase to support
So bumping the issue bigtime.
I urge other watchers to reply to thread with their usecase
Hi,
i would like to bump this thing as well, as the issue started more than 2 years ago. My company reimplements an terminal for patients in hospitals with electron, running on ubuntu machines. In particular there are currently 2000 devices running on an deprecated platform. We are still in an early prototype stage. One of the requirements is to provide a browser, the user may use to either browse the internet as well as watch netflix, amazon prime and other services like this. The terminals are connected to the internet at any time and no offline content will be viewed. The perfect solution would be to use ECS and i verified, it plays netflix and prime flawlessly. However the documentation states, that like this, the app runs just with an UAT (development) certificate and most providers aren't even supposed to work with this license. Am i able to sign the app upon startup due to the lack of persistent certificates? I already tried to sign the app package but obviously, the EVS doesn't support my linux build. It is pretty tough and intransparent, how all certificate/licensing abilities work together.
Kind regards.
HI Klaus,
First, to clarify a couple of things: Google does support a browser Widevine CDM for Linux, however, that CDM does not support VMP. We are using this CDM in ECS releases for Linux, but those releases are not VMP-signed at all (it would be pointless without the Widevine CDM supporting VMP). This is also why Netflix, and other streaming services, actually work on Linux, out of the box. Many services implementing Widevine DRM proxies have opted to forego the VMP requirement, specifically for Linux clients, to allow them to stream Widevine protected content. This does not extend to persistent licenses though, so there is a limitation there that prevents implementation of persistent downloads with completely offline playback.
As the case you stated above does not require persistent licenses, you should be fine using ECS, at least as long as the required services keep the exception for Linux clients. Keep in mind that the same restriction exists for Chrome on Linux, so disabling the exception would alienate all of their Linux users, which is why I find it unlikely this will happen anytime soon.
I can understand this all seems unintuitive, and clearly less than ideal, but it is what we have to work with. Google has not committed to add VMP support to the browser CDM for Linux since they feel the platform is just to small to put the required resources into, and they still stand by that decision today. I'm not sure what it would take to change their minds, but from what I've heard it would likely require a push from a major actor (or actors), I'm guessing with many millions of users, for them to even consider VMP for Linux again.
Hi there! So just to clarify, how exactly can we use the castlabs solution for a Linux electron build either with or without using the VMP signing service?
Compared to a mac/linux build that is taking advantage of the castlabs_evs.vmp signing service, how would I go about creating a non-vmp build for Linux that still gains the required permissions, etc for Widevine supported materials?
You don't need to do anything special on the client side, i.e. just using ECS as-is without doing the extra VMP signing step is enough. The basic limitations are:
- Persistent licenses are not supported, only streaming licenses. This means implementing true offline support is not possible since you would always need to get a license from the cloud.
- The service you are targeting needs to have an exception for Linux clients that allows them to get a license without a VMP signature (i.e. PLATFORM_UNVERIFIED status). Most large services seem to have this exception in place, but I don't have a complete picture to share. If you are building a service of your own you'd typically be able to adjust the Widevine proxy configuration to support this.
Okay, so just to break it down even further:
When packaging for Linux, I must use the castlabs_electron version of electron, and at no point do I need to use the python evs signing service, i.e.
Python3 castlabs_evs.vmp sign-pkg "path_to_my_output"
And instead can start, package, distribute, etc my app while waiting for the widevine-ready event. If I try to access a service that contains an exception for Linux such as, for example, Netflix or HBO, it will work?
Yes, that is correct.