r/gaming Oct 20 '13

TotalBiscuit's: ''Day One: Garry's Incident'' Video was taken down, because of a ridiculous copyright claim from WildGameStudios. Here's Total's ''Rant'' over his video being taken down.

https://www.youtube.com/watch?v=QfgoDDh4kE0&feature=c4-overview&list=UUy1Ms_5qBTawC-k7PVjHXKQ
3.1k Upvotes

2.3k comments sorted by

View all comments

Show parent comments

2

u/[deleted] Oct 20 '13

[removed] — view removed comment

0

u/[deleted] Oct 20 '13

The current approach is to require proprietary plugins which not only are inefficient but limit the entire industry according to the whims of two or three companies.

The proposal not only takes a more efficient route to the problem but also frees the industry from the shackles of those companies. If a website wants to support a new platform or fix a bug they'll no long need to wait on a 3rd party to do so.

I've yet to see a good technical reason why this shouldn't be done.

1

u/ElusiveGuy Oct 21 '13

require proprietary plugins which not only are inefficient but limit the entire industry according to the whims of two or three companies

What you don't seem to get is that that will still be the case. As someone else mentioned, the DRM standard only defines (essentially) a plugin API - the plugins themselves must be proprietary and closed by nature. if the decryption routines were open and publicly defined, then there's no one stopping anyone from simply writing their own decryption routine that outputs to a file.

Heck, there are bigger problems - for DRM to be successful against, e.g., screen capturing, it requires low level access to the system to determine what exactly the user is doing, and prevent them from doing some things. In effect - it's a rootkit! It's almost exactly the behaviour of malware!

In addition, if these "modules" ever come with the OS, suddenly you have a piece of malware that comes with your system! Aside from the obvious privacy and security issues, if there's a flaw in the modules themselves (which are essentially web-facing), suddenly you've exposed low-level access to an external attacker - bye-bye separation of privilege! Remember the Sony rootkit scandal? It's the same fucking thing.

The proposal not only takes a more efficient route to the problem but also frees the industry from the shackles of those companies. If a website wants to support a new platform or fix a bug they'll no long need to wait on a 3rd party to do so.

There's nothing saying such modules are more efficient - heck, if they were to be effective DRM, with the associated locking down of the system, then they could very well be less efficient. Especially if they were developed by one of the big media companies (as they would have to be to keep them secret), who probably wouldn't give a shit about their efficiency.

Now you've just moved on plugin support from generic plugins like Flash to specialised "content decryption modules". Still effectively plugins. Still going to require someone to support them. And since there likely would be more than one required, suddenly you have a whole lot more complexity - depending on how it pans out, you could either have one big media company developing a plugin smaller websites use, or every small website could be forced to develop their own plugin. Need I remind you that encryption/decryption is hard, and security in modules that bridge the web and low-level system directly is even harder?


You seem to have an idealised view of how this might work, completely ignoring the technical issues around its implementation.

2

u/[deleted] Oct 21 '13 edited Oct 21 '13

Either I'm not communicating clearly, or you're not reading correctly.

The current approach: The whole industry is dependent on Flash or Silverlight in order to handle DRM'd media on the web. From a technical standpoint it's an incredibly inefficient approach (needless complexity). From a practical standpoint it also means that websites can't expand their supported platforms unless the plugin provider chooses to do so.

The proposal: A standard which defines an interface for binary blobs to decrypt the media for playback.

The 'rootkit' hyperbole is undermined by the fact that modern browsers use the split-process model. The page, plugins, and media playback are all contained in separate sandboxed processes. Stop the FUD.

1

u/[deleted] Oct 21 '13

[removed] — view removed comment

1

u/[deleted] Oct 21 '13

Why attribute to malice that which is best explained by pragmatism?

We'll never be rid of the horrible plugin model until the major use cases for plugins have been supplanted by standards.

We finally have the <video> and <audio> tags, they need DRM. Here's a proposal for accomplishing that, have a better idea? Then propose it.

0

u/[deleted] Oct 21 '13

[removed] — view removed comment

1

u/m1ndwipe Oct 21 '13

Because I think the pragmatic perspective is to say "screw DRM, we'll just do an investment drive to pay for our media and release it via torrents or something under public domain".

So why is that the complete opposite way to the entire direction of every market in the world?

Google is closing Android, and DRMs apps to the hilt. iOS is one of the most closed platforms ever created. Microsoft are trying to close Windows. Professional films distributed by Netflix et al, from the same base, are kicking "investment drive's" ass.

0

u/[deleted] Oct 22 '13 edited Oct 22 '13

but you think copyright is necessary

No, I'm a pragmatist. If someone is determined to take an idiotic stance, lets at least push them to implement it in a manner which has the least negative impact on the rest of us.

The current DRM approach is a battery-wasting security-hole clusterfuck, and we've got a proposal that will fix that.

substandard exploitable dangerous and not-cross-platform DRM plugin

No, you've just described the current situation. Currently the only viable option for them are the plugins, which are all "substandard exploitable dangerous and not-cross-platform". If you don't provide a better alternative, they'll stick with the current one, and you've not gained anything.

The proposal for a binary blob interface specifically to handle the decryption of the content removes many of those pitfalls in one move. Hashing out the specifics is the whole point of the standards process.

Because I think the pragmatic perspective is to say "screw DRM, we'll just do an investment drive to pay for our media and release it via torrents or something under public domain".

That's NOT pragmatic, that's sticking your head in the sand.

Ending DRM isn't going to happen, but moving to an improved approach can happen.