Yeah, I know, its pointless to post this, but I guess I like tilting at windmills.
I submitted this yesterday and it was rejected: 2002-02-18 15:32:33 Record Companies Facing Revolt of Artists (articles,music) (rejected)
I've read all the FAQ's on submitting (several times) and try as I might I cannot get a story accepted on this site. It makes one wonder what other stuff gets overlooked in the submission queue.
More to the point, it makes me wonder what issues are important to the editors of this site but which are not being clearly articulated in the FAQ's on submitting. I.e. I must be doing something wrong, but for the life of me I can't figure out what.
It's been reported in several of these stories that the Replay 4000 limits internet sends of recorded shows to a total of 15, and they have to be people you have previously agreed to exchange shows with. This is very different than Napster, where a total stranger could grab a song off my disk without my knowledge.
And there are other Digital Rights Management features in Replay 4000 that have NOT yet been reported upon. I'm a Replay 4000 owner, and I can comment on some of these.
SonicBlue licenses Macrovision's technology, which is the same signal-munging technology that keeps VCR's from recording the output of your DVD player.
The interesting part is that a Replay 4000 will let you record a Macrovision-encoded program. I personally tested this by feeding the output of my DVD player into the secondary input on my Replay 4160 as a test. The Replay reproduces the Macrovision signal when outputting the program. This means you can time-shift copy-protected shows, but you cannot dub them out of the Replay onto a VCR!
Also, according to this press release, when a Replay 4000 sees that a show is Macrovision-encoded, it will not allow the user to share this program over the internet.
I think this is a pretty decent compromise between preserving the customer's ability to time-shift programs, and the program-owner's right to control copying of that program on permanent media.
And vis-a-vis the big conglomerates, this is a big change from the early Replay units. I've owned a Replay 2004 for over two years, and those early units would strip the Macrovision encoding from shows you passed through it. Thus they could be used as an intermediary for dubbing DVD's and other protected content to tape.
For this and other reasons I really think the media giants are going to fall on their face in this lawsuit. No judge is going to side with them when its so obvious that SonicBlue has made these efforts to accomodate their interests.
I would like to call attention to the Useful Reading list at the bottom of the linked article. One of the books listed, "The Inmates Are Running The Asylum" is a fabulous book by Alan Cooper.
If you have anything to do with designing any sort of interface to any sort of product (be it a piece of hardware, a piece of software, a widget, whatever), you should read this book. It will open your eyes.
If you are interested in BSA's tactics, you might also want to read this article from a couple years ago in Mother Jones magazine. The well-researched piece essentially reveals that many of BSA's branches overseas essentially act as Microsoft sales offices, pushing licenses for MS products even on companies that weren't illegally using them, but in fact were using other (competing) products.
For fairness, here is a link to a follow up letters column that disputes some of the facts in the article.
Anyway, the point is that UPN couldn't stream the content to end users without pissing off affiliates...
Sure they could. In his proposal, he had folks logging in so they could demographically target ads at them, right? Well the login information includes where the person lives, right?
You simply pay the affiliates a percentage of the ad revenue based on how many people in their area viewed the stream.
Voila, everyone is happy.
Re:How Are the Changes Being Made?
on
AOL vs. Trillian
·
· Score: 2
> I'm not sure what happened in the second step,
> but one theory is that they started checking
> the version number submitted in the
> Authentication request(or something similar).
Actually I sniffed this to look. Trillian actually lies to the Oscar server and tells it that it is a particular version of AIM. This is probably necessary to even log on given AOL's attitude. (And this is possibly the basis of the PR flacks "hacking" accusation).
What it looked like AOL started doing was "slamming shut" the Oscar connection (with a TCP RST packet coming back to the client) after it was complete. If you've ever sniffed AIM, you'll see it makes an initial connection to the Oscar server to authenticate, and in that connection an IP address is sent down. The actual IM connection is made to that other IP address.
It looked to me like Trillian was expecting the Oscar connection to close normally, and barfed when it got the RST packet. It's possible the AIM client doesn't care about this.
FWIW I'm running Trillian 0.721 right now, and I'm connected *AND* I have the SecureIM feature turned on. So right at this moment Cerulean Studios is winning the battle.
Wow, that's interesting because I've had the exact opposite experience with Real vis-a-vis Windows Media. Windows Media always misbehaves, gets the sound out of sync with the picture, or just dies. Real Media (and Quicktime for that matter) works well on the same connection.
Of course I don't watch a ton of long feeds on the net, mostly short things like movie trailers or clips. Maybe thats the difference?
There are lots of software programs like Ad-Aware that will clean these up for you, but my goal is to have LESS software on my PC, not MORE.
I found an nice free website that will run a JavaScript in your browser that detects various kinds of spyware and directs you to instructions on how to remove it. He also offers the source up for free so webmasters can help combat this scourge by hosting the script on their own pages. (That way all your site visitors will be warned about they spyware as they visit your site). It doesn't seem to detect this one though.
I dug this up when I discovered a few months back that AudioGalaxy had secretly installed a similar application called VX2 on my PC. The odd thing was that Audio Galaxy wanted to install BonziBuddy too, but it let me choose. But no choice with this other one. Fortunately it was easy to remove and AG runs fine without it.
> They did the same thing some 40 years ago in Egypt, at the temple of Abu Simbel built
> by Ramses the Great. When the Aswan High Dam was about to be built, engineers realized
> the temple would be buried under all of the water flow. So, it was moved to a higher
> location that would be safer. Of course, they did that without the use of
> supercomputers and 3D modelling
I was gonna mention that but you beat me to it. I remember being fascinated as a kid reading the National Geographic article where they showed the whole project in detail. Each block was carefully sliced out of the mountain and numbered for reassembly.
Here's a good link with lots of pictures of Abu Simbel.
Well you gotta pay for the equipment, but ReplayTV's units carry no ongoing subscription fees.
Re:You pay for performance
on
Future Of IDS
·
· Score: 1
> If you can find me one NIDS review by a reputable 3rd party where
> they hooked up a NIDS to a SMARTBITS and reported the results I'll take it back.
Well for one, the review we are talking about, which you can download here, used a SmartBits (among other things) to generate background traffic during the performance tests. See pages 167 and 228 in the report.
Some methodology flaws
on
Future Of IDS
·
· Score: 2
It took me a while to download the report (/. effect no doubt) but now that I look at it, even a quick skim of the testing methodology shows some obvious flaws.
Page 165: The Tests
all available signatures enabled
This is not a level playing field. The product that I helped build (ISS RealSecure) contains a number of signatures that are not intended to be turned on in normal usage. For instance, RealSecure can generate an even for every single HTTP GET request on your network, no matter how inane.
This feature is intended to be used as a special purpose tool, for instance to analyze web usage over the short term. It is not intended to be turned on during normal IDS usage. If you do turn it on, it often overwhelms your console with tons of incidental data and rapidly fills your logs.
Page 166-167: Performance Under Load
Another RealSecure specific problem here is that RealSecure deliberately drops redundant reports and does not count them, so that you do not get inundated with a million messages that tell you the exact same thing. Therefore I would expect it to fare very poorly in the boping count test.
Others in this thread have pointed out the danger of using tools like SMARTBITS to generate background traffic. The problem is that unless you really know what you are doing, SMARTBITS is likely to generate traffic that is entirely unrealistic. (For instance, TCP data packets that don't correspond to an actual open session that the IDS would have been tracking). This can cause both unrealistically good and unrealistically bad performance, depending on what the background traffic actually is and how the IDS is built.
The assertion early in this section that "if a sensor detects 100 per cent of attacks at 100 per cent load in this test" (of minimum length packets) that it "can handle anything that islikely to be thrown at it" is patent BS. Yes this is the worst case scenario of "packets per second", but packets per second is not the most important metric here.
I also note on page 177 and 178 in a footnote that neither RealSecure nor BlackICE were "re-tested for Edition 2", yet they are not reluctant to conclude that SNORT is better than the commercial products. I think we've got an apples and oranges problem here.
I also question whether their assertion that all products were tested with their latest signature updates can possibly true, if they didn't retest all the products. Most of the commercial vendors release new signatures on a regular basis.
(This is also true for the Cisco, CA, Symantec, Enterasys and other products in the comparison, if you read the footnotes carefully).
Re:You pay for performance
on
Future Of IDS
·
· Score: 2
> Any IDS vendor that is using a smartbits to test their
> NIDS should be flogged and then shot in the kneecap
I am aware of the fact that SMARTBITS alone is not sufficient to properly test a network IDS. I was merely giving an example of the expense someone has to incur to set up proper simulation environments to exercise their products so they will have good behavior in real-world networks.
SMARTBITS, while not sufficient by itself to properly test an IDS, is a tool that lets you push Ethernets to (and beyond) their theoretical limits. This is VERY DIFFICULT to do with other solutions.
> > Not to mention trying to compare NetIce to Snort is like apples
> > and oranges. NetIce does protocol analysis...
I see that, like many, you have fallen prey to Network ICE's excellent marketing machine. Yes, it does do protocol analysis, but it is not unique in this respect. RealSecure (ISS'es product prior to buying Network ICE) did protocol analysis before BlackICE even existed. NETICE was just better at getting that marketing message out. (Reminder: I've seen the source code to both products, and wrote large hunks of one of them).
Re:You pay for performance
on
Future Of IDS
·
· Score: 2
Unfortunately (for Snort) I helped build one of these commercial systems when I was at my previous employer. Therefore helping the guys improve Snort might put me in violation of my employment agreement. So I can't.
And I don't think you were flaming, its a very legit suggestion.
You pay for performance
on
Future Of IDS
·
· Score: 5, Informative
That's all well and good, but have you ever tried to put SNORT with a large number of signatures enabled on a really high speed link that is well utilized?
I am afraid if you do you are in for a RUDE awakening. The fact of the matter is that these $20,000 solutions cost that much for a reason, and the reason is they've spent years optimizing them for high speed links. This is something the hobbiest programmers who work on Snort cannot compete with. For instance, what open source coder has a SMARTBITS on their desk? Something like that is essential to test these things, but they cost upwards of $10,000.
So I would say yes, if all you want to do is monitor a T1 or two, and you're willing to tinker alot, something like Snort would work. But if you have a SERIOUS network with lots of bandwidth, you're gonna have to pony up the dough.
Disclosure: I helped build one of the systems that Snort supposedly beat, and I analyzed the source code for another one that was bought by that company. Snort CANNOT beat either one in a high bandwidth situation. I've seen the code, I've run the tests, trust me.
I no longer work for that company so have little to gain by saying this.
The Replay 4000 is the first Personal Video Recorder (PVR) that comes with broadband support from the factory. Also has the highest capacity of any on the market. They may not have the TV advertising budget that Tivo does, but they have some great technology and have won an Emmy for it!
I've had a ReplayTV for two years now, and have been very happy with the hardware and the company. I'm looking forward to upgrading.
Sure, the iPod is slick, but is it worth $400 just to play music? The TDK Mojo (which I've posted about before) uses CD-R's and CD-RW's as media, can play regular CD's as well, uses normal AA batteries, has 8-minute shock protection, and is far cheaper.
Best of all, (and unlike the Rio Volt SP250), it has a quite usable UI that lets you search your disks for MP3's by Artist, Title, Genre and so on. (On the other hand, the Rio has an FM tuner, and plays WMA files too). The UI is what sold me on this unit, it really is the make-or-break.
Yes, that's right. You need to be plugged in when you boot or it can't determine if there is a conflict. This is no different from DHCP, where you need to be plugged in at boot in order to receive an address.
> If you let the Windows random assignment
> happen, there is always the chance that two
> machines will grab the same IP address.
First of all it's not the "Windows" random assignment. The 169.254 stuff is a public spec, and so far both Windows and MacOS support it. It's called "Dynamic Configuration of IPv4 Link-Local Addresses" and you can read about it here. (Microsoft's implementation is called APIPA and you can read about it here).
Have you ever actually seen an address conflict happen? It's not supposed to under the spec. Each box after picking a proposed address is supposed to ARP it. If it gets a reply, it then tries again. And so on. Works kind of like a hash table.
Clearly you are not interested in discussing the issue at hand. I asked you to tell me WHY the ActiveScripting API was insecure and you refuse to answer the question. Instead you feed me a bunch of ill-founded opinions.
I dislike Microsoft's business practices as much as the next guy. But if you want to convince me that one of their technologies has a problem you have to back it up with facts, not religious zealotry.
Tell Mulder and Scully I said HI, clearly you live somewhere in their fictional world.
Slashdot Mirror
This has the effect, at least for me, of severely discouraging submissions.
I submitted this yesterday and it was rejected:
2002-02-18 15:32:33 Record Companies Facing Revolt of Artists (articles,music) (rejected)
I've read all the FAQ's on submitting (several times) and try as I might I cannot get a story accepted on this site. It makes one wonder what other stuff gets overlooked in the submission queue.
More to the point, it makes me wonder what issues are important to the editors of this site but which are not being clearly articulated in the FAQ's on submitting. I.e. I must be doing something wrong, but for the life of me I can't figure out what.
Kathleen Fent
Damn! You beat me to it.
And there are other Digital Rights Management features in Replay 4000 that have NOT yet been reported upon. I'm a Replay 4000 owner, and I can comment on some of these.
SonicBlue licenses Macrovision's technology, which is the same signal-munging technology that keeps VCR's from recording the output of your DVD player.
The interesting part is that a Replay 4000 will let you record a Macrovision-encoded program. I personally tested this by feeding the output of my DVD player into the secondary input on my Replay 4160 as a test. The Replay reproduces the Macrovision signal when outputting the program. This means you can time-shift copy-protected shows, but you cannot dub them out of the Replay onto a VCR!
Also, according to this press release, when a Replay 4000 sees that a show is Macrovision-encoded, it will not allow the user to share this program over the internet.
I think this is a pretty decent compromise between preserving the customer's ability to time-shift programs, and the program-owner's right to control copying of that program on permanent media.
And vis-a-vis the big conglomerates, this is a big change from the early Replay units. I've owned a Replay 2004 for over two years, and those early units would strip the Macrovision encoding from shows you passed through it. Thus they could be used as an intermediary for dubbing DVD's and other protected content to tape.
For this and other reasons I really think the media giants are going to fall on their face in this lawsuit. No judge is going to side with them when its so obvious that SonicBlue has made these efforts to accomodate their interests.
If you have anything to do with designing any sort of interface to any sort of product (be it a piece of hardware, a piece of software, a widget, whatever), you should read this book. It will open your eyes.
For fairness, here is a link to a follow up letters column that disputes some of the facts in the article.
Quite an eye-opener.
Sure they could. In his proposal, he had folks logging in so they could demographically target ads at them, right? Well the login information includes where the person lives, right?
You simply pay the affiliates a percentage of the ad revenue based on how many people in their area viewed the stream.
Voila, everyone is happy.
> but one theory is that they started checking
> the version number submitted in the
> Authentication request(or something similar).
Actually I sniffed this to look. Trillian actually lies to the Oscar server and tells it that it is a particular version of AIM. This is probably necessary to even log on given AOL's attitude. (And this is possibly the basis of the PR flacks "hacking" accusation).
What it looked like AOL started doing was "slamming shut" the Oscar connection (with a TCP RST packet coming back to the client) after it was complete. If you've ever sniffed AIM, you'll see it makes an initial connection to the Oscar server to authenticate, and in that connection an IP address is sent down. The actual IM connection is made to that other IP address.
It looked to me like Trillian was expecting the Oscar connection to close normally, and barfed when it got the RST packet. It's possible the AIM client doesn't care about this.
FWIW I'm running Trillian 0.721 right now, and I'm connected *AND* I have the SecureIM feature turned on. So right at this moment Cerulean Studios is winning the battle.
Pay attention people! You there, in the back, is that gum in your mouth?
Of course I don't watch a ton of long feeds on the net, mostly short things like movie trailers or clips. Maybe thats the difference?
I found an nice free website that will run a JavaScript in your browser that detects various kinds of spyware and directs you to instructions on how to remove it. He also offers the source up for free so webmasters can help combat this scourge by hosting the script on their own pages. (That way all your site visitors will be warned about they spyware as they visit your site). It doesn't seem to detect this one though.
I dug this up when I discovered a few months back that AudioGalaxy had secretly installed a similar application called VX2 on my PC. The odd thing was that Audio Galaxy wanted to install BonziBuddy too, but it let me choose. But no choice with this other one. Fortunately it was easy to remove and AG runs fine without it.
> by Ramses the Great. When the Aswan High Dam was about to be built, engineers realized
> the temple would be buried under all of the water flow. So, it was moved to a higher
> location that would be safer. Of course, they did that without the use of
> supercomputers and 3D modelling
I was gonna mention that but you beat me to it. I remember being fascinated as a kid reading the National Geographic article where they showed the whole project in detail. Each block was carefully sliced out of the mountain and numbered for reassembly.
Here's a good link with lots of pictures of Abu Simbel.
Well you gotta pay for the equipment, but ReplayTV's units carry no ongoing subscription fees.
> they hooked up a NIDS to a SMARTBITS and reported the results I'll take it back.
Well for one, the review we are talking about, which you can download here, used a SmartBits (among other things) to generate background traffic during the performance tests. See pages 167 and 228 in the report.
Page 165: The Tests
all available signatures enabled
This is not a level playing field. The product that I helped build (ISS RealSecure) contains a number of signatures that are not intended to be turned on in normal usage. For instance, RealSecure can generate an even for every single HTTP GET request on your network, no matter how inane.
This feature is intended to be used as a special purpose tool, for instance to analyze web usage over the short term. It is not intended to be turned on during normal IDS usage. If you do turn it on, it often overwhelms your console with tons of incidental data and rapidly fills your logs.
Page 166-167: Performance Under Load
Another RealSecure specific problem here is that RealSecure deliberately drops redundant reports and does not count them, so that you do not get inundated with a million messages that tell you the exact same thing. Therefore I would expect it to fare very poorly in the boping count test.
Others in this thread have pointed out the danger of using tools like SMARTBITS to generate background traffic. The problem is that unless you really know what you are doing, SMARTBITS is likely to generate traffic that is entirely unrealistic. (For instance, TCP data packets that don't correspond to an actual open session that the IDS would have been tracking). This can cause both unrealistically good and unrealistically bad performance, depending on what the background traffic actually is and how the IDS is built.
The assertion early in this section that "if a sensor detects 100 per cent of attacks at 100 per cent load in this test" (of minimum length packets) that it "can handle anything that islikely to be thrown at it" is patent BS. Yes this is the worst case scenario of "packets per second", but packets per second is not the most important metric here.
I also note on page 177 and 178 in a footnote that neither RealSecure nor BlackICE were "re-tested for Edition 2", yet they are not reluctant to conclude that SNORT is better than the commercial products. I think we've got an apples and oranges problem here.
I also question whether their assertion that all products were tested with their latest signature updates can possibly true, if they didn't retest all the products. Most of the commercial vendors release new signatures on a regular basis.
(This is also true for the Cisco, CA, Symantec, Enterasys and other products in the comparison, if you read the footnotes carefully).
> NIDS should be flogged and then shot in the kneecap
I am aware of the fact that SMARTBITS alone is not sufficient to properly test a network IDS. I was merely giving an example of the expense someone has to incur to set up proper simulation environments to exercise their products so they will have good behavior in real-world networks.
SMARTBITS, while not sufficient by itself to properly test an IDS, is a tool that lets you push Ethernets to (and beyond) their theoretical limits. This is VERY DIFFICULT to do with other solutions.
> > Not to mention trying to compare NetIce to Snort is like apples
> > and oranges. NetIce does protocol analysis...
I see that, like many, you have fallen prey to Network ICE's excellent marketing machine. Yes, it does do protocol analysis, but it is not unique in this respect. RealSecure (ISS'es product prior to buying Network ICE) did protocol analysis before BlackICE even existed. NETICE was just better at getting that marketing message out. (Reminder: I've seen the source code to both products, and wrote large hunks of one of them).
And I don't think you were flaming, its a very legit suggestion.
I am afraid if you do you are in for a RUDE awakening. The fact of the matter is that these $20,000 solutions cost that much for a reason, and the reason is they've spent years optimizing them for high speed links. This is something the hobbiest programmers who work on Snort cannot compete with. For instance, what open source coder has a SMARTBITS on their desk? Something like that is essential to test these things, but they cost upwards of $10,000.
So I would say yes, if all you want to do is monitor a T1 or two, and you're willing to tinker alot, something like Snort would work. But if you have a SERIOUS network with lots of bandwidth, you're gonna have to pony up the dough.
Disclosure: I helped build one of the systems that Snort supposedly beat, and I analyzed the source code for another one that was bought by that company. Snort CANNOT beat either one in a high bandwidth situation. I've seen the code, I've run the tests, trust me.
I no longer work for that company so have little to gain by saying this.
I've had a ReplayTV for two years now, and have been very happy with the hardware and the company. I'm looking forward to upgrading.
Best of all, (and unlike the Rio Volt SP250), it has a quite usable UI that lets you search your disks for MP3's by Artist, Title, Genre and so on. (On the other hand, the Rio has an FM tuner, and plays WMA files too). The UI is what sold me on this unit, it really is the make-or-break.
$128 at buy.com
Open source, like everything else in life, strictly follows Sturgeon's Law: Ninety percent of everything is crud
Yes, that's right. You need to be plugged in when you boot or it can't determine if there is a conflict. This is no different from DHCP, where you need to be plugged in at boot in order to receive an address.
> happen, there is always the chance that two
> machines will grab the same IP address.
First of all it's not the "Windows" random assignment. The 169.254 stuff is a public spec, and so far both Windows and MacOS support it. It's called "Dynamic Configuration of IPv4 Link-Local Addresses" and you can read about it here. (Microsoft's implementation is called APIPA and you can read about it here).
Have you ever actually seen an address conflict happen? It's not supposed to under the spec. Each box after picking a proposed address is supposed to ARP it. If it gets a reply, it then tries again. And so on. Works kind of like a hash table.
I dislike Microsoft's business practices as much as the next guy. But if you want to convince me that one of their technologies has a problem you have to back it up with facts, not religious zealotry.
Tell Mulder and Scully I said HI, clearly you live somewhere in their fictional world.