Actually, I'm sure the engineer would have to run it if only in a debugger to work out what is happening. This thing may well be a "pseudo-trojan" so it may be a case of running it under VMWare to see what happens.
I make 6$ an hour, there is no way I would even spend 2$ a month on this subscription service
That's $24 a year you are not willing to spend on the subscription. That's less than the price of one computer game and if you aren't willing to part with a fraction of a game's worth then IMO you don't buy enough games to make the valuable gamespot worthwhile to yourself. You may as well get the information elsewhere.
But if you are willing to pay a fraction of a game's worth a year to get a valuable service then that is what Gamespot is looking for.
Probably not... it was some months back so it ought to be fixed by now. I can't imagine a machine rebooting once every 5 minutes for the past few months =P
I'Id hate to see a port of WinCE on a cash register
Heh, well at Wimbledon station in the UK, they run Windows NT to sell train tickets in one of those electronic hole in the wall ticket dispensers. (Choose ticket, insert money, out pops ticket).
While waiting for my pickup, I amused my self as the machine spontaneously rebooted, saw the NT4 loader in it's comforting blue screen, see Windows launch, autologin, connect to some network shares and start up the ticket selling interface. And then watch it spontaneously reboot again =P
I was referring to embedding extra features (aka spyware) into their product without making it clear that they are doing so (except in a EULA less clear than a tax form). I consider a rip off is when you don't get what you bargained for and that is how I view Kazaa today
That's hitting the nail on the head. Who do you trust more? Do you trust the original authors who hid the spyware in your program but are possibly giving some legal notice in the EULA (bleh), so they aren't completely rogue, but are ripping you off? Or do you trust the rogue programmer who claims to have fixed the spyware but maybe has slipped his own trojan in instead?
In the case of Kazaa Lite, I trust the rogue coder but I won't have that attitude on patched software for long. I think I would rather wait for my Slashdot peers to "beta test" these patched versions and find out if their computers die, before I even consider downloading patched up pirate software
Then CNET should delist this
on
Spyware Fights Back
·
· Score: 4, Interesting
If they have delisted Kazaa for it's deceptive practices, surely CNET should remove RadLight for similar reasons. This is way over the top.
It's hard for Kazaa to mass change the protocls they are using as it could break too many clients... unless of course their first use of their spyware is to check for the new version and force a download!
Here comes the the biggest spy/trojan-ware versus the stripped down version
I've worked at a certain big investment bank over the summer. Internet access there was completely firewalled away except for a port 80 HTTP proxy server. Now, one could tunnel IM programs through this successfully but even then, the company has a zero-tolerance policy that bans any use of IM programs.
There is a very good reason for this. Apart from the usual virus problems, it is often *mandatory* by law for investment banks to log all communications between employees and clients, just like the article says. It is well known that all telephone calls are recorded for this reason. All proxy requests are naturally recorded and scanned for port and external mail use (also against company policy). Allowing IM would equally thus be in violation of company policy and legal requirements. Unless of course... if a system was introduced where all messages could be reliably logged and traced.
If you still aren't convinced about these policy issues, consider this. In a IB, if your phones are tapped, all web access is logged and you know it, then perhaps consider that logging IM isn't such a big extra step.
All that you have stated is correct and actually pretty close at what I was trying to get at.
The article claims that all (99%) script kiddies use IRC and then try to make the inference or image that therefore IRC is bad (by making the implicit suggestion that 99% of IRC users are bad). That kinda FUD winds me up
I dunno how many of you nerds know Bayes Theorem but it's one of the first rules and statisticians learn and, annoyingly, it is one of the more unintuitive arguments for the uninitiated
<Offtopic>I can't stand the current Cannibis debate in the UK where people state something like that 95% of heroin addicts used Cannibis first as a gateway drug. Therefore Cannabis should be illegal. While I agree Cannabis should be illegal, that argument is a statistically false one because you cannot say that 99% of cannabis users go on to take heroin. That would be significant</offtopic>
Here, just because I imagine 99% of script kiddies use IRC, does not mean we should be anti IRC. You cannot map it to the proper argument where I imagine only <1% of all IRC users have anything to do with hacking and scripting. If you, for example, kill IRC, you upset 99% of the populatoin and script kiddies go elsewhere
Exploitation of people's misunderstanding of Bayes makes the easiest and most effective weapon in the world of FUD
This isn't my area of experise... but would it be possible for an open source implementation to be made for Windows? Samba for windows? If it is good enough, then the growing numbers of companies out there that want Windows and Linux to interoperate will have an alternative from the M$ machine with all the benefits of the free (both senses) world. The implementation could be independent on any M$ specification and thus be free from any M$ restriction completely
Well, let me be perfectly clear about this having seen the source to this. Actually, they can license this under LGPL. The reason is the same reason why WINE can be licensed under LGPL and not whatever proprietary licence Microsoft uses
The reason is, having seen their code, is that they do NOT actually use code from the QT libraries at all but they purport to emulate the interface instead. Any indication to the contrary would be a misccmmunication by the authors
So basically, since the source code consists of nothing but cout , I am sure their licensing choice is just fine =)
+5 Informative for anyone who can either point out links to 1) Precompiled binaries made from a Garnome (if it's not too giant) 2) RPMs that will coexist nicely with Gnome 1.4 3) Instructions on how to get Gnome 2 from the Mandrake cooker (yes, it's there) but avoiding the conflicts with gnome 1.4 (and without removing Gnome 1.4)
Asking the user to require 1.1Gbs of build space seems rather excessive! Even the "206Mbs once installed" seems large
Your arguments are well represented and correct. Innovation is the most important point about the patent system. However, I would say the the patent system in its current form is far more harmful to software innovation than beneficial.
I respect your opinion but my opinion is that software is much more like music than engineering when it comes to generating ideas and implementing ideas. Or maybe it is just because the patent system sucks. For example, you bring patented engines as an example. Sometimes I feel that the software world is bringing the equivalent of patenting any and all types of engines as opposed to one type of engine. Many people have a problem with the patent system because the cover of software patents is too wide whereas most physical patents are specific enough to feel fair
Disclaimer: I haven't read the article But here is my take on the analogy... and a pretty good analogy I think it to be.
In Music, there is copyright on pieces of music. You cannot distribute copyrighted music nor resell it without the permission of the copyright holder. I am all for this. In software, if you make a piece of software, you own the copyright and people must get your permission or a license to use the software or source code. That works well too.
Now patents are about ideas. There are no patents in music. You can't stop people from copying the idea that major scales and minor scales sound good. You can't patent the 12 bar blues but you can patent any piece that uses the 12 bar blues. To stop people from using the 12 bar blues seems ludicrous... and it is just as ludicrous as people in software engineering patenting quicksort, mathematical algorithms and compression techniques such that others can't use them for 10 years
If the subciphers are independently keyed, the overall cipher is at least as strong as the weakest subcipher In almost all cases, yes. But not if the two ciphers are a group, for example.
Key length means nothing if you can find analytical attacks. True also but one could just as well find an analytical attack in the combined layered cipher if a "poor" choice in ciphers is chosen
Basically, if I had to choose what cipher to use, I think it is more likely that I would make a mistake in choosing a poor combination of ciphers to layer than I would someone finding an analytical attack in a cipher that has been analysed for decades.
The fact is, both layering and key-growing are both valid and are both used. I just happen to prefer one over the other;)
I'm sure this has been mentioned before... but what about throwing a frisbee? A good frisbee will travel exactly horizontally from source to target and us humans have no problem catching it.
I'm trying to imagine what I would do in space. I can see myself trying to anticipate the not dropping ball and messing up. I can also see myself catching a frisbee with few problems in space. Maybe our brains have learnt from experience that balls tend to drop and frisbees don't as much
I don't quite understand your question there (running through DES with unknown key... extra encryption reducing security) but I'll try to say something helpful
Ok, I'd better disclaim IANACE (crytography expert). I've studied the subject at university level so I know the defintions and have read the facts but have done no analysis myself.
Cracking DES-64 is "easy". Now which is harder to break of these two? DES-64 performed twice with two different keys or DES-128? As it turns out, both are using 128bits worth of key. I would rather use DES-128 on principle since 2^128 is a big key space and current DES breaking difficulty is in the order of brute force as far as I know.
Now what about DES-64 twice? Well, as it turns you might be safe with DES (because I think some people have found it is not a group) BUT suppose we weren't using DES but a symmetric algorithm that *is* a group. Then the hacker could just do a brute force attack on your code with a *64* bit key.
The thing is, I am just touching the surface here. In this case, I have showed that layering using the same cipher that is a group is BAD. Now you could argue, different ciphers etc. etc. but that *may* introduce weaknesses. To know, you would need to analyse it! But why bother when DES and the like have already been analysed to death so you can be fairly sure you are safe at larger key lengths
Slashdot Mirror
Actually, I'm sure the engineer would have to run it if only in a debugger to work out what is happening. This thing may well be a "pseudo-trojan" so it may be a case of running it under VMWare to see what happens.
I make 6$ an hour, there is no way I would even spend 2$ a month on this subscription service
That's $24 a year you are not willing to spend on the subscription. That's less than the price of one computer game and if you aren't willing to part with a fraction of a game's worth then IMO you don't buy enough games to make the valuable gamespot worthwhile to yourself. You may as well get the information elsewhere.
But if you are willing to pay a fraction of a game's worth a year to get a valuable service then that is what Gamespot is looking for.
Probably not... it was some months back so it ought to be fixed by now. I can't imagine a machine rebooting once every 5 minutes for the past few months =P
Oh I sat there long enough for the cycle to happen twice. Daytime too, just when you need 100% availability
Heh, well at Wimbledon station in the UK, they run Windows NT to sell train tickets in one of those electronic hole in the wall ticket dispensers. (Choose ticket, insert money, out pops ticket).
While waiting for my pickup, I amused my self as the machine spontaneously rebooted, saw the NT4 loader in it's comforting blue screen, see Windows launch, autologin, connect to some network shares and start up the ticket selling interface. And then watch it spontaneously reboot again =P
How is it a rip off?
I was referring to embedding extra features (aka spyware) into their product without making it clear that they are doing so (except in a EULA less clear than a tax form). I consider a rip off is when you don't get what you bargained for and that is how I view Kazaa today
That's hitting the nail on the head. Who do you trust more? Do you trust the original authors who hid the spyware in your program but are possibly giving some legal notice in the EULA (bleh), so they aren't completely rogue, but are ripping you off? Or do you trust the rogue programmer who claims to have fixed the spyware but maybe has slipped his own trojan in instead?
In the case of Kazaa Lite, I trust the rogue coder but I won't have that attitude on patched software for long. I think I would rather wait for my Slashdot peers to "beta test" these patched versions and find out if their computers die, before I even consider downloading patched up pirate software
If they have delisted Kazaa for it's deceptive practices, surely CNET should remove RadLight for similar reasons. This is way over the top.
It's hard for Kazaa to mass change the protocls they are using as it could break too many clients... unless of course their first use of their spyware is to check for the new version and force a download!
Here comes the the biggest spy/trojan-ware versus the stripped down version
Mini typo back there... that was meant to be "proxy requests... are scanned for porn". Not sure how you can scan for port =P
I've worked at a certain big investment bank over the summer. Internet access there was completely firewalled away except for a port 80 HTTP proxy server. Now, one could tunnel IM programs through this successfully but even then, the company has a zero-tolerance policy that bans any use of IM programs.
There is a very good reason for this. Apart from the usual virus problems, it is often *mandatory* by law for investment banks to log all communications between employees and clients, just like the article says. It is well known that all telephone calls are recorded for this reason. All proxy requests are naturally recorded and scanned for port and external mail use (also against company policy). Allowing IM would equally thus be in violation of company policy and legal requirements. Unless of course... if a system was introduced where all messages could be reliably logged and traced.
If you still aren't convinced about these policy issues, consider this. In a IB, if your phones are tapped, all web access is logged and you know it, then perhaps consider that logging IM isn't such a big extra step.
All that you have stated is correct and actually pretty close at what I was trying to get at.
The article claims that all (99%) script kiddies use IRC and then try to make the inference or image that therefore IRC is bad (by making the implicit suggestion that 99% of IRC users are bad). That kinda FUD winds me up
You know, that bugs me too. Noone has ever produce that stat. I only keep hearing that the "vast majority" of heroin users used pot first
I dunno how many of you nerds know Bayes Theorem but it's one of the first rules and statisticians learn and, annoyingly, it is one of the more unintuitive arguments for the uninitiated
<Offtopic>I can't stand the current Cannibis debate in the UK where people state something like that 95% of heroin addicts used Cannibis first as a gateway drug. Therefore Cannabis should be illegal. While I agree Cannabis should be illegal, that argument is a statistically false one because you cannot say that 99% of cannabis users go on to take heroin. That would be significant</offtopic>
Here, just because I imagine 99% of script kiddies use IRC, does not mean we should be anti IRC. You cannot map it to the proper argument where I imagine only <1% of all IRC users have anything to do with hacking and scripting. If you, for example, kill IRC, you upset 99% of the populatoin and script kiddies go elsewhere
Exploitation of people's misunderstanding of Bayes makes the easiest and most effective weapon in the world of FUD
This isn't my area of experise... but would it be possible for an open source implementation to be made for Windows? Samba for windows? If it is good enough, then the growing numbers of companies out there that want Windows and Linux to interoperate will have an alternative from the M$ machine with all the benefits of the free (both senses) world. The implementation could be independent on any M$ specification and thus be free from any M$ restriction completely
Well, let me be perfectly clear about this having seen the source to this. Actually, they can license this under LGPL. The reason is the same reason why WINE can be licensed under LGPL and not whatever proprietary licence Microsoft uses
The reason is, having seen their code, is that they do NOT actually use code from the QT libraries at all but they purport to emulate the interface instead. Any indication to the contrary would be a misccmmunication by the authors
So basically, since the source code consists of nothing but cout , I am sure their licensing choice is just fine =)
Oh c'mon! Are there no brits in here? It's one of the famous little rhymes that every schoolkid learns. At least in England
"The rain in Spain stays mainly in the plain"
+5 Informative for anyone who can either point out links to
1) Precompiled binaries made from a Garnome (if it's not too giant)
2) RPMs that will coexist nicely with Gnome 1.4
3) Instructions on how to get Gnome 2 from the Mandrake cooker (yes, it's there) but avoiding the conflicts with gnome 1.4 (and without removing Gnome 1.4)
Asking the user to require 1.1Gbs of build space seems rather excessive! Even the "206Mbs once installed" seems large
Ahh... I will remember this argument. Thanks
+1 Insightful to parent?
Your arguments are well represented and correct. Innovation is the most important point about the patent system. However, I would say the the patent system in its current form is far more harmful to software innovation than beneficial.
I respect your opinion but my opinion is that software is much more like music than engineering when it comes to generating ideas and implementing ideas. Or maybe it is just because the patent system sucks. For example, you bring patented engines as an example. Sometimes I feel that the software world is bringing the equivalent of patenting any and all types of engines as opposed to one type of engine. Many people have a problem with the patent system because the cover of software patents is too wide whereas most physical patents are specific enough to feel fair
Disclaimer: I haven't read the article
But here is my take on the analogy... and a pretty good analogy I think it to be.
In Music, there is copyright on pieces of music. You cannot distribute copyrighted music nor resell it without the permission of the copyright holder. I am all for this. In software, if you make a piece of software, you own the copyright and people must get your permission or a license to use the software or source code. That works well too.
Now patents are about ideas. There are no patents in music. You can't stop people from copying the idea that major scales and minor scales sound good. You can't patent the 12 bar blues but you can patent any piece that uses the 12 bar blues. To stop people from using the 12 bar blues seems ludicrous... and it is just as ludicrous as people in software engineering patenting quicksort, mathematical algorithms and compression techniques such that others can't use them for 10 years
I like the music analogy
If the subciphers are independently keyed, the overall cipher is at least as strong as the weakest subcipher
;)
In almost all cases, yes. But not if the two ciphers are a group, for example.
Key length means nothing if you can find analytical attacks.
True also but one could just as well find an analytical attack in the combined layered cipher if a "poor" choice in ciphers is chosen
Basically, if I had to choose what cipher to use, I think it is more likely that I would make a mistake in choosing a poor combination of ciphers to layer than I would someone finding an analytical attack in a cipher that has been analysed for decades.
The fact is, both layering and key-growing are both valid and are both used. I just happen to prefer one over the other
I'm sure this has been mentioned before... but what about throwing a frisbee? A good frisbee will travel exactly horizontally from source to target and us humans have no problem catching it.
I'm trying to imagine what I would do in space. I can see myself trying to anticipate the not dropping ball and messing up. I can also see myself catching a frisbee with few problems in space. Maybe our brains have learnt from experience that balls tend to drop and frisbees don't as much
I don't quite understand your question there (running through DES with unknown key... extra encryption reducing security) but I'll try to say something helpful
Ok, I'd better disclaim IANACE (crytography expert). I've studied the subject at university level so I know the defintions and have read the facts but have done no analysis myself.
Cracking DES-64 is "easy". Now which is harder to break of these two? DES-64 performed twice with two different keys or DES-128? As it turns out, both are using 128bits worth of key. I would rather use DES-128 on principle since 2^128 is a big key space and current DES breaking difficulty is in the order of brute force as far as I know.
Now what about DES-64 twice? Well, as it turns you might be safe with DES (because I think some people have found it is not a group) BUT suppose we weren't using DES but a symmetric algorithm that *is* a group. Then the hacker could just do a brute force attack on your code with a *64* bit key.
The thing is, I am just touching the surface here. In this case, I have showed that layering using the same cipher that is a group is BAD. Now you could argue, different ciphers etc. etc. but that *may* introduce weaknesses. To know, you would need to analyse it! But why bother when DES and the like have already been analysed to death so you can be fairly sure you are safe at larger key lengths
I stand corrected