I tried creating a web browser and Google blocked me (2019)
blog.samuelmaddock.com
blog.samuelmaddock.com
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...
The risk doesn't seem worth it to use such a workaround for a serious project though.
[0] https://source.chromium.org/chromium/chromium/src/+/master:t...
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.
It has the MIT license since 2 months ago. Did the closed-source part change or is that only about the non-npm code?
how does that work with the fact that Blink (LGPL) is part of electron ?
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.
----------
† Among others, I don't use any one source.
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.
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.
• 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!
If I was writing this headline, I think I'd go with something like:
> "I tried building a better way to watch videos, but DRM stopped me."
Which is still pretty attention grabbing.
https://security.googleblog.com/2019/04/better-protection-ag...
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.
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.
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.
As for your examples, Konqueror and Falkon might be blocked because they use Qt WebEngine – which embeds Blink in the Qt framework [0].
[0]: https://en.wikipedia.org/wiki/Blink_(browser_engine)#Framewo...
In this case it's blocking the embedded Blink, which is their browser engine, so at least they're consistent?
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.
https://news.ycombinator.com/item?id=25717156
See the comments for a summary and why the submission was flagged.
> 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.
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.
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.
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.
Also, it kind of makes sense: You'd effectively be implementing a browser (or the GUI thereof) in a browser.
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.
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.
There is an ongoing EC investigation.
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.
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.
Buy a Blu-ray player and watch it on their TV.
Like it or not the market to watch blu-rays on a computer is basically zero at this point.
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.
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.
why not?
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.
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?
Occasionally this creates a problem that people notice. For example see https://www.macworld.com/article/3116414/oops-you-cant-play-... for one of them.
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.
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".
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.
Not so misleading IMO.
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?
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.
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.
Edit: Title changed from "I tried creating..." to "Someone tried creating..."
If you really want to differentiate that, you can put the entire title in quotes, but I think that's overkill here.
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.
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".
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...
> 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...
> 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.
[0] https://github.com/google/shaka-player/issues/2492#issuecomm...
https://blog.samuelmaddock.com/posts/the-end-of-indie-web-br...
You don't really need Google for this.
... 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.
Also I'd encourage you to contact the owners of the repositories listed in Google's DMCA notice against the Widevine cryptographic key and help them file a counter-notice. https://github.com/github/dmca/blob/master/2020/11/2020-11-0...
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.
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.
It's nearly impossible to create one that isn't. Firefox (and Tor) is basically the only one.
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.
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.
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...
Sometimes I wonder if the web standards aren't designed specifically to prevent any meaningful competition.
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?
That would be if Google cared for developers/users.
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.
Somewhat related discussion: https://news.ycombinator.com/item?id=23161922
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.
https://drewdevault.com/2020/03/18/Reckless-limitless-scope....
Summary quote:
"It is impossible to:
* Implement the web correctly
* Implement the web securely
* Implement the web at all"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).
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.
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.
or re-implement a Widevine-compatible plugin outside the US where DMCA doesn't apply
of course, say goodbye to ever setting foot on US soil again
We need more "web browsers" that just browse HTML.
Why not more. I'm a satisfied links user, but would like to see more choices.
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.
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 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?
RMS and anyone could implement a dumb grep from within GNU ed easily.