[coldtea]

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".

[smaddock]

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.

[0] https://github.com/brave/browser-laptop

[eivarv]

... 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.

[danShumway]

> 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.

[eivarv]

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.

[0]: https://security.googleblog.com/2019/04/better-protection-ag...

[danShumway]

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.

[0]: https://github.com/castlabs/electron-releases

[1]: https://github.com/brave/browser-laptop/issues/10449#issueco...