Imagine if the Rosetta Stone was DRM crippled, or if Michelangelo had used DRM to 'protect' his work that was tied to a long since lost keyserver.
Today's digital media will never survive as long as the Rosetta Stone did, so that's no problem ;-)
Web DRM moves to next phase, Defective by Design to continue opposition
31–40 of 53 posts
Re: Web DRM moves to next phase, Defective by Design to continue opposition
#32Actually. I realized that any party that would want to put their content behind this kind of obstruction does not really have anything interesting to show anyway. So better of without that particular content anyway! Same with sites that block you when using Privacy Badger. Good riddance.
The danger will be in it becoming normal for everyone to use EME, or that the most used audio/video devices and tools will by default enable this and make it hard/impossible to disable it. So if you shoot a video of police violence with your phone and decide to publish it that it can be blocked by e.g. government. Of course, pushing for integrating this with your video camera will be done to protect the children.
Re: Web DRM moves to next phase, Defective by Design to continue opposition
#33There must be people who find this style of writing persuasive, but for me it has the opposite effect. The tone is so aggressive and slanderous that even though I should nominally be on the side of the author, I find myself thinking "surely there is another side to this story" and come away with the feeling that I should step back and consider that maybe the other side is in fact in the right. It's like reading angry…
This is a passionate issue, written from the perspective of a fierce activist. I participated in the march against DRM in March, and it's difficult to describe the powerful emotion bursting from the protesters, as well as Harry Halpin when he pledged his resignation should it pass.
But your perspective is important.
I encourage you to write to campaigns@fsf.org; I know personally that Zak and others will value your input.
Re: Web DRM moves to next phase, Defective by Design to continue opposition
#34There must be people who find this style of writing persuasive, but for me it has the opposite effect. The tone is so aggressive and slanderous that even though I should nominally be on the side of the author, I find myself thinking "surely there is another side to this story" and come away with the feeling that I should step back and consider that maybe the other side is in fact in the right. It's like reading angry…
Agreed, and I've just realized the reason why : 1) The portmanteaus are just annoying to read, giving me a negative feeling off the bat and I start searching for flaws to justify it. 2) The portmanteaus are in-jokes for the people who already agree with the author. This makes me think that the author is so focused on their own social bubble that they haven't seriously wrestled with a well-written argument by the othe…
I think one of us is confused. I don't see any portmanteaus in the linked article: https://www.defectivebydesign.org/blog/web_drm_standard_next...
Re: Web DRM moves to next phase, Defective by Design to continue opposition
#35The tracking of users enabled by EME is surely enough reason to reject the standard:-
Re: Web DRM moves to next phase, Defective by Design to continue opposition
#36W3C did this move because its biggest sponsors are the DRM makers (Google, Microsoft). To make it acceptable they made it optional. But in practice all major browsers implemented it. The right answer is now to standardized the W3C CDM black box by standardizing DRMs as ETSI has started ( https://lists.w3.org/Archives/Public/public-html-media/2014F... ). W3C should contribute to this effort. Useful link on EME: https:…
The ETSI thing doesn't solve problems. It creates a layer of abstraction that in theory makes the key acquisition protocol defined by whatever runs on the ETSI layer, but now you have the problem of remotely attesting the tamper-resistance of the ETSI layer itself. It would make more sense to standardize the protocol than to define an execution environment for arbitrary protocol engines.
Re: Web DRM moves to next phase, Defective by Design to continue opposition
#37You must remember that also before EME, Netflix & co. were using DRM.
EME makes it possible to view the DRM'd content (that is there with or without EME) without installing horrible and unaccessible generic binary add ons (Silverlight, Flash) and thus gives more freedom to users. Now a Netflix heavy user can choose to consume the content on Linux, too.
Re: Web DRM moves to next phase, Defective by Design to continue opposition
#38I am not sure how this is going to effect me. While I use FSF Icecat (their Firefox version) and should be OK with that, I do use Chrome for Netflix, Google, FB, and Twitter.
Will DRM black box plugin threaten the security of my laptop? Will many mainstream sites stop working with IceCat?
Re: Web DRM moves to next phase, Defective by Design to continue opposition
#39I thought the general consensus amongst people, including the general HN crowd was that it was better to allow the w3c to specify a "black box" with well defined inputs and outputs. Allowing vendors to slot in their own (probably closed source) implementation than it was to slam the door in their faces whilst screaming "SCREW YOU, USE SILVERLIGHT OR FLASH". Defective by design seems to be misinterpreting the "build t…
> it was better to allow the w3c to specify a "black box" with well defined inputs and outputs. But they didn't! EME is a spec for only for inputs, and no outputs. EME entirely depends on CDMs, and their interface is deliberately left completely undefined (W3C uses that as an excuse to say they didn't—strictly speaking— define a DRM). Plug-ins at least had an open NPAPI interface that anybody could integrate with. CD…
> The spec allows them to be anything, including kernel modules or hardware (and in practice they're… plug-ins).
On mobile platforms, they generally are system-integrated (and hardware-supported) components, often running at privilege levels exceeding the running Android/Linux kernel.
See the recent Qualcomm case where a DRM component (Widevine) running in TrustZone context[0] was used to attack Android's full disk encryption scheme.
[0] TrustZone is an ARM architecture feature for running code in a different execution context not accessible from the "normal" running kernel. Useful for running small amounts of code dedicated to protecting crypto keys, but horrible if you load gigantic DRM blobs into it that no one could reasonably audit due to sheer size even if their source code was available.
Re: Web DRM moves to next phase, Defective by Design to continue opposition
#40You must remember that also before EME, Netflix & co. were using DRM. EME makes it possible to view the DRM'd content (that is there with or without EME) without installing horrible and unaccessible generic binary add ons (Silverlight, Flash) and thus gives more freedom to users. Now a Netflix heavy user can choose to consume the content on Linux, too.
You still need to install horrible binary plugins available only for a small set of platforms.