AV WWDC, part 2: Fair Is Pretty Foul

Next up on our tour of WWDC 2015 media sessions is the innocently-titled Content Protection for HTTP Live Streaming. Sounds harmless, but I think there’s reason for worry.

For content protections, HLS has always had a story: transport segments get a one-time AES encryption, and can be served from a dumb http server (at CocoaConf a few years back, I demo’ed serving HLS from Dropbox, before it was https:-always). You’re responsible for guarding the keys and delivering them only to authenticated users. AV Foundation can get the keys, decrypt the segments, and play them with no client-side effort beyond handling the authentication. It’s a neat system, because it’s easy to deploy on content delivery networks, as you’re largely just dropping off a bunch of flat files, and the part you protect on your own server is tiny.

So what’s “FairPlay Streaming”, then?

The guts of the first half of the session covers this question. In FairPlay Streaming, you adopt an Apple API to provide for the key delivery as well. There’s 50 slides of this stuff for you server types… there’s an SDK and a reference implementation that needs to be customized, so it’s not likely I’m going to be doing that step myself, since back-end coding out of my wheelhouse (I try, but I suck at it, and I find it boring). Clearly not as simple as the current scheme, but it’ll be worth someone’s time to implement it.

Because here’s the difference — and you figure there has to be a difference for it to be worth Apple’s time to develop an supplementary standard to what they already have and everyone’s using. The point of “FairPlay Streaming” seems to be to plug holes in the server-to-viewer chain where the media could be copied in some way. On slide 13, we see “Requires protected HDMI for external output”, so you couldn’t take a FPS stream and dump it directly to an external recording device over HDMI (because any such device would presumably not be HDCP compliant).

And then it gets better, by which I mean worse. The standard seems particularly interested in preventing you from AirPlay’ing content to other devices. Slide 81:

  • FairPlay Streaming with AirPlay
  • AirPlay Video will transfer streaming operation to Apple TV
  • No additional code needs to be written!
  • SPC request is generated by FPS on Apple TV and CKC response is for Apple TV
    • Your app on the sending device relays messages between Apple TV and your key server
  • Provides the same level of security as local playback
  • FPS content is disabled by AirPlay Mirroring, not rendered in screenshots or recordings

So the first part here is that when AirPlaying to an Apple TV, FairPlay Streaming basically turns the Apple TV into a Chromecast: it transfers responsibility for downloading and playing the stream to the AppleTV, rather than having the iOS/OSX device fetch the content and then re-stream it to the Apple TV. Good in one sense, because this effectively halves the amount of data being sent across your network.

But look at that last point: FPS content cannot be captured by the user if they’re, say, streaming it to their Mac. It’s not clear if this is also the behavior when playing an FPS stream directly in OS X or iOS. It’ll suck if it is, because this basically would mean that streams would behave the same way DVDs do when you try to get a screenshot: you get a blank rectangle.

This sounds a lot like the various efforts to plug the “analog hole”, meaning the ways in which protected content can escape a protected chain of delivery and thus be captured. This, for example, is why a PlayStation 3 plays Blu-Rays in standard def if you have component video instead of HDMI: it can’t be sure if you’re hooked up to a recorder, so it assumes you are and degrades the video. Defective by design.

The thought of this is rather appalling. Content providers have been playing Whack-A-Mole for years with their own users, doing much to inconvenience users while doing little to thwart piracy. At this point, you have to conclude that they are genuinely opposed not to piracy, but to any use of their product other than passive viewing. They honestly think they’re being robbed if you use a clip of a movie to make a point on Vine, or a screenshot for a funny tweet, something I frequently do with my Crunchyroll subscription:

The idea of using HTTP Live Streaming for any significant piracy is also rather absurd. HLS bitrates are well below physical media (typically 3-5 Mbps for HD streaming while Blu-Rays run 20-50), and then AirPlaying that video will add further artifacting from a local re-encode. Combine that with the unpredictable quality of variable-playlist HLS, and any serious pirate would be nuts to use HLS as an attack vector.

So this seems like a feature that’s likely to do little to prevent piracy, while taking away the ability to do things we already do, like grab screenshots, livestream group viewings, or screen-record things like reaction videos. And even if it works, we’ll just seek out workarounds: Flash will be the dominant way to stream to browsers for the foreseeable future, and it can be captured. And after that, there’s probably a million other approaches, like running a media player in a VM and recording that.

Honest, paying customers should have more rights to reuse their digital media, not less. But once again, the result is to make piracy more appealing, as Matt Drance perfectly captured a few years back:

Also under this new deal, pirated movies remain free of charge, free of non-skippable ads, free of five-minute load times, and are now nearly three months ahead of the competition.

Difference is, in that blog, Matt was talking about Netflix, and now we’re talking about Apple. While I’ve gotten used to the sad spectacle of Congress fellating Hollywood on a daily basis, it’s a surprise to see from Apple. It was only a week ago that Apple was presuming to stream free music for three months without paying for it, and now it seems they’re trying to close a content protection hole in AirPlay that is actually useful to users and likely irrelevant to genuine piracy.

File this under “Do Not Want”. Hopefully, implementing the server side pieces will be burdensome enough to slow the deployment of FairPlay Streaming.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.