But coke already does the dirty "we'll give you big discounts on coca-cola products if you promise not to carry pepsi products" thing. No idea if Real does this with encoder/stream licensing.
because it's all about MONEY. i totally agree with you, and these questions shouldn't even need to be asked.
Unfortunately, everyone wants to convince the world that their proprietary codec or streaming protocol is TEH BEST, but it's not based on the merits of the protocol, only on how much fame/fortune and licensing revenues it can bring to the company pushing it.
countless minutes of my life lost into a sock, watching her on that show. She's one of those hotties that -should- have done playboy before getting old.
anyway, BPL is evil. just as evil as IP over carrier pigeon. They both have dirty side effects.
Now that the VFS layer has been stabilized and supportive of such FS drivers as XFS, very little needs to be changed to add XFS support. It's almost completely "additive", rather than modifying the existing code.
XFS would help 12,000,000 people if those people used XFS. I'm sure 12,000,000 people would agree that having a more reliable filesystem that's less likely to be corrupted or lose data during a power failure or emergency-laptop-shutting, and takes no more than 5 seconds to run consistency checks during startup, regardless of filesystem size, is more important than something that improves the responsiveness of the system in certain high-load situations.
Now, do your part and advise 12,000,000 linux users that there are low-latency preemptive kernel patches and a filesystem more robust/stable/reliable than ext2/ext3. Let them decide, instead of assuming that everyone in the world is like you.
Extended ACLs, btree filesystem structures to facilitate huge files, fast sparse files, large directories, fast deletes, and a couple other niceties that would have required huge functional changes to ext2/ext3 to implement. It's also completely 64-bit clean, as it has from its conception.
The btree-based storage structure is already employed by reiserfs in a similar manner, but XFS' implementation has been stable (used in IRIX) for quite a bit longer.
This "big merge" has nothing to do with vendor pressure. The XFS patches have been available and well-tested throughout most of the 2.4 kernel's life cycle and since its (XFS') stability has already been proven to play nicely with the rest of the kernel, it's quite appropriate to do a merge so late in the 2.4 tree's live cycle. The team at SGI that handles merging the XFS code into the kernel have done a very good job of keeping up with bug reports and changes in the kernel vfs code.
Marcelo probably shares my opinion in that the current XFS code has been around long enough, demonstrated stability, and successfully merged with every recent 2.4 kernel back to at least 2.4.1x, that it's more than suitable for inclusion in the main kernel source without risk of introducing instability.
The only clashes I've ever seen with XFS and other code was with other 3rd-party patches, such as the ACL support in grsecurity. Those are now "switchable", anyway.
Holy shit. 20A at 240V? You're dissipating about 4800W of heat there. Does that 20A also include the current for an _air conditioner_ to keep the room cool?
Careful. It's actually quite easy to implement per-circuit power metering (as they do in colo facilities) One day they're going to realise that charging for excessive power usage would be practical and profitable.
Enter the "wide-spaced, rotated-socket power strip". One of these babies makes my DSL bridge, radio and cell phone chargers, and speaker wall transformers all very happy to be plugged in near eachother.
But he's suggesting pulling power from -two- 110volt legs. Two 110v/15a legs will give you 3300watts maximum (+/- adjustment for load factor). Same amount of power available on a 220v/15a single circuit.
The amount of power would be the same for each of the two 110v legs, measured individually.
The number of tracks a drive has is inconsequential to the access time. The time it takes for the read/write head to move across the platter (since the platters in ide and scsi drives are nearly the same size) is a product of how heavy the heads are and the strength of the motor assembly (which is actually a pair of coils moving between two very strong magnets). I'm inclined to believe that the IDE drive's slower seek performance is actually because if a cheaper head/motor mechanism. After all, the IDE drive _is_ cheaper, so this is one place where costs are cut.
As far as buffering is concerned, random access reads, such as when reading in many small files, does NOT benefit in speed from larger on-drive caches. That cache is used mostly for multi-block read-ahead and write-back on sequential accesses, and is usually segmented into "areas", where sections of cache memory are linked to sections (cylinder groups) of the platters. The more cache you have on the drive, the less "thrashing" the drive has to do when many disperse files are written to, since it can group many operations into their appropriate "areas" of cache. This doesn't help as much for random reads (like maildir!) as for sequential reads.
So why does scsi really have an advantage? 1) tagged queuing. The host controller can queue up to 255 (depending on the controller and drives) commands to each drive, and can request the drive to "update" the controller on its status completely asynchronously, and in groups of responses. With one single "message" from the controller, the scsi drive gets up to 255 times as many low-level commands (block reads/writes/seeks/cache ops) as one command between an ide controller and its drive. For the test in that article, the host OS simply had to read the directory, and send off a bunch of commands to the SCSI controller to read a list of blocks, and notify the host when it was done moving everything into memory. Meanwhile, the IDE drive was busy doing every operation one at a time.
2) multi-processing-friendly communications protocol. Because of the way scsi offloads most of the processing from the host, the host can spend less time waiting for an interrupt to complete (remember, an IDE device can only complete one low-level command at a time, per interrupt), and group commands from many processes together into one stream of scsi commands, or multiplex commands to multiple devices on the scsi bus in one operation. IDE is incapable of sending commands to two devices on the bus simultaneously. i.e. It must wait for an operation to the master drive to complete before sending something to the slave on the same channel, or to a drive on a different channel. In the test, the SCSI drive performed so well even though it was on a 'server' sharing resources with other processes because the OS was able to group commands together from all the different processes, while the IDE system had to "pause" programs that were waiting "in line" for ide operations from another process to finish. These processes can also include kernel disk read-ahead threads, write-back buffering, other programs on the system, etc.
IDE will eventually have tagged queuing (some controllers/drives already support it), but there's still the problem of the IDE controller holding the host in an interrupted state (interrupt contention) while the operations complete. It's how the IDE spec works. DMA helps a lot here, but only makes the data transfer faster. The time the various low-level commands take and how they tie up the host cpu is still the bottleneck. To be fair, SATA should have all this stuff covered, and will likely bridge the gap between IDE and SCSI performance, but I don't believe it'll approach the overall reliability and robustness of SCSI.
Disclaimer: I've described the advantages/disadvantages above as best as I could recall. corrections welcome.
Most people would call me an atheist, because I don't believe in a supreme entity whom has complete power over us and our world, but I just realized something. We are God. We've already stopped our own evolution. Before we developed the ability to heal ourselves, kill off or obsolete our only natural predators and shield ourselves from any natural threat, we were HAPPY to live to a ripe age of 30-40 years. It was plenty of time to raise a family and pass on our general knowledge of our simple little world.
200 years ago, we didn't know what cancer was. Not because we had no way to SEE it or diagnose it, but because it simply didn't happen (short of the very low rates of actual cancer manifestations.) When someone got sick from a terminal disease, it was just accepted as a fact of life, and those people became a statistic of Darwin's laws.
Now, people with congenital diseases (or diseases inherited from parents, or combinations of parents' genes which give the child a high predisposition for a disease) are surviving longer AND reproducing, causing such diseases and predispositions to prosper. On the other side of the same coin, we're weakening our species' immunities to congestive diseases by artificially suppressing and preventing them with medicine.
Biomedical engineering is also causing as much harm as good. Sure, we've eliminated many Really Bad Diseases. But now there are mutated versions of the same diseases (viral and bacterial) that survived our initial campaigns to eliminate them, which have proven to be much more resistant to our medicines and techniques. Virii and bacteria are still evolving, and there's nothing WE can do to stop that. It's only going to get worse.
Don't get me wrong here. I'm happy and extremely grateful to live a longer, healthier, and safer life than my predecessors. But we're taking this whole "Live Longer!" thing to an extreme that will only be detrimental in the long run. In fact, overpopulation is one of the immediately obvious effects of this. Why are we spending billions and billions of dollars and as many man hours every year, intentionally extending the lifespan of our individuals, instead of the collective species?
God (the one that most people in the world pray to) NEVER intended us to live this long. If God exists, I believe cancer, AIDS, SARS, and Osama bin Laden (sorry, couldn't resist:) are simply His latest attempts to curb the population problem that we've initiated.
Creating 'super mice' might be a great novelty at first, and a boon to science, but what we learn from them certainly wont benefit our species. Just ourselves. Seems a bit selfish, ignoring the decline in quality of life many generations in the future will be faced with.
(Yes, I'm playing the devil's advocate here, but it's a point I REALLY wish more people would consider)
Why would microsoft buy them out? Phil Goldman and webtv are(were?) practically in bed with microsoft.
I'm sure they already have some under-the-table agreement to let microsoft use the technology, and seeing that microsoft was basically responsible for webtv's success (when it was successful), Goldman would be stupid to bite that hand by refusing microsoft the "privilege" of that technology.
Unless you code your 'spambot' with a viable Turing engine and/or OCR software, AND you use a valid working email address as the sender address, your spambot is effectively useless.
An AI or other relatively smart parser/evaluator would be needed to solve the challenge puzzle, or an OCR system to read the obfuscated text in an attached image would be needed to solve the challenge, and you wont even get the challenge if your From: address is forged.
It's a very effective system if done right. No spammer would go through the trouble of implementing these things AND expect to receive and reply to as many 'challenges' as the initial emails he/she sends out.
This patent is meant to make sure the ideas remain in the public domain, and was only applied for so some money-grubbing pharmaceutical company doesn't do it and then turn around and demand money for the implementation of the ideas.
Patents alone don't stifle innovation. They simply make sure nobody else is allowed to take credit for things. In this case, that's a GOOD thing, because since he's indicated that he WANTS people to use the information in this patent, there's no chance of someone "violating" it.
IP RANGES - MediaForce "MediaDecoys" have been spotted on irc networks (dalnet and efnet, at least) from these netblocks: 4.23.190.*, 65.247.105.* (matching *.regional-one.net hostnames), and 65.215.219.* They have another netblock 208.251.137.0/24, as well.
MODUS OPERANDI - The "Decoys" are described briefly at http://www.mediaforce.com/services/mediadecoy.asp
The description they give their MediaDecoys exactly describes what we call a Denial of Service attack. They're boasting that their decoys are capable of flooding an alleged copyright infringer with requests to prevent anyone else from downloading from them. Such an action is unambiguously illegal in many states, and this company is doing it all without actually verifying that the person is offering AND sending a copyrighted work. They're taking blatantly abusive action against people that haven't been proven to be violating any laws.
The decoys that we see on IRC essentially do the following (discovered by watching their activity from the viewpoint of the irc server itself):
1) after connecting to an irc server, issue a LINKS command, presumably to discover more irc servers to connect to
2) occasionally do a LIST to get lists of large public channels
3) join the discovered channels and watch for activity
4) if there are any public fserves advertising in the channel, the decoy first attempts to do a public trigger to activate the fserve and get a list of files being shared from it
5) if the channel is moderated the decoy attempts to trigger the fserve directly via private msg or ctcp, or does a standard XDCC LIST. No files are actually requested or downloaded
6) after 2 or 3 minutes of no fserve advertisements, the decoy leaves the channel and continues searching for more.
7) the decoys watch channel activity for mentions of any other channel names (channels that are 'private' and don't show up in the public channel list), and attempt to join those channels as well.
8) a few (not many) of these decoys have also been observed sending XDCC LIST commands to other clients that simply have 'dcc' in their nicknames.
Nobody has observed these decoys actually downloading anything, so it baffles me how they can assume that the files being advertised are the actual files being sent if a person COULD download the file, or even assume that the person is in fact SENDING any files. In addition, if there are other decoys on the network whose sole purpose was to launch some sort of attack against irc clients sharing files (as described on the page mentioned above), we haven't found them yet.
Hope this clears a few things up about how their decoys work and what to watch for.
I've received two of these form letters from MediaForce, as well. As a network and security engineer at an ISP, it's my duty to make sure none of my lusers are violating any laws, but ALSO to ensure the privacy of my lusers.
I challenged the sender (Mark Weaver) in both instances to provide proof that the user was in fact sharing what they were being accused of, and asked how it was being shared (irc, p2p, etc). I never got a human response back. It seems they're just shooting blindly at users and their ISPs, hoping that the ISP will disconnect the "copyright infringer" without questioning MediaForce's (apparent) authority.
MediaForce has NO RIGHT AT ALL to tell ISPs to terminate a user's account for only an alleged copyright violation, especially if such allegations don't conflict with the ISP's acceptable-use-policy. Even if the AUP has a "do not break any laws" clause, no laws have been broken until a conviction is handed down.
I'd say it's completely safe to ignore the form letters these bastards are spewing forth. It's nothing more than a scare tactic, and perhaps just something to show their copyright-holding clients that they're actually working for whatever they're charging for the "service".
MediaForce is not authorized to enforce any laws, in America or abroad. It doesn't matter whether or not the user they were accusing was making copyrighted works available for sharing.
The copyright owner is obligated to notify the local authorities about the violation, while providing evidence showing that the user was in fact making the software available to download and not just putting the name of the file in a list called "downloads", or offering the file without actually sending it to anyone. Unless they can prove that the file was in fact being SHARED, no violation of any law has been committed.
It seems MediaDorks has appointed themselves as an authority in enforcing copyright laws, whether they apply to the alleged infringer's locality or not, and using this "business model" to generate revenue by charging the "copyright owners" for the service.
I'd honestly love to see vigilante groups start doing this and have the government turn a blind eye to the activity, but judging spammers and sentencing them to physical punishment outside of a court of law wont sit well with "legitimate" law enforcement.
It's unfortunate that law enforcement has a monopoly on law enforcement.
Look up the ip addresses of any websites advertised in the next several spams you get. Chances are, if it's about mortgages, russian mail-order brides, spamming-for-spam, collecting J U D I C I A L J U D G E M E N T S, etc, the website is likely hosted in china. So there are certainly people or companies in china involved in the hosting of these fraudulent or deceptive services being spamvertised to america.
And the american counterparts in these spam campaigns get their websites hosted there not because it's legal, but because it's nearly impossible for any US agency to track down the owner of the spamvertised web page (or email address) without significant cooperation from chinese officials. This practice alone is a flag that they're doing something that they KNOW is illegal or bordering on illegal.
Slashdot Mirror
But coke already does the dirty "we'll give you big discounts on coca-cola products if you promise not to carry pepsi products" thing. No idea if Real does this with encoder/stream licensing.
because it's all about MONEY. i totally agree with you, and these questions shouldn't even need to be asked.
Unfortunately, everyone wants to convince the world that their proprietary codec or streaming protocol is TEH BEST, but it's not based on the merits of the protocol, only on how much fame/fortune and licensing revenues it can bring to the company pushing it.
ah, loni anderson.
countless minutes of my life lost into a sock, watching her on that show. She's one of those hotties that -should- have done playboy before getting old.
anyway, BPL is evil. just as evil as IP over carrier pigeon. They both have dirty side effects.
Now that the VFS layer has been stabilized and supportive of such FS drivers as XFS, very little needs to be changed to add XFS support. It's almost completely "additive", rather than modifying the existing code.
XFS would help 12,000,000 people if those people used XFS. I'm sure 12,000,000 people would agree that having a more reliable filesystem that's less likely to be corrupted or lose data during a power failure or emergency-laptop-shutting, and takes no more than 5 seconds to run consistency checks during startup, regardless of filesystem size, is more important than something that improves the responsiveness of the system in certain high-load situations.
Now, do your part and advise 12,000,000 linux users that there are low-latency preemptive kernel patches and a filesystem more robust/stable/reliable than ext2/ext3. Let them decide, instead of assuming that everyone in the world is like you.
Extended ACLs, btree filesystem structures to facilitate huge files, fast sparse files, large directories, fast deletes, and a couple other niceties that would have required huge functional changes to ext2/ext3 to implement. It's also completely 64-bit clean, as it has from its conception.
The btree-based storage structure is already employed by reiserfs in a similar manner, but XFS' implementation has been stable (used in IRIX) for quite a bit longer.
This "big merge" has nothing to do with vendor pressure. The XFS patches have been available and well-tested throughout most of the 2.4 kernel's life cycle and since its (XFS') stability has already been proven to play nicely with the rest of the kernel, it's quite appropriate to do a merge so late in the 2.4 tree's live cycle. The team at SGI that handles merging the XFS code into the kernel have done a very good job of keeping up with bug reports and changes in the kernel vfs code.
Marcelo probably shares my opinion in that the current XFS code has been around long enough, demonstrated stability, and successfully merged with every recent 2.4 kernel back to at least 2.4.1x, that it's more than suitable for inclusion in the main kernel source without risk of introducing instability.
The only clashes I've ever seen with XFS and other code was with other 3rd-party patches, such as the ACL support in grsecurity. Those are now "switchable", anyway.
Holy shit. 20A at 240V? You're dissipating about 4800W of heat there. Does that 20A also include the current for an _air conditioner_ to keep the room cool?
Careful. It's actually quite easy to implement per-circuit power metering (as they do in colo facilities) One day they're going to realise that charging for excessive power usage would be practical and profitable.
Enter the "wide-spaced, rotated-socket power strip". One of these babies makes my DSL bridge, radio and cell phone chargers, and speaker wall transformers all very happy to be plugged in near eachother.
But he's suggesting pulling power from -two- 110volt legs. Two 110v/15a legs will give you 3300watts maximum (+/- adjustment for load factor). Same amount of power available on a 220v/15a single circuit.
The amount of power would be the same for each of the two 110v legs, measured individually.
Nevermind. Mister Editor fixed it.
Maybe quoting submissions "verbatim" isn't such a good idea. I nearly went into convulsions trying to parse that submission.
Letting things like that get through makes the slashdot front page look a bit less "intelligent." What kind of demographic are we catering to again?
The number of tracks a drive has is inconsequential to the access time. The time it takes for the read/write head to move across the platter (since the platters in ide and scsi drives are nearly the same size) is a product of how heavy the heads are and the strength of the motor assembly (which is actually a pair of coils moving between two very strong magnets). I'm inclined to believe that the IDE drive's slower seek performance is actually because if a cheaper head/motor mechanism. After all, the IDE drive _is_ cheaper, so this is one place where costs are cut.
As far as buffering is concerned, random access reads, such as when reading in many small files, does NOT benefit in speed from larger on-drive caches. That cache is used mostly for multi-block read-ahead and write-back on sequential accesses, and is usually segmented into "areas", where sections of cache memory are linked to sections (cylinder groups) of the platters. The more cache you have on the drive, the less "thrashing" the drive has to do when many disperse files are written to, since it can group many operations into their appropriate "areas" of cache. This doesn't help as much for random reads (like maildir!) as for sequential reads.
So why does scsi really have an advantage?
1) tagged queuing. The host controller can queue up to 255 (depending on the controller and drives) commands to each drive, and can request the drive to "update" the controller on its status completely asynchronously, and in groups of responses. With one single "message" from the controller, the scsi drive gets up to 255 times as many low-level commands (block reads/writes/seeks/cache ops) as one command between an ide controller and its drive. For the test in that article, the host OS simply had to read the directory, and send off a bunch of commands to the SCSI controller to read a list of blocks, and notify the host when it was done moving everything into memory. Meanwhile, the IDE drive was busy doing every operation one at a time.
2) multi-processing-friendly communications protocol. Because of the way scsi offloads most of the processing from the host, the host can spend less time waiting for an interrupt to complete (remember, an IDE device can only complete one low-level command at a time, per interrupt), and group commands from many processes together into one stream of scsi commands, or multiplex commands to multiple devices on the scsi bus in one operation. IDE is incapable of sending commands to two devices on the bus simultaneously. i.e. It must wait for an operation to the master drive to complete before sending something to the slave on the same channel, or to a drive on a different channel. In the test, the SCSI drive performed so well even though it was on a 'server' sharing resources with other processes because the OS was able to group commands together from all the different processes, while the IDE system had to "pause" programs that were waiting "in line" for ide operations from another process to finish. These processes can also include kernel disk read-ahead threads, write-back buffering, other programs on the system, etc.
IDE will eventually have tagged queuing (some controllers/drives already support it), but there's still the problem of the IDE controller holding the host in an interrupted state (interrupt contention) while the operations complete. It's how the IDE spec works. DMA helps a lot here, but only makes the data transfer faster. The time the various low-level commands take and how they tie up the host cpu is still the bottleneck. To be fair, SATA should have all this stuff covered, and will likely bridge the gap between IDE and SCSI performance, but I don't believe it'll approach the overall reliability and robustness of SCSI.
Disclaimer: I've described the advantages/disadvantages above as best as I could recall. corrections welcome.
Most people would call me an atheist, because I don't believe in a supreme entity whom has complete power over us and our world, but I just realized something.
:) are simply His latest attempts to curb the population problem that we've initiated.
We are God.
We've already stopped our own evolution. Before we developed the ability to heal ourselves, kill off or obsolete our only natural predators and shield ourselves from any natural threat, we were HAPPY to live to a ripe age of 30-40 years. It was plenty of time to raise a family and pass on our general knowledge of our simple little world.
200 years ago, we didn't know what cancer was. Not because we had no way to SEE it or diagnose it, but because it simply didn't happen (short of the very low rates of actual cancer manifestations.) When someone got sick from a terminal disease, it was just accepted as a fact of life, and those people became a statistic of Darwin's laws.
Now, people with congenital diseases (or diseases inherited from parents, or combinations of parents' genes which give the child a high predisposition for a disease) are surviving longer AND reproducing, causing such diseases and predispositions to prosper. On the other side of the same coin, we're weakening our species' immunities to congestive diseases by artificially suppressing and preventing them with medicine.
Biomedical engineering is also causing as much harm as good. Sure, we've eliminated many Really Bad Diseases. But now there are mutated versions of the same diseases (viral and bacterial) that survived our initial campaigns to eliminate them, which have proven to be much more resistant to our medicines and techniques. Virii and bacteria are still evolving, and there's nothing WE can do to stop that. It's only going to get worse.
Don't get me wrong here. I'm happy and extremely grateful to live a longer, healthier, and safer life than my predecessors. But we're taking this whole "Live Longer!" thing to an extreme that will only be detrimental in the long run. In fact, overpopulation is one of the immediately obvious effects of this. Why are we spending billions and billions of dollars and as many man hours every year, intentionally extending the lifespan of our individuals, instead of the collective species?
God (the one that most people in the world pray to) NEVER intended us to live this long. If God exists, I believe cancer, AIDS, SARS, and Osama bin Laden (sorry, couldn't resist
Creating 'super mice' might be a great novelty at first, and a boon to science, but what we learn from them certainly wont benefit our species. Just ourselves. Seems a bit selfish, ignoring the decline in quality of life many generations in the future will be faced with.
(Yes, I'm playing the devil's advocate here, but it's a point I REALLY wish more people would consider)
Why would microsoft buy them out? Phil Goldman and webtv are(were?) practically in bed with microsoft.
I'm sure they already have some under-the-table agreement to let microsoft use the technology, and seeing that microsoft was basically responsible for webtv's success (when it was successful), Goldman would be stupid to bite that hand by refusing microsoft the "privilege" of that technology.
Unless you code your 'spambot' with a viable Turing engine and/or OCR software, AND you use a valid working email address as the sender address, your spambot is effectively useless.
An AI or other relatively smart parser/evaluator would be needed to solve the challenge puzzle, or an OCR system to read the obfuscated text in an attached image would be needed to solve the challenge, and you wont even get the challenge if your From: address is forged.
It's a very effective system if done right. No spammer would go through the trouble of implementing these things AND expect to receive and reply to as many 'challenges' as the initial emails he/she sends out.
This patent is meant to make sure the ideas remain in the public domain, and was only applied for so some money-grubbing pharmaceutical company doesn't do it and then turn around and demand money for the implementation of the ideas.
Patents alone don't stifle innovation. They simply make sure nobody else is allowed to take credit for things. In this case, that's a GOOD thing, because since he's indicated that he WANTS people to use the information in this patent, there's no chance of someone "violating" it.
Absolutely. now, wouldn't THAT throw them off course in their accusatory ventures.
IP RANGES - MediaForce "MediaDecoys" have been spotted on irc networks (dalnet and efnet, at least) from these netblocks:
4.23.190.*, 65.247.105.* (matching *.regional-one.net hostnames), and 65.215.219.*
They have another netblock 208.251.137.0/24, as well.
MODUS OPERANDI - The "Decoys" are described briefly at http://www.mediaforce.com/services/mediadecoy.asp
The description they give their MediaDecoys exactly describes what we call a Denial of Service attack. They're boasting that their decoys are capable of flooding an alleged copyright infringer with requests to prevent anyone else from downloading from them. Such an action is unambiguously illegal in many states, and this company is doing it all without actually verifying that the person is offering AND sending a copyrighted work. They're taking blatantly abusive action against people that haven't been proven to be violating any laws.
The decoys that we see on IRC essentially do the following (discovered by watching their activity from the viewpoint of the irc server itself):
1) after connecting to an irc server, issue a LINKS command, presumably to discover more irc servers to connect to
2) occasionally do a LIST to get lists of large public channels
3) join the discovered channels and watch for activity
4) if there are any public fserves advertising in the channel, the decoy first attempts to do a public trigger to activate the fserve and get a list of files being shared from it
5) if the channel is moderated the decoy attempts to trigger the fserve directly via private msg or ctcp, or does a standard XDCC LIST. No files are actually requested or downloaded
6) after 2 or 3 minutes of no fserve advertisements, the decoy leaves the channel and continues searching for more.
7) the decoys watch channel activity for mentions of any other channel names (channels that are 'private' and don't show up in the public channel list), and attempt to join those channels as well.
8) a few (not many) of these decoys have also been observed sending XDCC LIST commands to other clients that simply have 'dcc' in their nicknames.
Nobody has observed these decoys actually downloading anything, so it baffles me how they can assume that the files being advertised are the actual files being sent if a person COULD download the file, or even assume that the person is in fact SENDING any files. In addition, if there are other decoys on the network whose sole purpose was to launch some sort of attack against irc clients sharing files (as described on the page mentioned above), we haven't found them yet.
Hope this clears a few things up about how their decoys work and what to watch for.
Max, the webspider monkey says "MediaForce Sucks!"
I've received two of these form letters from MediaForce, as well. As a network and security engineer at an ISP, it's my duty to make sure none of my lusers are violating any laws, but ALSO to ensure the privacy of my lusers.
I challenged the sender (Mark Weaver) in both instances to provide proof that the user was in fact sharing what they were being accused of, and asked how it was being shared (irc, p2p, etc). I never got a human response back. It seems they're just shooting blindly at users and their ISPs, hoping that the ISP will disconnect the "copyright infringer" without questioning MediaForce's (apparent) authority.
MediaForce has NO RIGHT AT ALL to tell ISPs to terminate a user's account for only an alleged copyright violation, especially if such allegations don't conflict with the ISP's acceptable-use-policy. Even if the AUP has a "do not break any laws" clause, no laws have been broken until a conviction is handed down.
I'd say it's completely safe to ignore the form letters these bastards are spewing forth. It's nothing more than a scare tactic, and perhaps just something to show their copyright-holding clients that they're actually working for whatever they're charging for the "service".
Max, the webspider monkey says "MediaForce Sucks!"
MediaForce is not authorized to enforce any laws, in America or abroad. It doesn't matter whether or not the user they were accusing was making copyrighted works available for sharing.
The copyright owner is obligated to notify the local authorities about the violation, while providing evidence showing that the user was in fact making the software available to download and not just putting the name of the file in a list called "downloads", or offering the file without actually sending it to anyone. Unless they can prove that the file was in fact being SHARED, no violation of any law has been committed.
It seems MediaDorks has appointed themselves as an authority in enforcing copyright laws, whether they apply to the alleged infringer's locality or not, and using this "business model" to generate revenue by charging the "copyright owners" for the service.
Max, the webspider monkey says "MediaForce Sucks!"
acting as if they own the PATENT on p2p or something.
Noble cause, bad execution.
I'd honestly love to see vigilante groups start doing this and have the government turn a blind eye to the activity, but judging spammers and sentencing them to physical punishment outside of a court of law wont sit well with "legitimate" law enforcement.
It's unfortunate that law enforcement has a monopoly on law enforcement.
Look up the ip addresses of any websites advertised in the next several spams you get. Chances are, if it's about mortgages, russian mail-order brides, spamming-for-spam, collecting J U D I C I A L J U D G E M E N T S, etc, the website is likely hosted in china. So there are certainly people or companies in china involved in the hosting of these fraudulent or deceptive services being spamvertised to america.
And the american counterparts in these spam campaigns get their websites hosted there not because it's legal, but because it's nearly impossible for any US agency to track down the owner of the spamvertised web page (or email address) without significant cooperation from chinese officials. This practice alone is a flag that they're doing something that they KNOW is illegal or bordering on illegal.