4 ms·

How would that be implemented? What's to stop me from simply changing my computer's clock to a future date to disable the DRM?

mseebach 11y ago
You require rights holders to place the DRM key in escrow with the copyright office.
- tamana 11y ago
  Even better, TSA can hold it, next to the luggage keys
schoen 11y ago
Gwern analyzes some ideas at http://www.gwern.net/Self-decrypting%20files http://www.gwern.net/Self-decrypting%20files
chatmasta 11y ago
What's to stop you from changing your computers [fill_in_the_blank] in the current status quo? DRM is an inherently weak system because as long as you have root on your device, you can break it. Perhaps it will take some serious reverse engineering effort, but it's always going to be breakable, because in order for you to consume the content in the fist place, your device needs to decrypt it. (Of course, that's the point the EFF is making here, that that unbreakable DRM requires compromising our ability to have root access to our own devices.) So yeah, I agree with you. But given the assumption that DRM works (it doesn't), there's no reason why the DRM could not enforce public domain release protocol in the same way it enforces copyright requirements. Just as iTunes lets you "rent" a movie for a day, it could let you "rent" a copyrighted work until it enters public domain.
- kazagistar 11y ago
  There is a significant effort to prevent users from having root on their devices. It isn't successful yet, but it does not mean vendors aren't trying.
  - gcr 11y ago
    Apple's efforts are already bearing fruit: since El Capitan, the only paths that root can change are in /Users/$USER and /usr/local. For example, you can no longer edit binaries in /bin or /usr/bin. Another example: root cannot attach the debugger to binaries that have been signed with restrictive entitlements. lldb will refuse to debug `/usr/bin/git`, for example. This has been the case for at least a year now.
- __init 11y ago
  Unfortunately, hardware vendors are jumping on the DRM train, too, with things like Qualcomm's Secure Execution Environment [1], and Intel's Secure Enclave [2]. [1] https://www.qualcomm.com/media/documents/files/snapdragon-studioaccess-infographic.pdf https://www.qualcomm.com/media/documents/files/snapdragon-st... (PDF) [2] https://software.intel.com/en-us/sgx https://software.intel.com/en-us/sgx
  - nitrogen 11y ago
    I suggest the book Rainbow's End by Vernor Vinge as an interesting bit of fiction built around the concept of a secure CPU enclave.

mseebach 11y ago

You require rights holders to place the DRM key in escrow with the copyright office.

tamana 11y ago
Even better, TSA can hold it, next to the luggage keys

schoen 11y ago

Gwern analyzes some ideas at http://www.gwern.net/Self-decrypting%20files http://www.gwern.net/Self-decrypting%20files

chatmasta 11y ago

What's to stop you from changing your computers [fill_in_the_blank] in the current status quo? DRM is an inherently weak system because as long as you have root on your device, you can break it. Perhaps it will take some serious reverse engineering effort, but it's always going to be breakable, because in order for you to consume the content in the fist place, your device needs to decrypt it. (Of course, that's the point the EFF is making here, that that unbreakable DRM requires compromising our ability to have root access to our own devices.) So yeah, I agree with you. But given the assumption that DRM works (it doesn't), there's no reason why the DRM could not enforce public domain release protocol in the same way it enforces copyright requirements. Just as iTunes lets you "rent" a movie for a day, it could let you "rent" a copyrighted work until it enters public domain.

kazagistar 11y ago
There is a significant effort to prevent users from having root on their devices. It isn't successful yet, but it does not mean vendors aren't trying.
- gcr 11y ago
  Apple's efforts are already bearing fruit: since El Capitan, the only paths that root can change are in /Users/$USER and /usr/local. For example, you can no longer edit binaries in /bin or /usr/bin. Another example: root cannot attach the debugger to binaries that have been signed with restrictive entitlements. lldb will refuse to debug `/usr/bin/git`, for example. This has been the case for at least a year now.
__init 11y ago
Unfortunately, hardware vendors are jumping on the DRM train, too, with things like Qualcomm's Secure Execution Environment [1], and Intel's Secure Enclave [2]. [1] https://www.qualcomm.com/media/documents/files/snapdragon-studioaccess-infographic.pdf https://www.qualcomm.com/media/documents/files/snapdragon-st... (PDF) [2] https://software.intel.com/en-us/sgx https://software.intel.com/en-us/sgx
- nitrogen 11y ago
  I suggest the book Rainbow's End by Vernor Vinge as an interesting bit of fiction built around the concept of a secure CPU enclave.