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