undefined | Better HN

0 pointseivarv5y ago0 comments

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

0 comments

danShumway5y ago

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

j / k navigate · click thread line to collapse