Re: Protecting Streaming Audio

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks for that informative post. It really is a can of worms. How far to go
with it is a good question.. Honesty, the glass in half full (No harm in
thinking like that is there)..

Sincerely,
Adam

On 11/7/06, Richard Lynch <ceo@xxxxxxxxx> wrote:

On Mon, November 6, 2006 10:24 am, Ed Lazor wrote:
> use readfile to read the file and output it to the browser.  I don't
> know the specific ones, but you'll need to also send headers that
> declare the file as streaming media.

Alas, things get a bit more complicated than that, really...

For starters, the authentication process can get tricky, as the web
browser is generally used to find the file, authenticate the access,
and then you send out a playlist (authenticated access is trivial),
which is then handed off to a different piece of software (the player,
be it Real, WMP, or even WinAmp) which does not continue the session
cookie/data paradigm.

So at that point you need to embed some kind of authentication token
into the playlist, or rely on Security by Obscurity (usually
bad/ineffective), or have the actual audio stream expire (bad, annoys
users), or rely on proprietary DRM (bad, annoys users *and*
ineffective), assuming you absolutely HAVE to have some kind of
authentication on the audio data.

Because the player won't do diddly-squat useful with your
cookie/session/whatever, as it's not the web browser doing the URL
reading/playing.

There is also the question of what transport you stream over -- These
days it's largely just more HTTP data, with a standard web-server, but
there were specialized streaming servers such as Real had back in the
day, and presumably they are still suckering people into using that
pile of [bleep]. [Not that I'm biased against it, or anything...] or
perhaps an iTunes RSS feed.

Still, the authentication mechanism being transferred from GUI to find
the audio and the player to play the audio is not really a solvable
problem, unless you want to go whole-hog with something the way Apple
had to with iTunes to cater to the Major Labels.

You may actually want to look into Apple's RSS docs about this, as
that's probably the least-annoying and most flexible of the available
proprietary DRMs.  Which ain't saying much...

If you have any wiggle room at all, and want to keep your sanity, a
clear "Usage Policy" and no DRM is the way to go, honestly.  The DRM
will only annoy legit users, and be about as effective at stopping the
thieves as mosquito netting is against a Sherman tank.

Oh yeah.  You can't just send the "headers" for the streaming media.
You have to have the URL *look* like a static plain old media URL, or
some players *will* reject it, sight unseen, as invalid input.
http://richardlynch.blogspot.com/
shows one simple way to do that in PHP.

You could trivially extend that to read an embedded PHP Session ID in
a URL, very much like the GET arg that trans_sid does, and propogate
your session that way.  'Course that also exposes your session to a
hijack, which opens up a whole 'nother can of worms...

Did I mention that to keep your sanity you're much better of avoiding
the whole authentication and DRM model and just having a clear Usage
Policy and relying on user honesty? :-)

"I been down, I been down, I been down this road before..."

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux