Tired of walled gardens and increased limitations of Chrome extensions, I'm building enough of the web extensions API to let me run them in my own desktop browser. Eventually I plan to build products from this project.
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.
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 intention was to build a media player based on a Chromium-derived web browser. Functionally it would playback content on Netflix, Hulu, and other DRM-enabled services.
The problem isn't the closed source nature of Widevine CDM, but rather that access to use it is rather difficult to come by.
DRM goes against the concept of an Open Web in which anyone can build a web browser without asking permission.
Blog post author here. Since this post, there's now an option available for DRM-enabled Electron. However, it's only available through a single vendor, castLabs [0].
This is a closed source, downstream effort which means no modifications can be made to Electron itself. All changes must make it upstream to show up in this fork. When asked whether they would eventually merge it upstream, they didn't provide a clear answer [1].
I also wrote a followup blog post with more detail on the current state of DRM options on the web [2]. Spoilers: it's not great.
Regardless of all of these problems, I still hold an interest in browser development and have been working towards making Electron a viable option for building a browser [3].
Did you consider to not get a license? You could perhaps download and execute Widevine pretending to be Firefox or Chrome. Is there advanced spying software in Widevine preventing to do that?
Surely there's no way locking down distribution this much helps anything or anyone if working around the terms is simply some minor tedium that can be automated.
The thing is he isn't circumventing copyright protection. He is just allowing it to play in his browser too, no downloading etc. I'm a legal noob, but there always was that "fair interests" like making stuff work on different devices/OSs (youtube-dl is hiding behind this a bit), would it not apply here?
The ambiguity here is why I said potentially. Does circumventing a technical measure mean to access the content without Widevine, or is using Widevine in an unintended way enough? However, the law quite clearly says that fair use doesn't matter; you can't break DRM even if you're not violating copyright.
Would it be legal if DRM is not shipped with the browser, but the user can download and install it separately (copy it manually to the browser folder)?
Let's rephrase: can you create a clone, a derivative work of a working OS browser, which only has DRM part not changed?
I'm not sure if you're asking for technical or legal advice. If legal, then since most of us are not lawyers here, strictly speaking we can't judge if "Hello, world!" program will put us in jail or not.
Thank you for creating a browser shell, maybe I can bring my browser project out of retirement. I just wish Chromium/Electron wasn't the only flavor (hence one of the main reasons I use Firefox). I had hoped Servo to be an additional option but alas.
I feel you regarding Chromium, I use Firefox as my daily browser. As for building my own browser, Electron/Chromium just seems like the most achievable option to empower individuals to create a browser.
The code included in the GitHub repository downloads the closed source Electron binaries. Just for comparison, the full source would look something more like what's accessible here: https://github.com/electron/electron
Thanks! I see it as unlikely that they will release the code, because castlabs also seem to have a business of auditing implementations for consideration for the widevine program: https://github.com/castlabs/electron-releases/wiki/EVS#3pl
Despite a fair amount of folks disliking Electron for replacing traditional desktop apps, I find it's a great fit for building unique web browsers.
I believe there's a lot of opportunity for making interesting web browsers, but building and maintaining them by forking something like Chromium or Firefox is a ton of work.
With Electron, it's possible to create something interesting with a team of one.
I'd love to see legislature go through a process like public GitHub pull requests. If we could create a culture similar to the best practices of code reviews, that'd be great.
- Keep changes limited in scope for easier review.
- Open the process to the wider public for inspection.
The intention here is that users don’t enter their password into an embedded web view where the host application can inject JS or otherwise sniff the password/session cookie. (or just phish them). That’s a good thing. A new standalone browser should be a separate case. Hopefully.
In an ideal world the Android/iOS framework would enforce that an insecure embedded webview has a distinguishing User-Agent or some other tell that Google can check. A standalone browser wouldn’t have that and in theory wouldn’t be caught up by Google’s enforcement of this. That’s how it should work, but it unclear to me if that’ll actually happen.
> A new standalone browser should be a separate case.
Right, but what are the chances google will allow people to sign up with their own user agent with their new browser engine? Or even if that was a feasible thing for them to do, why should _they_ be able to gatekeep that? The security argument is valid, but there should be some web standard or something to address that, not google deciding who gets to read their email depending on the browser they use.
It's tricky. Although this is being justified with references to phishing (which may well be the case) it's also an issue for spambots that need to sign in to a Google account in order to e.g. post spam links to YouTube comments.
If you think about it, you'll quickly end up in a briar patch of confusion over what exactly the definition of a "browser" is. Google have attempted to provide a definition here which is better than most, but it's basically a subtractive definition. A browser is a thing that supports "modern web standards" whilst not supporting automation features. OK. What about extensions?
The intent is to ensure that only people can sign in when they understand which site they're on. If anyone can define any program as a browser you can't enforce that and would have to allow unlimited automation of web sites. That is too hard to do, purely server side content analysis algorithms don't get you far enough, hence CAPTCHAs and now this JavaScript based enforcement.
The same system is enforced on sign up too, but the spam market is split between account creators/sellers and account users. So you need it everywhere.
Because of the asymmetry of use. Signing up takes a small amount of human labor, and there's already several sellers of fake accounts who use cheap human labor to create them. If actually sending spam would require human labor too, spamming would not be as desirable.
(For the record: I vehemently disagree with the idea of dictating what browsers are allowed to use an online service.)
The actual problem seems to be the UA string requirement (from the OP, at least).
If he removes the UA spoofing, all Google sites break because Google use this to determine if they run their services (which is incredibly weird to me).
If he doesn't, then his browser is banned. Somewhat of a double bind.
The most charitable explanation here is that Google is a megacorp now, and the right hand and left hand are on different continents and aren't aware of each others existence.
You're right that the issue described in the OP is more specific. However, I believe its a symptom of the larger, underlying problem.
Google shouldn't wield the power to decide which browsers are worthy enough to access the larger internet they have control over. It's antithetical to the open web.
Google literally has the keys to a kingdom. Should Google's box ever be opened, countries will burn. Let's face it, the definition of a monopoly is insufficient on a global scale.
Merely restricting their own sign-in service impacts over 1.5 billion people. Of course, most are unaffected.
Even Firefox has experimented with UA spoofing on Android because Google offers a severely downgraded experience even though the browser would technically support the same site that Chrome gets. So in the limited set of a dozen or so extensions for Firefox mobile, there is one that adopts the Google UA... The list was manually selected by Mozilla so you know their opinion on this.
Are they likely to whitelist Electron (and React Native and other major webapp-as-native-app frameworks)? Or will those apps be forced to boot you out to the browser, and then back to the app?
I think I've already seen one app that did that to me. It was clunky and broke the illusion that the app was native -- though I guess that's a pretty thin illusion anyway.
This is not a security feature. This is smoke and mirrors. If it was really about securing the web, Google would made IETF and W3C recommendations, instead of trying to kill competition. This is strictly market grabbing and anti competitive
In an ideal world we would have settled on an authentication protocol which everyone could support. Something like "oidc://idp-url" which the OS could have a built-in handler for.
