I apologize for the delay in response time :) I got busy. Now I'm back :)> >Go read a basic document on Internet Standards. Encoding meta > >information (especially type) in a filename or URL is broken and wrong. > > I wasn't suggesting it be encoded in the URL.. only that if you go to the > URL (not the client-listen url, the website url) there should state what > type of streams they provide. I think most people already do this, or if > not, they have at least a short list of clients that are known to be able > to tune in.Yes your right. I also want to get people into going to these sites. There's _real_ information there. The directory is a directory, and it will never be a substitute for the broadcasters webpages.> Locking the field is fine.. but I think this goes back to separating the > front-end from the back-end. Listing it in the directory listings is just > silly IMHO. It's even sillier if the admin only wants to support > technology X, as it would just be the same redundant information repeated > over and over for every station, wasting screen real estate and bandwidth both.Ah, in general I'm not dicussing here what's shown on screen. Only how the information is stored and used. Once we lock this down, I imagine we'll ahve 101 good ideas about how to present this information in a good way. That's the hard part :)> 1. Icecast needs better metadata support, and hopefully the template idea > we return to in a bit.Icecast 2 has it. Ogg has much better metadata than mp3. Icecast passes that on just fine. it will also pull it out of the stream and use it however you want. This is the plan. There will also be another ogg substream for metadata only. This will allow you to do all kinds of wacky stuff. It's not done yet though. In the meantime you'll have much better metadata support than shoutcast to tide you over.> 2. Winamp needs Ogg support by default, or at least via a reliable plugin; > both in decoding and encoding.I'm not sure why this didn't make it into 2.77. But I've been told it's expected for 2.78. They have to get it approved or something. It'll be there. The current plugin is quite reliable now. After lots of testing on people's test icecast2 streams I think Peter has nailed most of the bugs. Also, the Windows Media Player plugins support streaming as well. And if I ever finish the RealPlayer one, it will too.> I still occasionally have problems with the metadata streaming on Icecast > if I leave the stream up for a log period of time, and Winamp is by far the > client that is most widely used to listen to the stream. I also prefer > Winamp for my source, because all of my workstation boxes are Windows > based.. that won't be changing any time soon.Icecast 1.x metadata is crap. I know it's crap. You guys know it's crap. It isn't crap in 2.x. :)> I think that at-best this TTL field should be more accurately named MAXTTL > unless you intend to disallow updates to the directory while the TTL is > still non-zero.Intent is the same, but your suggestion is certainly clearer.> Also, there are other time dependant pieces of information you seem to be > overlooking here such as Stream Title (mine changes depending on the name > of the current show), Track Title (obviously changes frequently, and at > strange intervals) and others.The only title in the directory is the title of the station. This is a constant. Show titles and song titles are transmitted in the comment headers for vorbis streams or in mp3-metadata.> What you're basically doing here in any respect is building a DoS into the > software on purpose. If you've never used something like Gnutella then it > may not be so obvious, but I guarantee it'll only be a matter of time > before software pops up that spams the server with multiple "streams" > showing music in every conceivable genre so as to get their stream listed > no matter what preferences the listener decides to sort the listing with.It's easy enough to stop this kind of attack, even automatically. Note that having every server send updates every 2 seconds is also going to be a problem. I'm trying to find some reasonable compromise. We can't 100% stop cheating. But I can certainly make cheating 'different'. Taking away the listener count removes a strong temptation to cheat. The idea is that if the temptation is weakened, cheating will not be as big of a problem.> This should without a doubt be an admin tunable knob, not something to be > set by clients. If you intend this directory lister to achieve widespread > use, especially as the software-of-choice for running public directory > servers, this must absolutely not be tuneable by the client.I'm not sure what you mean. If you mean MAXTTL, it's certainly reasonable that this be tunable by the client within some acceptable range. My current thoughts were 5 minutes to 1 day. That way sites that are very stable, can be nice about the amount udpates they do. especially since there's no time dependent data, this makes things more efficient. Certainly someone can abuse things and set the thing to 1 day and then take down there stream. But there are programmatic ways to check on people in the interest of keeping the directory content valid.> Applied Cryptography begs to differ with you. > > Sending a hash across the network is no more secure than sending a > cleartext password, if all that is required to authenticate is the > hash. What you really need is something like Diffie-Hellman to do the > negotiation, or a public-key system.This is not to protect against sniffing. This is to protect against spoofing and stealing. It is certainly adequate to do that. It would be unreasonable to bruteforce the 'password'. When I 'check' the password on the other server, I certainly won't be transmitting it :) There will be some challenge response type action going on. We don't need absolute security. We need security to protect against specific attacks. If you'd like me to outline these in detail, I can in a separate email. I have notes on the attacks and how these methods prevent them and also on which attacks are still possible.> The request-and-parse approach is horribly inefficient. It requires me to > set up some kind of cron job or server side scripting to do this step and > then convert the output to the format I wish to display on the main site > for the stream. This causes linearly increasing load on a single machine > instead of distributing that load among all the mirrors. > > I realize I can do the things you've listed, and have done them in the > past.. but it's just horribly time consuming and process consuming compared > to simply using SSI in Apache to request a URL from the remote stream and > having a template that is one row in a table.The answer to this may be XSLT. It is probably easy enough for me to put XSLT capability into icecast. This would allow you to specfy a template to transform stats.xml (or some other xml). That would give you the output you want. The downside here is that icecast is processing something. As more clients want to view this template icecast will do more processing. Request and parse, while more inefficient for a few clients, is way more efficient for many clients. In a large scale environment you wouldn't use either of these methods. You'd write a stats client that listens on teh stats port and gets hte updates in realtime (note that this _already_ works now). Then you can do processing without involving icecast, and without request/parse/output overhead. In the end, it's likely we will support all three models. There's nothing difficult about any of them. I hadn't thought about the XSLT stuff, but that is an elegant way to do it. jack. --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
At 08:19 PM 10/17/2001 -0600, you wrote:>I apologize for the delay in response time :) > >I got busy. Now I'm back :)Cool, and you replied to me first! ;)> > over and over for every station, wasting screen real estate and > bandwidth both. > >Ah, in general I'm not dicussing here what's shown on screen. Only how >the information is stored and used. Once we lock this down, I imagine >we'll ahve 101 good ideas about how to present this information in a >good way. That's the hard part :)Roger that.>There will also be another ogg substream for metadata only. This will >allow you to do all kinds of wacky stuff. It's not done yet though. In >the meantime you'll have much better metadata support than shoutcast to >tide you over.Right on.>I'm not sure why this didn't make it into 2.77. But I've been told it's >expected for 2.78. They have to get it approved or something. It'll be >there.Hopefully.. considering their DSP guy and a handful of others were laid off.. the new DSP they have really blows too so I'm forced into using the old one.. oh well.>The current plugin is quite reliable now. After lots of testing on >people's test icecast2 streams I think Peter has nailed most of the >bugs. Also, the Windows Media Player plugins support streaming as well. >And if I ever finish the RealPlayer one, it will too.Oh that's cool.. and I assume the WMP plugin is available through the wacky MS codec plugin thing, so that it can automagically find and download it if it needs to? That's just as good as default support, if not plain better.>Icecast 1.x metadata is crap. I know it's crap. You guys know it's >crap. It isn't crap in 2.x. :)Consider yourself quoted on that. ;)>Intent is the same, but your suggestion is certainly clearer.Ah ok cool.>The only title in the directory is the title of the station. This is a >constant. Show titles and song titles are transmitted in the comment >headers for vorbis streams or in mp3-metadata.Well since this was cleared up with the (max)TTL discussion paragraph just before this, it's a non-issue.>It's easy enough to stop this kind of attack, even automatically. Note >that having every server send updates every 2 seconds is also going to >be a problem. I'm trying to find some reasonable compromise. We can't >100% stop cheating. But I can certainly make cheating 'different'. >Taking away the listener count removes a strong temptation to cheat. >The idea is that if the temptation is weakened, cheating will not be as >big of a problem.True enough, but I would still like to see it there.. If it's not listed in this directory in particular that's not a big deal I suppose, as long as Icecast maintains the capability of connecting to multiple servers and types of servers simultaneously. I've actually been looking for some YP "out there" to run myself for some of the reasons that went back and forth in this thread. The most compelling one being that I want to get nice, homogenous statistics from all my servers, be they Icecast, Shoutcast, or something else, without mucking around with template files for each one. I figured if I could just get them all on the same YP, by configuring Icecast and faking out Shoutcast via some ipfw/natd trickery, that I could generate the page fragments I want off the YP and stop worrying about the server software doing it.. but listener counts is one thing I really need here if just for my station homepage. If you could point me in the direction of where I can find one of these I'd appreciate it.. unless you'd rather I wait until the new project we're discussing is ready. ;)> > This should without a doubt be an admin tunable knob, not something to be > > set by clients. If you intend this directory lister to achieve widespread > > use, especially as the software-of-choice for running public directory > > servers, this must absolutely not be tuneable by the client. > >I'm not sure what you mean. If you mean MAXTTL, it's certainlyI was talking about listener counts, not MAXTTL.> > Applied Cryptography begs to differ with you. > > > > Sending a hash across the network is no more secure than sending a > > cleartext password, if all that is required to authenticate is the > > hash. What you really need is something like Diffie-Hellman to do the > > negotiation, or a public-key system. > >This is not to protect against sniffing. This is to protect against >spoofing and stealing. It is certainly adequate to do that. It would >be unreasonable to bruteforce the 'password'.Well it's not protecting against spoofing either. Someone can sniff the hash and then they don't have to spoof, they can connect and send the hash without ever knowing the password that it was before it was hashed. What you really need for reliable client-server authentication is a challenge-response system (like NT password authentication or Kerberos) or an encrypted transport layer (like SSL or SSH).>When I 'check' the password on the other server, I certainly won't be >transmitting it :) There will be some challenge response type action >going on.There we go.. challenge response. :)>We don't need absolute security. We need security to protect against >specific attacks. If you'd like me to outline these in detail, I can in >a separate email. I have notes on the attacks and how these methods >prevent them and also on which attacks are still possible.I'm always interested in this sort of thing, and as you've probably guessed, very forthcoming with my technical critique. ;)>In the end, it's likely we will support all three models. There's >nothing difficult about any of them. I hadn't thought about the XSLT >stuff, but that is an elegant way to do it.Cool enough. --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> Hopefully.. considering their DSP guy and a handful of others were laid > off.. the new DSP they have really blows too so I'm forced into using the > old one.. oh well.The ogg plugin author was not an employee. He was a contractor. He's still working on the plugin regardless.> Oh that's cool.. and I assume the WMP plugin is available through the wacky > MS codec plugin thing, so that it can automagically find and download it if > it needs to? That's just as good as default support, if not plain better.I doubt microsoft will do that, but you never know. For now it's a download (but it's a very nice and easy installer. a no brainer). We're trying to find a way to make this automatic when you hit a webpage possibly. We'll see. It only gets better from here :)> >I'm not sure what you mean. If you mean MAXTTL, it's certainly > > I was talking about listener counts, not MAXTTL.It doesn't matter whether listener counts are configurable by the user. users will cheat anyway. Certainly shoutcast does not allow you to change these, and you can still cheat in numerous ways. If you mean controlling whether it's displayed on the server, then certainly those are server-configurable only :) That's the only logical way for them to be :)> Well it's not protecting against spoofing either.Yes it is. To spoof the address you'd have to guess the password. That is reasonable difficult.> Someone can sniff the > hash and then they don't have to spoof,Sniffing is quite difficult. If you can sniff, you've likely gotten onto the box anyway and can cause other michief. The chances of someone on your network wanting to muck with you is slim, and even so, challenge response prevents this. You can still sniff the transmission to the directory server, since it will need to receive the password. But like I said, this isn't perfect, just quite adequate for our purposes and very easy to implement and manage. jack. --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.