I’m not claiming the situation is just or should be ignored, but the option the author seems to be ignoring is to launch without Widevine. Sure, a lot won’t work, but a lot will. Having a vocal community can add a lot of pressure.
Yeah, but it's not a browser, it's a glorified media player.
Basically the dev wanted to take Electron (a wrapper of Chromium/v8, the Google maintained FOSS browser engine) + Google's Widevine, smash them together with some glue code and a special-purpose UI, and call it a "broswer".
Brave also started out this way—building a browser on top of Electron. [0]
Building something on top of the Chromium project is still building a browser. You're right that it's not building a rendering engine and JavaScript interpreter though.
... and Brave famously migrated away from building a browser using Electron, because of the security-implications (not to mention that Electron actively discourages it).
Building something on top of the Chromium project is pretty different than using and embedded version of its web engine.
In the case of a high-impact vulnerability, for instance, the time between committing a fix in Chromium and the user having an updated browser is obviously shorter than committing a fix in Chromium and making a release, waiting for the framework embedding Blink to update it's embedded engine and make a release, waiting for a "browser" built using an embedded framework to update its dependencies (including the new version of embedded framework) and pushing a new release to end users.
> and Brave famously migrated away from building a browser using Electron
Is that relevant? Do you think that Google was going to refuse to license Widevine and then Brave made the migration to CEF and they said, "now we know you're serious"?
It's not user security that's causing Google to refuse to license Widevine to this project. The response Google gives is not, "I'm sorry but we're not supporting an Electron solution like this", it's "I'm sorry but we're not supporting an Open Source solution like this."
In fact, if you read the full email exchange, the suggestion that the Widevine licensing team gives is to move to a proprietary Electron fork that will be even slower to receive security patches than the upstream codebase would be. So it's definitely not the Electron/security part that Google is upset about.
Yes, it's relevant – they migrated from Electron because of the security-issues associated with building a browser in Electron specifically. Meaning: it's relevant because it's particularly insecure, and a bad idea to implement a browser inside a browser (which is what you do when you develop a "browser" in Electron, implementing GUI using web-technologies).
And they didn't migrate to CEF (which is another embedded framework), but built Brave on top of Chromium AFAIK.
As you can see linked [0] in another thread here, what I'm describing above makes sense in the context of Google blocking anything that's implemented in an embedded framework (e.g. Electron, CEF, webviews) which does not use browser-based OAuth authentication.
I agree – The suggestion you mention doesn't make any sense from a security perspective, but from a purely functional perspective it would seem to solve the problem at hand.
And while I agree that the end result is bad, I frankly find it weird to complain that Google won't just fork over their proprietary DRM-implementation on someone else's terms. And it's not very surprising that it's closed source, or handled this way; It's typically how DRM works, after all – which is why the inclusion of DRM in webstandards was widely debated in the first place.
The Widevine team themselves suggested building the same exact system on top of a proprietary Electron fork.
> The Castlabs Electron implementation would be your only path of support. Otherwise, we don't have the resources to support at this time.
So Electron is not the reason this request was denied.
You're not wrong that Google is blocking login from embedded webviews, but the thing is that Google is separately blocking logins from embedded webviews. It's a different situation that's unrelated to their Widevine licensing. If what you were saying was correct, then the Castlabs Electron framework[0] wouldn't have Widevine support, and it does.
It's not about embedded engines, it's about Open Source.
----
> which is why the inclusion of DRM in webstandards was widely debated in the first place.
My take on this is that you would be right -- it would be weird to complain about Google refusing to set up a licensing scheme for Widevine -- if not for the fact that:
A) they were a part of the campaign for DRM inclusion in the first place, even while people argued that it would hamper browser innovation, so the problem we're in is in no small part their fault,
B) the fact that they control both Widevine licensing and the dominant desktop browser (and the fact that they have used that control to harass even mainstream browsers like Brave[1]) constitutes something at least adjacent to anticompetitive behavior,
and C) the fact that they're willing to license Widevine to Open Source browsers like Brave and Firefox suggests that there isn't a fundamental problem with Open Source that means it couldn't interact with this DRM in a way that's acceptable to Google.
Add those 3 points together, and I feel like it's reasonable to ask Google what they're doing and why they're doing it, and to expect them to have some kind of answer as to how they're going to maintain control of Widevine without cutting off the legs of browser innovation and using web standards to shut out competitors.
The point of his browser is to be able to playback Netflix, Hulu, etc. between browsers in sync. That can't be done without DRM, and Widevine is "the only available DRM for a Chromium-based browser, especially so for Electron."
> As far as I’m aware, Widevine is the only available DRM for a Chromium-based browser, especially so for Electron.
But according to this [0] the Chromium-based Edge browser supports both Google's WideVine CDM and Microsoft's PlayReady CDM. Not sure if it's really any help, but that's a different question.
At the time of the article, Chromium Edge hadn't been released yet with PlayReady CDM integrated. The followup article I wrote elaborates on these options further.
Or literally use the header files for the widevine blobs freely available in the chromium sources to directly use the API exported by the .so...
... and then get sued for illegally calling a few exported methods on a shared library you freely downloaded from the internet (but without first obtaining a license from Google!).
And by the way, I wasn't kidding about the freely downloadable from the internet part, when you open Netflix in Firefox, the browser downloads and loads a shared library from a Google domain: https://dl.google.com/widevine-cdm/${WIDEVINE_VERSION}-linux...
As per https://gist.github.com/ruario/3c873d43eb20553d5014bd4d29fe3..., which is still used by certain browsers and unofficial clients like the inputstream kodi extension to play netflix videos.
If you're on arm, an entire chrome OS image is downloaded instead, extracting the compiled widevine shared library.
Aside from being illegal, defeating the various layers of obfuscation and extracting the private keys requires a very particular set of skills, beyond the reach of most programmers. And then they'll just rotate the key and add more obfuscation, once they're done suing you out of existence.
