71–80 of 194 posts
Earlier quoted context omitted.
They could also reverse engineer the Widevine module binary and reimplement it in their own project. You don't really need Google for this.
This is, unfortunately, explicitly made illegal by the DCMA Anti-Circumvention Provisions.
We need more "web browsers" that just browse HTML.
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 ans…
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 ans…
Earlier quoted context omitted.
Nice for Google to block the project that wrote the origins of their browser engine.
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.
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-encu…
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 ans…
Earlier quoted context omitted.
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…
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.
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-encu…
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 standardi…