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
Isn't this just how DRM works? It's precisely why so many were concerned about EME being adopted into web standards, and why so many are passionate about DRM-Free media. DRM is designed to put restrictions on where, when, and how media is played, including what software it's used with.
This doesn't invalidate any of the author's points, and they're right to be upset. But the problem isn't Chrome per se, it's DRM-encumbered media.
And that's why I buy audiobooks from Libro.fm†, games from GOG†, and (out of necessity) movies and TV shows from iTunes—which are still DRM'd by default but are at least relatively easy to decrypt.
Strictly speaking, Widevine isn't a standard - the web standards tracks really don't allow for it. Hell, they couldn't even agree on a single baseline video standard. The only part of web standards that even covers DRM is EME, which just specifies a way for JavaScript to negotiate content decryption with a DRM plugin. It specifies no standard DRM, and it can't do that, because DRM by it's very nature is not standardizable - or, more specifically, standardized DRM is ineffective. You can totally write video DRM in JavaScript using Media Source Extensions. You'll just have no actual technical control over where the video goes after it's been decrypted; that's why they want compiled binaries that have to be distributed as browser plugins.
The w3c spec does specify the clearkey DRM plugin as mandatory to implement, but as the name says, the encryption keys are not hidden in any fashion from users, so most deployments use one of the proprietary plugins.
Yes, perhaps the lesson here is that one should do some basic investigation on whether an approach has any fatal flaws before spending 2 years working on it.
I think I agree, harsh as it may be. But that doesn't mean the author's complaints are illegitimate—they're just a tad misplaced.
DRM hampers innovation and creativity in all sorts of ways. It locks users into specific platforms, and prevents anyone else from leveraging those platforms to build improved or entirely new experiences.
I'm not sure if this is still the case, but I remember when the Oculus Rift and HTC Vive were new, a lot of people were disappointed that they couldn't watch Netflix in a virtual theater (in high quality). The DRM made it impossible.
Thanks for the link to Libro.fm; it looks like a great initiative. Unfortunately, for a lot of titles I'm interested in, I get this message: "You appear to be accessing the site from a country where this title has restricted rights". Do you know of a similar audiobook provider for the EU?
Unfortunately I don't. What I can do is list all the services I know of which sell DRM-Free Audiobooks in the US:
• Libro.fm
• Downpour.com
• Audiobooksnow.com (Check for a "Downloadable" icon, a very small number of tiles without it have DRM).
• Google Play
I bounce between the first three of these regularly, based on price and availability. I've never actually used Google Play for audiobooks; they always seems to cost more.
Hopefully at least one of those has better offerings in the EU!
Thanks for that list. I only got into listening to audiobooks last year when I started walking a lot more (due to Covid-19 restrictions). My local public library had a deal with Bolinda where library members could rent audiobooks at no cost. The catch is that (due to artificial scarcity), the user usually has to wait a couple of months before the title they're interested in becomes available. It turned out that Harry Potter and the Philosopher's Stone was immediately available so after listening to that, I continued with the rest of the series. When I became too impatient to wait for the next title to become available, I was able to purchase non-DRM MP3 files from JK Rowling's own site, Pottermore.
A more precise wording might be "... Google also blocks anything that's implemented in an embedded framework (e.g. CEF, webviews) and does not use browser-based OAuth authentication."
The problem is a web browser is arguably something which has a webview in it. The difference Google considers between "a browser" and "an app embedding a webview" is whether that app is specifically Chrome, Firefox, Edge, Safari, or IE.
There is another, arguably legitimate differentiating feature:
How up to date the embedded web engine is (and how quickly you would be able to merge upstream changes, update the framework, wait for "browsers" implemented using the embedded framework to update their dependencies, etc.)
That can be a pretty big deal when there's a fix for a high-impact vulnerability.
There's another security consideration here: whether you trust the webview not to peek at your https content.
With a known browser, you get reasonable guarantees that TLS is being handled properly. With an unknown browser, these guarantees are gone. Considering the average person has no idea what https/TLS is, banning all unknown browsers as a defense against phishing seems completely reasonable.
HTTPS isn't even the largest concern - it's the browser being some malicious app asking to 'sign in to Google to load your profile' and stealing either the password or auth token.
What's frustrating (and clearly anti-competitive) is that Google thinks this is a problem enough to justify this, but refuses to ban browser extensions that utilize permissions broad enough to allow them to do this in Chrome directly. Browser extensions can generally collect everything on web sites and that you enter into websites, and has access after all TLS decryption has occurred.
For the most part, if a browser's extension store isn't in order, everything else they claim to do to secure web traffic is kinda a joke.
The Qt project didn't write the origins of Google's browser engine.
Blink forked from Webkit, which started as a fork of the KHTML and KJS libraries from KDE. Many KDE-projects are built upon Qt, but Qt is an independent project.
"We're perfectly accessible as long as you switch web browsers to the one we make" is probably not going to cut it by ADA standards if someone pushes hard enough. Chrome isn't a 1:1 drop-in replacement, and it may not be available on some devices.
Sorry to go off-topic slightly, but can any INFOSEC people confirm that this idea below makes any sense? The conventional thinking, as far as I am aware, has always been that JavaScript increases your attack vector and diminishes your security coverage.
> Last year, we announced that we would require JavaScript to be enabled in your browser when you sign in so that we can run a risk assessment whenever credentials are entered on a sign-in page and block the sign-in if we suspect an attack. This is yet another layer of protection on top of existing safeguards like Safe Browsing warnings, Gmail spam filters, and account sign-in challenges.
I think they're looking at two different notions of security: security of Google's services against bots (which is probably what Google is trying to check with Javascript), and security of users' browsers against malware (which is an attack surface that can be limited by turning off Javascript).
It might be like thinking about whether a "TSA lock" increases security. One might say that it increases security because it allows TSA to check the contents of people's belongings more easily, or that it decreases security because it can allow anyone with brief physical access to a bag to steal its contents.
Edit: the sibling comment also points out a likely use about recognizing your own devices. If you let Google spy on you more, it can more accurately determine what is usual or unusual for you, in order to distinguish you from an impersonator. You might also not want Google or others to have this information.
Dirty little secret: when software vendors speak, they will frequently blur the purpose of a given security measure and who, exactly, it protects.
This measure helps protect Google. And much like a politician stretching the definition of the national interest to include themselves, Google might say that they're protecting you by protecting themselves.
If Google can use this to rate limit sign-ins more effectively, then it does protect users, since the limiting factor on password security is time to crack.
I want the ability to change these types of settings for my account. They can be buried in an advanced menu somewhere.
I have a password manager. My Google password is a long, unique string of random characters that I don't use on any other service. If someone does break into my Google account, it will be because they broke into my password manager and/or successfully phished me (or hit me on the head with a $5 wrench). Number of retries will have nothing to do with it, unless they have a computer from the future.
I am much more concerned about Google locking me out of my account some day in an attempt to stop someone from breaking in, then I am about someone else actually breaking in.
There's probably more here, but one thing I can think of is fingerprinting the client as part of the automated risk assessment, deciding whether and when to block attempts, trigger MFA, and recognize specific devices (and potentially tie them to specific users for whatever reason).
Phishing is accessible to anyone with basic web development skills, while JavaScript sandbox escapes for major browsers are the domain of pretty sophisticated actors.
Regardless of the discussion, Electron browsers are very insecure and is not a stable foundation to build a browser on. Electron even recommend that you do not try and build a browser using it.
I don't know. Implementing a browser in a browser can make XSS potentially bad, and I think it even lead to full on RCE in the earlier days of Brave/Electron. Still happens, I think (though to a lesser extent these days).
There's also the difference in time between committed patch and end user having a new release in the case of a critical vulnerability, for instance.
Using an embedded browser framework introduces many intermediate parties, some (many?) of which might not have being up to date with the upstream as a priority – which leads to a weakened state of security in the "browsers" downstream.
I had the same problem. After a couple of emails, I got completely ghosted. They simply do not respond.
Seems that google pushed hard for EME, under the guise of giving widevine to anyone who wanted it. Of course, as is evident from OPs situation - this isn't the case.
DRM is fundamentally incompatible with open source and free software. DRM is all about restricting what your computer can do (what code it is allowed to run), so it can be trusted by third parties with handling protected information. Content providers want to be able to trust your computer in not allowing you to have full control of what it does.
If users can execute their free software rights (modify software and run modified versions), they can instruct their computers to do anything, thus DRM would not be possible. Binary blobs like Widivine are not complete DRM solutions on systems where users can still modify their display server or kernel. As DRM gets more widespread, content providers will require more strictly locked systems, that's why mobile devices are shipped with locked bootloaders and PCs have secure boot and TPM — most current hardware is ready to support strict DRM.
The only approach to DRM is to boycott its use completely, there is no workaround or compromise.
>> The only approach to DRM is to boycott its use completely, there is no workaround or compromise.
I couldn't agree more.
DRM is a plague that needs to go away. Digital content producers use it in the hopes it'll deter piracy, but the truth, as clearly shown by GOG.com, is that DRM is pointless. If your software and content are reasonably priced and worthwhile in some way, people will buy it.
I recently looked into what it takes to play 4K Blu-ray UHD discs natively, and its fucking laughable. A specific Intel-only CPU, only certain motherboards, certain monitors that support certain specs... OR you could just download an .mkv from some torrent website that plays flawlessly...
Which are people more likely to do? Instead of potentially adding 1.5 billion Windows users to the pool of available 4K UHD Blu-ray customers, they made it so fucking annoying that it practically guarantees piracy. Nice job breaking it, Hero.
"I tried creating a web browser, and Google blocked me"
Title is very missleading, your web browser works and google does not block you, it's all about DRM.
"For the last 2 years I’ve been working on a web browser that now cannot be completed because Google, the creators of the open source browser Chrome, won’t allow DRM in an open source project."
This is crap, you should probably have known that before starting the project? As a dev it should be some common sense that you can't just playback 4k video from Netflix with a built-in Browser.
> Title is very missleading, your web browser works and google does not block you, it's all about DRM.
Google, Microsoft, and Apple effectively control access to DRM. They are acting as a cartel to prevent competitors. So, yeah perhaps it would be best to add Microsoft and Apple to the list of offenders, along with the MPA, and heck even Congress (which criminalized breaking DRM even for otherwise legal purposes). But I'd hardly call the title very misleading.
Regarding your second point, it's understandable that he focused on the functionality before the licensing, because Widevine would probably have been even less supportive if he had a working product. Honestly I don't understand your complaint; someone had to make a browser and get screwed over, otherwise the defenders of Google et. al would argue that Widevine could be licensed by competing browsers.
And anyways, these minute arguments completely ignore the overarching point that DRM subverts the premise of the web and prevents disruption and competitive.
Because if you can playback 4k video from Netflix with a browser under your control, then you can playback 4k video to a file and thereby create a cracked copy that can be pirated.
DRM is built on a self-contradictory premise that tremendous amounts of effort are going into making work. Namely, if we save content in a special format, then we can make it impossible for it to be used except as we decide.
However they then put that software on hardware controlled by people whose interests are not necessarily aligned with that goal. And once there, that software can be changed. That hardware may be an emulation that can also be changed. And so on and so forth.
To make the fiction appear to work, they need to find every way that they can to avoid escape. They add detection code that tries to identify running under emulation and blocks it. They obfuscate their software in every way that they can. They only place their software in other software that they trust. They embed various checks that nothing looks suspicious.
And even so, they are doomed to fail. See https://krebsonsecurity.com/2020/10/google-mending-another-c... for example. But they just need to make it hard enough to bypass the encryption that it is hard to get pirated copies. And make the penalties for trying to do so to discourage a pirate scene. And this they have done.
>Because if you can playback 4k video from Netflix with a browser under your control, then you can playback 4k video to a file and thereby create a cracked copy that can be pirated.
Can't you just record the screen to do this? Or split the signal in the cable or have the screen itself send the data on to another device. At the very least you can always just physically record the screen itself.
At the end of the day, you have to ask whether this is worth it. Does it actually help sales to offset the costs?
Why yes, you can. And so there is pressure on every single hardware vendor to do fancy handshakes to guarantee that it is only going to authorized places that will do authorized things with it. Exactly to make the bypass that you're describing harder to do.
At the end of the day, you have to ask whether this is worth it. Does it actually help sales to offset the costs?
Actually it doesn't matter what your belief is on that. In the end, Netflix believes that it does. And as long as they are where you buy the content that you want, that means you have to play by their rules. No matter how stupid you think that they are being.
Or they believe that their media partners, who license the media to Netflix, believe that it does. Or perhaps those media partners are members of the MPAA, which wants to take a hard-line stance and never do anything that looks like backing down, even if their own technical advisors say it's getting silly.
But, yes, whatever Netflix's reasons, those who buy from them will do so under Netflix's terms.
>Actually it doesn't matter what your belief is on that. In the end, Netflix believes that it does. And as long as they are where you buy the content that you want, that means you have to play by their rules. No matter how stupid you think that they are being.
I meant that Netflix and co have to ask this. Because it's pretty obvious that none of the direct anti-piracy measures have worked. What has worked is making content more accessible and providing other incentives to users for getting the media legitimately. I think Netflix itself is that type of advancement, but I guess they're looking to get more "marketshare".
There is a big difference between playing some mp4 / webm on a website and Netflix, if every random dev could implement a DRM for Netflix most likely DRM would be useless.
To be fair, given that anything that hits any streaming service is ripped and available to pirating within an hour, DRM has proven to be useless. It doesn't stop pirates at all but it does annoy actual paying customers.
The article being from 2019, I highly doubt that DRM was such a common issue in 2017, so much that you had to anticipate for it.
4k wasn't that common either.
For the reference, at the time, I believe Netflix was even using Silverlight.
And Google is the blocking entity here, because they are in charge of delivering licenses for Widevine, which is specifically what you need to play DRMed content.
The thing about titles is that they often give a summary. Of course it does not tell the whole story--but I don't think it's misleading nor do I think it's crap.
You're free to open a website that directly stream some mpeg ts without encryption, Google is not to blame, the people that actually want that are the publisher. Youtube does not use DRM fyi.
I'm no an expert on DRM, but maybe someone here is. What would open source programs using DRM look like? My understanding is that the whole point of DRM is to prevent the software and the user from having arbitrary control over the data, which is fundamentally opposite of open source.
Say that Google desperately wanted to support any reasonable method to accomplish allowing open source tools access to DRM-protected media. Is there some way to allow that? What would it look like?
DRM in hardware is about the only other possibility. Make the GPU do the DRM internally. This is actually relatively feasible since most DRM'd video content has hardware acceleration support and GPUs already support HDCP.
Full DRM in hardware would require a much larger coordination across manufacturers than any DRM to date (HDCP), and with AACS's key distribution problems greatly magnified. Specifically, preventing any software fallback would be required to avoid AACS's player key leaks.
Also if the hardware DRM ever gets broken, you've got to choose between breaking the device or getting content ripped.
By contrast with DRM in software and automatic browser updates, you can switch DRM schemes fairly easily. Which is not hypothetical - Google has had to fix Wideview multiple times.
But this needs both streaming and automatic updates. Without automatic updates, you can't depend on devices having the update. Without streaming, something like https://www.redfox.bz/en/anydvdhd.html will eventually emerge and people buying existing content will be able to bypass your control.
Sure, and maybe this is my lack of understanding speaking, but if you're free to edit the source, recompile, and then use the DRM software, why couldn't you just edit the source to save the video?
Would we see Intel/Samsung/IBM contribute to the Linux kernel if it wasn't in their self-interest? That's just how business tends to go as a general rule, IMHO. At least, I generally are more surprised to see a company go the extra mile than the opposite.
No, but there's a long time since those got to skirt regulations because they claimed they were not evil or did the right thing.
The problem with Google is it went from actual friendly actually competent giant to (somewhat) incompetent[1] giant monster[2] in one decade.
[1]: you might not agree, but come back when their own verbatim option works correctly over time: that hasn't been the case for a decade or so now. If they can't even get that right they are at least somewhat incompetent as a group even if every single one of them are brilliant.
[2]: Not because they want to be one or try to but this seems to be what happens with giant corporations. It is kind of like the AI paperclip machine: it optimizes (i.e. destroy) everything around it to make paperclips, or in Googles case: quarterly profits.
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.
There's a number of reasons, but one of the biggest is that it's impractical for an individual or small group to create a web engine that is capable enough that users will want to use it. This means the only options are to either fork an existing browser (as most Chromium forks are doing) or build a browser around an embeddable engine (as WebKit-based browsers do, and hopefully one day Servo-based browsers will).
For many interested in creating a browser, a new engine is one of the primary reasons for doing so, and so forking or embedding being the only option means that many who would've created a new browser don't, because from their perspective there's no point in a Chrome/Firefox/Safari clone with a slightly different coat of paint.
WebKit at least partially addresses the clone issue, making it easy for developers to write entirely new UI code using their toolkit of choice, but comes with the caveat of not receiving much attention on non-Apple platforms, which is a problem with browser security being so important.
Also, saying 'Chromium fork' is mostly untrue since these browsers almost always change stuff that's required (ie. changing the appearance, logos, chrome:// uri, and maybe solving some platform-specific bugs) then continue to pull changes from upstream Chromium with little intent to iterate on the core components of the browser or implement new standards. Brave is the one exception with IPFS support but that's it - not even MSFT did something like enabling PlayReady in chromium, it's straight widevine.
Much of the media playback IP is tied up by the big players. Who wants a browser without media playback?
Aside from that, how do you make money on a web browser? Without some kind of payback, it's pretty unlikely a browser project will get funding. Particularly since there are decent browsers on all platforms already.
Opera was originally based on the Presto layout engine from 1995-2013. Then it switched to being a Chromium based browser in 2013 so they could utilize the Chromium plug-in ecosystem.
The ecosystem is the big issue for a lot of these products. It why Microsoft's Windows phone failed so badly - they didn't have the app store to compete with or allow users to migrate to their platform without losing a lot of apps they already used on Apple or Android.
The ecosystem is a major reason why you don't see more competition.
> Then it switched to being a Chromium based browser in 2013 so they could utilize the Chromium plug-in ecosystem.
Opera switched to Chromium because they didn't consider it profitable enough to keep developing their own engine, and laid off a large portion of their browser developers. It was entirely about money and nothing to do with using Chrome extensions.
Google basically controls the "standards" now, and it has the resources to keep churning them endlessly while spreading propaganda about how much better the new features are and how everyone should use them --- because they're only implemented in its browser.
There are perfectly capable HTML4-level browsers like Dillo, NetSurf, etc. and a bunch of similar projects on GitHub (under elaborate yet non-browser descriptions such as "HTML viewer with CSS support".) If only people would stop drinking the Goog-aid and unnecessarily "app-ifying" sites, maybe we would have more browser diversity... after all, the majority of sites I use are from the "document web" and not the "application web".
Edit: downvoted for talking against Google, interesting...
Looking at the holistic picture (as anyone implementing an entire browser must), it's probably a stretch to say they're "designed" at all – web standards are a patchwork of almost archaeological layers built up over several decades. Even many deprecated bits must still be implemented to support the millions of websites users will want to visit. Backwards compatibility is hard :-/
This has never been true. We wouldn't have JavaScript if Netscape didn't go off and do their own thing. Netscape and Microsoft were locked in a fierce embrace-and-extend battle for the web. XMLHttpRequest wasn't even a standard when Gmail came out in 2004, and wasn't a standard until at least 2006.
Web standards merely describe the current world of web browsers and attempt to retroactively take credit for it.
>Web standards merely describe the current world of web browsers and attempt to retroactively take credit for it.
I'm not sure I understand what you mean here by "take credit" but, that aside, are you suggesting that it would have been easier for Netscape and Microsoft to cooperate (or for gmail to support both) without some standards?
Back in the day yes. Modern web standards upgrades are designed (a) because Google wants them, (b) for regulatory capture -- making it too difficult for a browser to be created (I'm abusing the term to refer to behavior regulated by "web standards").
(c) because they provide features requested by developers/users. Compare modern JS to JS from 10 years ago, it's pretty clear Google is not the only one benefitting from the new standards.
The question is cooperation between who exactly? A cooperation can turn into a collusion. And all I can see as members of these boards is a bunch of corporations, that are known for using underhanded tactics.
If we're talking about creating a browser from scratch, it's nearly impossible to implement one without a huge investment of both time and money. Browsers are unbelievably complex, and the new features are being added at such a pace that you need to run twice as fast just to keep up.
If we're talking about forking an existing browser, that is doable. But you still need a huge investment to understand, change and extend that code. Once again, browsers are unbelievably complex beasts.
Because a modern browser is about as complex as an operating system, and moves even faster.
Check out the complexity of ES6. You're gonna need an interpreter for that which performs acceptably well, plus a DOM interface to the rest of the browser. And check out how complex CSS is when it starts interacting with everything. Gotta handle all that too. Along with the basics of HTML structure, and how to interpret horribly broken HTML. And all of those pieces have to work together in realtime for dynamic animation, and do so fast enough for webapps to work and without eating too much of the host system's memory and CPU. And handle the constant addition of new JS APIs and how they have to interact with the host OS. Better be compatible and integrate well with Windows, OS X, and Linux too.
Building a new one from scratch today is pretty comparable to building a new operating system. You'd probably need to coordinate thousands of people working fulltime to get it off the ground. And it's basically impossible to charge any money for it, since all of the tech majors give away fully supported mature browsers for free.
In theory, you can fork an existing browser. But they all move so fast, keeping a fork with any useful changes up to date with the main browser is going to take a significant sized team too.
Microsoft is a tech giant, and even they decided to dump their independent Internet Explorer codebase in favor of using a Chromium fork. Now the only other truly independent browser codebase is Firefox's, and they haven't been doing so great the last few years.
It's probably practically impossible to build a browser that isn't a fork of Chromium these days.
My take-away from the post here is that to build a good browser you'll need to include some licensed bits. You might have a hard time incorporating those licensed bits into an open source project. Which sort of brings things back around to a business problem.
Google has announced that it is cutting off access to the Sync and "other Google Exclusive" APIs from all builds except Google Chrome. This will make the Fedora Chromium build significantly less functional (along with every other distro packaged Chromium).
That seems unlikely. Google is one of many providers in this space, it's unlikely that a sole trader could afford the liability provisions, and anti-trust doesn't really tend to stretch to "you're too small for me to bother trading with you."
Where are the relevant philosophical and legal debates around digital copy?
If we establish some common ground over copy, where balanced legal frameworks can grow, i bet things like DRM would be considered illegal.
It should be not be considered a reasonable legal path to be pursued against copyright infringement (which is a reasonable right).
And while we are at that, i see a lot of people mentioning
feeling betrayed by Firefox, while back in the day, i felt that it was Tim Berners Lee and W3C who stabbed me in the back with this.
Is in time like these that we see how important it is to have a guy like Linus (and all the contributors) behind important projects.
Corporations being pulled by the capitalistic strings are not suppose to look forward higher ethical things as the "common good".
Its not irrational that corporations do this kind of things, its irrational that we expect them not to, knowing the game that is being played here.
I'm curious what the gatekeeping around letting you use Widevine or similar does. As an "approved" entity are you then technically capable of copying DRMed content? Trying to understand if that's why it's so closely guarded.
Under DMCA 1201 technical protection measures automatically get legal protection against this sort of thing. There's actually two layers of protection:
1. You can't deprotect the content for a purpose that would violate copyright law (this is the "DMCA exception" process you hear about every 3 years)
2. You can't provide tools that deprotect the content for any purpose
Both provisions give DRM the force of law, though the latter poses specific risks for anyone who merely wants to run DRM content within it's protected bounds. There are loads of well-reasoned exceptions to DMCA 1201, but they're very restrictive and special-cased. You'd never be able to get away with just releasing a Widevine-compatible plugin, even if it did all the validation and security in exactly the same way as Widevine. This means that, practically speaking, the only legal way to actually play Widevine-protected content is to license Widevine and comply with the inevitable litany of restrictions they place upon you for access to that plugin.
I don't know if it's technically feasible, but a DeCSS type release would be fun to watch from the outside as everyone scrambles to close the barn door.
WideVine and PlayReady and FairPlay don't exist because tech companies want them, they exist because movie studios want them - or to be more precise, they demand them.
Chrome plays non-DRM video just fine. No studio in the USA will make their films available on a non-DRM encumbered service.
Wait, what is this person trying to do? They're not happy that Google open-sourced Chrome, so they also demand that Google open-source some DRM system so that they can make a media player for Netflix or something? Forgive me for not feeling sorry for someone who wants to make a browser polluted with DRM who complains that someone else is enforcing their copyright.
If your goal is that new browsers should only be able to be made without DRM, then you're effectively saying that we can't have any new mainstream browsers unless they're built by already established companies and commit to not doing anything creative or new that Google doesn't like.
I run Firefox without DRM support on my computers, and I believe that the web would be better today if DRM had never been forced into the standards process. However, ideology aside, if you want to make a browser that ordinary people can use, then it is unacceptable for that browser to not to play Netflix. DRM on its own is a threat to the Open web, but DRM that is only usable by a few big players is an even bigger threat to the Open web.
I would argue that we should be concerned when the largest browser on the market effectively has the power to decide whether or not websites will work on competing browsers. To me, that undermines the entire point of having web standards in the first place.
A bit of rant, but this is something that advocates warned about when DRM was in the process of being added as a web standard. It would be better if we didn't have DRM on the web at all. But at the very least, if we are going to have DRM, then there needs to be a consistent, accessible licensing model that allows any browser to interface with that DRM component. I'm sorry if Netflix has problems with that, but Netflix's current business model is not more important than the platform that literally created and enabled Netflix's currently business model. And companies like Google should not be allowed to decide who can and can't compete with them, it's anticompetitive through and through.
If you want a diverse browser ecosystem, then anyone building a browser should be able to interface with Widevine to play protected content.
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.
Yes, someone attempted to build a tool that was interesting to them, and ran into DRM related roadblocks.
Life is not all or nothing. Even GNU is a a matter of free software improving over time rather than a purity test. Do you really think RMS refused to run grep until it was FLOSS?
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].
[0] https://github.com/castlabs/electron-releases
[1] https://github.com/castlabs/electron-releases/discussions/24
[2] https://blog.samuelmaddock.com/posts/the-end-of-indie-web-br...
[3] https://github.com/samuelmaddock/electron-browser-shell