[HN Gopher] I tried creating a web browser and Google blocked me...
___________________________________________________________________
I tried creating a web browser and Google blocked me (2019)
Author : gu5
Score : 330 points
Date : 2021-01-20 18:13 UTC (4 hours ago)
(HTM) web link (blog.samuelmaddock.com)
(TXT) w3m dump (blog.samuelmaddock.com)
| oscargrouch wrote:
| DRM is the new ActiveX
| CobrastanJorji wrote:
| 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?
| eivarv wrote:
| Binary blobs (i.e. not open source) ?
| benlivengood wrote:
| 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.
| teclordphrack2 wrote:
| DRM is just encryption. It being open source and everyone
| seeing what math is used is only going to make it stronger.
| CobrastanJorji wrote:
| 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?
| fctorial wrote:
| They'll need to implement some kind of signing mechanism, or
| the users will just plug in a modified blob that pipes the
| output to a file.
| commandlinefan wrote:
| I was hoping it was going to be an actual created a web browser,
| rather than another Chromium or Webkit derivative.
| Havelock wrote:
| 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.
| eivarv wrote:
| This. Brave famously migrated away from Electron because of the
| security implications of that approach.
|
| Also, it kind of makes sense: You'd effectively be implementing
| a browser (or the GUI thereof) in a browser.
| inopinatus wrote:
| if the underlying language were Lisp or Smalltalk then
| implementing it thus might be a rational shoo-in.
| eivarv wrote:
| 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.
| SubiculumCode wrote:
| Am I wrong, but is this more evidence of monopoly power by
| Google?
| SubiculumCode wrote:
| Thanks for the downvote, but imho, I'd prefer a reply as to
| why.
| guyzero wrote:
| It's not that.
|
| 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.
| supermatt wrote:
| 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.
|
| There is an ongoing EC investigation.
| Hnsuz wrote:
| Google read your emails and recognizer that you became threat to
| them. That's Google way of dealing with competition. You get
| banned from play store also very quickly.
| pwinnski wrote:
| Google's commitment to open source stops at their profit's edge,
| yet again.
| folkrav wrote:
| 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.
| skinkestek wrote:
| 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.
| adamc wrote:
| Business commitment to much of anything tends to stop there.
| That's what businesses are about.
| varispeed wrote:
| If you are a business I'd check if in your country there is a
| body that deals with anti-competitive behaviour and make a
| complaint.
| gu5 wrote:
| I'm not the creator of this web browser, probably should
| clarify that. https://news.ycombinator.com/item?id=19553941
|
| Edit: Title changed from "I tried creating..." to "Someone
| tried creating..."
| [deleted]
| dang wrote:
| "I" in the title refers to the article author, not the HN
| submitter, so there's no need.
|
| If you really want to differentiate that, you can put the
| entire title in quotes, but I think that's overkill here.
| oscargrouch wrote:
| Speaking of DRM.
|
| 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.
| 1vuio0pswjnm7 wrote:
| I do not want a "web browser" that is also a video player.
|
| We need more "web browsers" that just browse HTML.
| fctorial wrote:
| lynx links w3m
| 1vuio0pswjnm7 wrote:
| You forgot W3C's libwww and the "www" browser. Supports
| HTTP/1.1 pipelining, which curl does not, nor wget.
|
| Why not more. I'm a satisfied links user, but would like to
| see more choices.
| tyingq wrote:
| 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.
| kmeisthax wrote:
| 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.
| fctorial wrote:
| What capabilities does the DRM blob running in a browser have?
| Wowfunhappy wrote:
| 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.
|
| ----------
|
| + Among others, I don't use any one source.
| Minor49er wrote:
| You should check out Bandcamp for DRM-free music. It's an
| excellent platform
| kmeisthax wrote:
| 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.
| est31 wrote:
| > It specifies no standard DRM
|
| 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.
| Wowfunhappy wrote:
| Whoops, I was getting Widevine and EME confused! Thank you
| for the correction, I've edited my comment.
| jonas21 wrote:
| 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.
| mr_toad wrote:
| "I created a browser and Netflix blocked it" isn't as baity a
| headline.
| tracedddd wrote:
| 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.
| coldtea wrote:
| 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".
| smaddock wrote:
| 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.
|
| [0] https://github.com/brave/browser-laptop
| eivarv wrote:
| ... 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.
| sneak wrote:
| They could also reverse engineer the Widevine module binary and
| reimplement it in their own project.
|
| You don't really need Google for this.
| danogentili wrote:
| 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/3c873d43eb20553d5014bd4
| d29fe3..., 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.
| gu5 wrote:
| And then get a DMCA request which takes down your Github
| repo.
| swiftcoder wrote:
| This is, unfortunately, explicitly made illegal by the DCMA
| Anti-Circumvention Provisions.
| anthk wrote:
| DMCA has interoperatibility exceptions.
| SubiculumCode wrote:
| Better have a good team of lawyers though.
| hirundo wrote:
| 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."
| MaxBarraclough wrote:
| I believe that's mistaken. From the article:
|
| > _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...
| jsnell wrote:
| Original discussion (612 comments):
| https://news.ycombinator.com/item?id=19553941
| julienfr112 wrote:
| That will end badly for Google with antitrust in the EU and in
| the US.
| atarian wrote:
| Not sure if this is covered under Widevine, but Google also
| blocks anything that is not a major browser from logging into any
| of its services.
|
| https://security.googleblog.com/2019/04/better-protection-ag...
| AndrewUnmuted wrote:
| 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.
| closeparen wrote:
| Phishing is accessible to anyone with basic web development
| skills, while JavaScript sandbox escapes for major browsers
| are the domain of pretty sophisticated actors.
| butt_hugger wrote:
| You are correct. This is just for Google's benefit, as you
| can imagine. They are Google, after all.
| _jal wrote:
| 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.
| kmeisthax wrote:
| 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.
| eivarv wrote:
| 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).
| schoen wrote:
| 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.
| judge2020 wrote:
| It's pretty warranted when this is the type of attack possible:
|
| https://news.ycombinator.com/item?id=25717156
|
| See the comments for a summary and why the submission was
| flagged.
| kevin_thibedeau wrote:
| It's also a glaring ADA violation.
| judge2020 wrote:
| https://www.google.com/accessibility/products-
| features/#!#ch...
| eivarv wrote:
| 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."
| LeoPanthera wrote:
| That's not correct, as Konqueror and Falkon browsers are also
| blocked.
| eivarv wrote:
| I'm just summarizing what the linked article actually says.
|
| 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)#F
| ramewo...
| lights0123 wrote:
| Nice for Google to block the project that wrote the
| origins of their browser engine.
| eivarv wrote:
| 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.
| pessimizer wrote:
| KDE-projects like Konqueror and Falkon, the subjects
| under specific discussion?
| Drdrdrq wrote:
| I think they are talking about Konqueror, not QT.
| Konqueror is what KHTML was developed for, iirc.
| eivarv wrote:
| Ah, right. Thanks!
| magicalist wrote:
| > _Nice for Google to block the project that wrote the
| origins of their browser engine._
|
| In this case it's blocking the embedded Blink, which _is_
| their browser engine, so at least they 're consistent?
| djxfade wrote:
| Yeah, Blink, which is a fork from Safaris WebKit, which
| is a fork of Konquerors KHTML. Google Chrome wouldn't
| exist today if it wasn't for Konqueror.
| magicalist wrote:
| yes, that's what the "consistent" was referring to...
| ocdtrekkie wrote:
| 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.
| smt1 wrote:
| I'm guessing the DRM has in effect has to be protected from
| the Russian and Chinese, both of who use forks of the _open
| part_ of Chromium. Even servo doesn 't have support for
| Wildvine, unlike gecko.
| eivarv wrote:
| 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.
| thethimble wrote:
| 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.
| judge2020 wrote:
| 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.
| underseacables wrote:
| Why aren't there more browsers? Is it just a matter of all the IP
| tied up by the majors?
| skrowl wrote:
| It's trivial to create a browser that's just a Chromium fork.
|
| It's nearly impossible to create one that isn't. Firefox (and
| Tor) is basically the only one.
|
| https://alternativeto.net/software/google-chrome/
| at-fates-hands wrote:
| 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.
| flagrant wrote:
| > 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.
| varispeed wrote:
| It's just enormous amount of work if you want to do it from
| scratch. It is simply impossible to afford for any small
| business.
| newdude116 wrote:
| Nah. You could do me a favor and get this thing her back to
| work https://www.uzbl.org/
| dmitriid wrote:
| 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.
| msie wrote:
| Heh, you're better off designing a new markup language and
| then implementing a browser to render that.
| Minor49er wrote:
| Given the current state of the web, this might not be a bad
| idea
| ufmace wrote:
| 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.
| annoyingnoob wrote:
| 1. Its hard. 2. No one will pay for a browser.
| fludlight wrote:
| The existence of open source software suggests there are
| other factors.
| annoyingnoob wrote:
| Such as?
| fctorial wrote:
| I think the OP wanted to say that there are large,
| complex, high quality community driven software projects.
| annoyingnoob wrote:
| 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.
| ttt0 wrote:
| Too many standards to follow, too many APIs, too complicated.
|
| Sometimes I wonder if the web standards aren't designed
| specifically to prevent any meaningful competition.
| ytpete wrote:
| 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 :- /
| shuntress wrote:
| Web standards are designed for cooperation not competition.
| coldtea wrote:
| 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").
| Leherenn wrote:
| (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.
| ttt0 wrote:
| 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.
| Devasta wrote:
| Web standards are whatever Google says web standards are,
| and will always be adjusted to whatever Chrome does.
| deckard1 wrote:
| 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.
| shuntress wrote:
| >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?
| kitsunesoba wrote:
| 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.
| folkrav wrote:
| Curious as to where Servo's gonna go from here, after the
| Mozilla layoffs... I'd really love for something non-Chromium
| to take off.
| judge2020 wrote:
| 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.
| ogre_codes wrote:
| 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.
| gspr wrote:
| Browsers are as complicated as operating systems these days.
| And far more monolithic, meaning the devlopment goalposts are
| spaced much farther apart.
| [deleted]
| paultopia wrote:
| 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.
| smaddock wrote:
| 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.
| danShumway wrote:
| 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.
| codemac wrote:
| https://thenib.com/mister-gotcha/
|
| 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?
| dang wrote:
| Discussed at the time:
| https://news.ycombinator.com/item?id=19553941
| Thaxll wrote:
| "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.
| coryfklein wrote:
| Users will balk if you call your application a web browser and
| it doesn't stream video from most of the major video providers.
| Thaxll wrote:
| 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.
| zucker42 wrote:
| > 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.
| Tepix wrote:
| DRM that Google controls
| Thaxll wrote:
| 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.
| smaddock wrote:
| 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].
|
| [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
| NetOpWibby wrote:
| 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.
| smt1 wrote:
| Right now, I think the focus has been on the GPU layering
| (see also: https://github.com/gfx-rs). Given the churn in the
| standards themselves (which is understandable since it
| requires buyin both from the hardware and software
| communities)
|
| I wish EdgeHTML had been open sourced.
| smaddock wrote:
| 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.
| heinrich5991 wrote:
| The link [0] still seems to work and redirects to
| https://github.com/castlabs/electron-releases/discussions/24
| for me.
| smaddock wrote:
| Oh! That makes sense, they must have moved it from Issues to
| Discussions. Thanks, I'll update the parent comment.
| speedgoose wrote:
| 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?
| smaddock wrote:
| I'm honestly not sure about the legality of downloading from
| another distributor. I do know that distribution requires a
| license [0].
|
| 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/+/maste
| r:t...
| bonzini wrote:
| Kodi downloads an entire ChromeOS image just to extract the
| widevine shared library, for example.
| zucker42 wrote:
| Potentially, there's a 5 year jail sentence for doing
| that[1].
|
| [1] https://www.law.cornell.edu/uscode/text/17/1204
| DelightOne wrote:
| > This is a closed source, downstream effort which means no
| modifications can be made to Electron itself.
|
| It has the MIT license since 2 months ago. Did the closed-
| source part change or is that only about the non-npm code?
| smaddock wrote:
| 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
___________________________________________________________________
(page generated 2021-01-20 23:00 UTC)