[icecast] Preventin browsers / wget's / ... from capturing stream?

[Stefan Neufeind]

On 8 Mar 2004 at 14:30, Rakotomandimby Mihamina wrote:

> On Tuesday 02 March 2004 02:23, Michael Smith wrote:
> > Shoutcast just does user-agent sniffing. This makes it look like you
> > can't download the stream easily, but that's just misleading you -
> > it's completely trivial to do so.
> 
> Yes , i'd say the same.
> 
> > > The most clean solution in my eyes would be to implement mms:// or
> > > rtp:// for mp3/ogg-streams in Icecast2 ... however, I guess just
> > > nobody yet started working on it - or is it really that hard to
> > > implement?
> 
> Though you could implement it , someone will always be able to "rip"
> your stream . I have a friend that runs Windows and he found a
> software that just record what is played by the soundcard, so that he
> just needs to turn off all the system sounds and can quietly record
> the stream, whatever is the protocol ...

I know such tools also. And I know even specialised tools exist that 
rip rtp.// as well as mms:// for you without a problem. The question 
was just to have a possiblity to at least deny the "dumb" users to 
download the stream with their browser ...

> > It's far from trivial to implement. This would be a very large
> > amount of work.
> 
> Useless , no worth amount of work ... :-)

Well, I think it might be useful if you also use the features like 
skip-protection, maybe automatic switching of stream-quality (if the 
connection-quality degrades during streaming) etc. And imho still the 
possibilty to deny "dumb" users to download the stream via any of the 
http-compliant programs widely used would be a major step.

> > > Anyway - I'm also looking for a good solution (similar to the one
> > > of Shoutcast, maybe) for plain http-streaming. Is it possible
> > > somehow?
> > Well, you could add nasty user-agent sniffing, but it's pretty
> > pointless.
> 
> streamripper can identify itself as any user-agent you want ... 

As said above: We're not talking about "there is always a way 
around". I'm just talking about what easy countermeasurements could 
be taken (and what is needed for icecast2 to actually use these 
countermeasurements) to give starters (not professionals) at least 
some feeling of "stream can't be downloaded".
Customers are (mostly) not technicians. But if you give them a http-
URL to listen and they can easily use their browser to download the 
stream, then you have a problem. At least I once had ... Then they 
come with things like "but if I use rtp / mms with RealServer / 
WindowsMediaServer then I'm more secure". This is not true from the 
technical point - but they think so ... and at least for the average 
user that's true.

So how could this practically be done?
a) How could browsers be denied from downloading?
b) Is anybody working on implementing an alternative streaming-
protocol (rtp or mms would surely be most interesting)?

PS: Also relaying from those protocols would be a cool feature *g*

<p>Regards,
 Stefan
--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to 'icecast-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.