51–60 of 194 posts
Earlier quoted context omitted.
That's not correct, as Konqueror and Falkon browsers are also blocked.
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)#Framewo...
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".
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.
Earlier quoted context omitted.
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)#Framewo...
Nice for Google to block the project that wrote the origins of their 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.
Earlier quoted context omitted.
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)#Framewo...
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?
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?
Earlier quoted context omitted.
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.
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.
Google's commitment to open source stops at their profit's edge, yet again.
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.
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.
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...
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 ar…
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.
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.