6 ms·

DRM is not about access or not (that can and is being done with simple authenticated content). DRM is about what you can do with SPECIFIC contents. The MANAGE

by cowl 3y ago

DRM is not about access or not (that can and is being done with simple authenticated content). DRM is about what you can do with SPECIFIC contents. The MANAGE part in DRM. Netflix requiring you to login to view a movie is not DRM. Netflix offering a way to content owners to specify for example this movie can be seen but not download or this movie can be seen only once or this movie can not be fastforwarded, that is DRM. DRM means Publishers decide how their content gets consumed (on a case by case and publisher by publisher case). Nothing in this proposal gives publishers those means (beyond what is currently available). Verifying the authenticity of a device in this case is a generic "trusted/not trusted" not "OK for movie 123/KO for skipping on movie 456"

Adverblessly 3y ago
> DRM is not about access or not (that can and is being done with simple authenticated content). DRM is about what you can do with SPECIFIC contents. The MANAGE part in DRM. Sure, if you redefine DRM to mean whatever you want it to mean, this is not DRM. I'm not even sure what authentication has to do with it if you prevent access to your website before I even got a chance to see it. > Netflix requiring you to login to view a movie is not DRM. Not sure where you came up with this strawman, I said nothing about requiring you to log in. I said "access content on a device and software stack of their choice.", so for example, limiting streaming quality to 720p on Linux, or blocking a user using FireFox, or blocking a user on Linux, or blocking a user with a custom kernel, or blocking a user without a TPM. > Nothing in this proposal gives publishers those means It gives them the means to discriminate based on hardware and software, for example by only trusting a single attestor of their choosing which only gives a trusted signal for whatever passes their hardware or software criteria. As an example, Google may decide that as a requirement to having their ads on your website, you must only trust a single attestor - "Google Play" (as named in the proposal), because otherwise you may be trusting an attestor that facilitates ad fraud, and we can't have that. Google naturally only treats devices running Chrome as trusted, how can they trust anything else that they don't own? Naturally, the same applies to their own websites, can't have you using FireFox to send people CP via gmail, right? Do you want your website to be protected from bots via Google's reCaptcha? I'm sure they know how to decide which access attempt belongs to a valid user or not. And they'll be happy to cooperate with Cloudfront to make sure everyone online is equally safe. Obviously, it is also on Google to protect users from websites that host botted content, so if you want to appear on search results and don't want the browser to give a scary warning when accessing your website, be sure to only trust the trustworthy attestor. And let's not get started on what happens if you want to take payment from users while "mitigating fraud"... > (beyond what is currently available) Right, the justification to do more evil is that we already do some evil, I'm convinced. > Verifying the authenticity of a device in this case is a generic "trusted/not trusted" not "OK for movie 123/KO for skipping on movie 456" In just this specific example you prove yourself wrong. You can use the generic "trusted/not trusted" signal to decide "movie 123 is OK for not trusted, but movie 456 we will restrict to trusted only".
wzdd 3y ago
DRM is in fact very much about access and is the reason that, for example, if you want to watch HD video from any major streaming service on Linux you need to run a Windows browser in Wine. This workaround only works currently because these systems rely on software-based DRM, perhaps because there isn't yet a convenient built-into-the-browser hardware-backed root-of-trust-based attestation system for the web.
deleted 3y ago
[deleted]
roywiggins 3y ago
Okay, but as far as I can tell, "trusted" can be defined however the attestor chooses, and one way could be "the user is really using Chrome, on Windows, and isn't running any extensions or other applications that we don't like." Same way HDCP can tell an application whether the video is being played on a screen rather than a capture card. No trusted screen? No video for you. That's DRM.

by cowl 3y ago

Adverblessly 3y ago

> DRM is not about access or not (that can and is being done with simple authenticated content). DRM is about what you can do with SPECIFIC contents. The MANAGE part in DRM. Sure, if you redefine DRM to mean whatever you want it to mean, this is not DRM. I'm not even sure what authentication has to do with it if you prevent access to your website before I even got a chance to see it. > Netflix requiring you to login to view a movie is not DRM. Not sure where you came up with this strawman, I said nothing about requiring you to log in. I said "access content on a device and software stack of their choice.", so for example, limiting streaming quality to 720p on Linux, or blocking a user using FireFox, or blocking a user on Linux, or blocking a user with a custom kernel, or blocking a user without a TPM. > Nothing in this proposal gives publishers those means It gives them the means to discriminate based on hardware and software, for example by only trusting a single attestor of their choosing which only gives a trusted signal for whatever passes their hardware or software criteria. As an example, Google may decide that as a requirement to having their ads on your website, you must only trust a single attestor - "Google Play" (as named in the proposal), because otherwise you may be trusting an attestor that facilitates ad fraud, and we can't have that. Google naturally only treats devices running Chrome as trusted, how can they trust anything else that they don't own? Naturally, the same applies to their own websites, can't have you using FireFox to send people CP via gmail, right? Do you want your website to be protected from bots via Google's reCaptcha? I'm sure they know how to decide which access attempt belongs to a valid user or not. And they'll be happy to cooperate with Cloudfront to make sure everyone online is equally safe. Obviously, it is also on Google to protect users from websites that host botted content, so if you want to appear on search results and don't want the browser to give a scary warning when accessing your website, be sure to only trust the trustworthy attestor. And let's not get started on what happens if you want to take payment from users while "mitigating fraud"... > (beyond what is currently available) Right, the justification to do more evil is that we already do some evil, I'm convinced. > Verifying the authenticity of a device in this case is a generic "trusted/not trusted" not "OK for movie 123/KO for skipping on movie 456" In just this specific example you prove yourself wrong. You can use the generic "trusted/not trusted" signal to decide "movie 123 is OK for not trusted, but movie 456 we will restrict to trusted only".

wzdd 3y ago

DRM is in fact very much about access and is the reason that, for example, if you want to watch HD video from any major streaming service on Linux you need to run a Windows browser in Wine. This workaround only works currently because these systems rely on software-based DRM, perhaps because there isn't yet a convenient built-into-the-browser hardware-backed root-of-trust-based attestation system for the web.

deleted 3y ago

[deleted]

roywiggins 3y ago

Okay, but as far as I can tell, "trusted" can be defined however the attestor chooses, and one way could be "the user is really using Chrome, on Windows, and isn't running any extensions or other applications that we don't like." Same way HDCP can tell an application whether the video is being played on a screen rather than a capture card. No trusted screen? No video for you. That's DRM.