Search code examples
downloaditunesdrmfairplay

is it reasonable to protect drm'd content client side

Update: this question is specifically about protecting (encipher / obfuscate) the content client side vs. doing it before transmission from the server. What are the pros / cons on going in an approach like itune's one - in which the files aren't ciphered / obfuscated before transmission.

As I added in my note in the original question, there are contracts in place that we need to comply to (as its the case for most services that implement drm). We push for drm free, and most content providers deals are on it, but that doesn't free us of obligations already in place.

I recently read some information regarding how itunes / fairplay approaches drm, and didn't expect to see the server actually serves the files without any protection.

The quote in this answer seems to capture the spirit of the issue.

The goal should simply be to "keep honest people honest". If we go further than this, only two things happen:

  1. We fight a battle we cannot win. Those who want to cheat will succeed.
  2. We hurt the honest users of our product by making it more difficult to use.

I don't see any impact on the honest users in here, files would be tied to the user - regardless if this happens client or server side. This does gives another chance to those in 1.

An extra bit of info: client environment is adobe air, multiple content types involved (music, video, flash apps, images).

So, is it reasonable to do like itune's fairplay and protect the media client side.

Note: I think unbreakable DRM is an unsolvable problem and as most looking for an answer to this, the need for it relates to it already being in a contract with content providers ... in the likes of reasonable best effort.

Solution

  • To answer the question "is it reasonable", you have to be clear when you use the word "protect" what you're trying to protect against...

    For example, are you trying to:

    1. authorized users from using their downloaded content via your app under certain circumstances (e.g. rental period expiry, copied to a different computer, etc)?
    2. authorized users from using their downloaded content via any app under certain circumstances (e.g. rental period expiry, copied to a different computer, etc)?
    3. unauthorized users from using content received from authorized users via your app?
    4. unauthorized users from using content received from authorized users via any app?
    5. known users from accessing unpurchased/unauthorized content from the media library on your server via your app?
    6. known users from accessing unpurchased/unauthorized content from the media library on your server via any app?
    7. unknown users from accessing the media library on your server via your app?
    8. unknown users from accessing the media library on your server via any app?

    etc...

    "Any app" in the above can include things like:

    • other player programs designed to interoperate/cooperate with your site (e.g. for flickr)
    • programs designed to convert content to other formats, possibly non-DRM formats
    • hostile programs designed to

    From the article you linked, you can start to see some of the possible limitations of applying the DRM client-side...

    • The third, originally used in PyMusique, a Linux client for the iTunes Store, pretends to be iTunes. It requested songs from Apple's servers and then downloaded the purchased songs without locking them, as iTunes would.

    • The fourth, used in FairKeys, also pretends to be iTunes; it requests a user's keys from Apple's servers and then uses these keys to unlock existing purchased songs.

    Neither of these approaches required breaking the DRM being applied, or even hacking any of the products involved; they could be done simply by passively observing the protocols involved, and then imitating them.

    So the question becomes: are you trying to protect against these kinds of attack?

    • If yes, then client-applied DRM is not reasonable.
    • If no (for example, you're only concerned about people using your app, like Apple/iTunes does), then it might be.

    (repeat this process for every situation you can think of. If the adig nswer is always either "client-applied DRM will protect me" or "I'm not trying to protect against this situation", then using client-applied DRM is resonable.)

    Note that for the last four of my examples, while DRM would protect against those situations as a side-effect, it's not the best place to enforce those restrictions. Those kinds of restrictions are best applied on the server in the login/authorization process.