electron-releases: When packing apps for the Windows Store, Widevine is not correctly loaded

I think dynamic downloading of WidevineCDM is allowed in the Windows Store because of this:

https://docs.microsoft.com/en-us/windows/uwp/publish/store-policies#102-security

10.2.2 Your product must not attempt to change or extend its described functionality through any form of dynamic inclusion of code that is in violation of Store Policies. Your product should not, for example, download a remote script and subsequently execute that script in a manner that is not consistent with the described functionality.

That is, as long as you don’t include code which changes described functionalities, you are ok.

On the other side, IMHO downloading Widevine in the home directory violates the principle at the beginning:

Don’t attempt to cheat customers, the system or the ecosystem.

Since it tries to circumvent the ecosystem concept of virtualization.

But my personal experience suggests that MS Store reviewers are usually open to exceptions if these are required to assure the app being able to work correctly

Starting with v5.0.13 it will be possible to override baseDir immediately instead of separately overriding downloadDir, installDir, updateDir and lastDir. It will also be possible to do this using the widevine-base-dir command line switch. This will roll out to v6 and v7 as well in the next release of each release series and should be the preferred way to move the Widevine CDM out of AppData in cases like this.

For example, to use the equivalent of %USERPROFILE%\Widevine\<APP-NAME> as the base path you could do:

app.verifyWidevineCdm({
  baseDir: path.join(app.getPath('home'), 'Widevine', app.getName())
});

Or:

app.commandLine.appendSwitch('widevine-base-dir', path.join(app.getPath('home'), 'Widevine', app.getName()))

@koenoe In case you wish to do everything from within electron, this is a way for accessing the above API: https://github.com/NodeRT/NodeRT

@khwaaj will test that when available. On 1903 the virtualization works roughly in this way: if an application module is started from within a virtualized folder, it will see a virtualized world where some dirs like the home folder / documents folder etc have a virtualized version that is in the exact same position of the not virtualized one. So if you can copy an .exe there, the starting program will see still see a virtualized world while the started one will see the not virtualized world. Virtualization is mostly used for avoiding messing up end-user systems with application.

(BTW this trick does not work in windows mode S (or how is it called now) and violates Windows Store policies)

That is just the thing, it won’t work inside AppData since the whole thing appears to be virtualized and the CDM can’t run from a virtualized location. I’m not sure if there is some other appropriate location to write the data instead, but using a completely separate directory, like I do above, does work when I run locally (using the POC provided by @delfinof).

If anyone has any good suggestions for an alternate location that is not virtualized please go ahead and make them… 😃