If they want to use thoroughly untrustworthy software, that's their problem. There's already thusly untrustworthy software available for Linux. I was trying to point out that at least most of the software available now is software libre, and is therefore far less likely to contain spyware.
Also, ActiveX runs code with caller privileges. Any correctly designed system (such as Java Applets) would never do something so profoundly idiotic.
It's not so much the fraud possibility that concerns me, since I think it's at least reasonable to assume that most companies won't go out of their way to break the law so obviously.
I take it you haven't been following the Enron scandal?
I should mention that gcc does also have a -pedantic option and other such things, so if you have a need to write code that is certain to be portable, you can use that.
As for gcc being the Linux C++ compiler, if there were any real alternatives, then I'm sure people would use them. As it stands now, however, gcc is the only compiler that meets all of the demands of the community (such as being Free Software and being portable). Gcc is the Linux C++ compiler because it is the only such compiler that is acceptable.
As for C99 providing for fixed-size integers, well, I didn't know that. Does it provide a 64-bit integer? Arbitrary length integer? (I'm thinking bignum here.) That'd be kinda cool...
If your user base can't run Java programs, they are the one-percenters. Anybody with a Windows box can run Java programs (though you might need to distribute the JRE on the CD-ROM or with the download if they don't already have it). The only downside to writing applications in Java is that the GUI system (AWT and Swing) can be a bit sluggish, but it still works quite nicely. I don't think I would ever even think about writing a graphical front-end to anything in a language other than Java.
Another important benefit is Java's portability. Rather than targeting 90% of the market, why not target 99% of it? And spend about a quarter of the time making the application, to boot?
Of course, writing spyware in Java is kind of hard...
You forgot to consider the Free Software effect on spyware. Spyware in Free Software tends to be discovered much more quickly than spyware in proprietary software, and the mindset of the developers of Free Software does not generally involve defrauding people. (See this post for more on that.)
Re:And to get vx2 to disassociate your personal da
on
Spyware in Audio Galaxy
·
· Score: 2, Interesting
I, too, find it extremely difficult to believe that they'll just throw away all of the data they've collected on you just for asking. The amount of money that could be made with this kind of information is huge -- especially bank account numbers, which can be used to defraud a lot of people of a lot of money (and then the VX2 people would move to Switzerland or some such place and retire). Selling all that email information to spammers could also be quite profitable. Oh, and they'd have gotten credit cards, too, so they can also commit credit card fraud, writ large.
Spyware (and other trojan-type activities, such as the backdoor in Borland Interbase) are often discovered quickly in Open Source software. If memory serves me correctly, the backdoor in Interbase was discovered almost immediately after the source was released. Don't you think that suggests something?
Of course you can have spyware on Linux systems. That's not the point. The point is that Linux systems are generally based on Free Software, which is much less likely to contain spyware. See this post for a more detailed explanation of this.
By the way, there is no ActiveX on Linux. It is, therefore, a hell of a lot harder to rm -rf $HOME than you seem to think. Actually, I don't think there are any means of executing untrusted code with caller privileges, short of downloading the binary, chmod +x'ing it, and running it manually. Most people won't do that just because someone asks nicely...
A good example of a similar tradeoff is in the difference between, say, Java and C. Modularity, portability, and so forth are exchanged in exchange for some (rather small) amount of performance.
GCC is Free Software. Microsoft Internet Explorer is anything but. If Internet Explorer were Free Software, standards wouldn't matter because whatever Internet Explorer does would become a de facto standard (and would probably wind up getting standardized in a future version of the W3C specification -- not something Microsoft is about to allow happen).
GCC is standards compliant, but it does have some of its own extensions, such as a 'long long' data type in C that's like 'long' but is 64 bits instead of 32.
I was going to say that if you did that you'd go to jail because Big Business (tm) would use its hired Congressdrones to make competition a capital offense, but then again, Linus Torvalds and company are still alive and still kicking Microsoft's ass, so I guess you're right.
I know this has already been done, but I thought I'd throw in my understanding of what would have to happen:
The process' core would need to be dumped. This should be fairly straightforward, since some of them do this a lot already...;)
The process' registers (main CPU registers, FP registers, and any other registers that might exist on whatever exotic arch you use) would need to be saved. This is already done by the kernel for context switching to other processes. Gdb also can fetch and change these, so it can be done from userland.
Last but not least, all of the kernel level state of the process would need to be saved. That involves saving:
The signal handler table.
The pending signals. (Since the process hasn't handled its pending signals yet, it needs to handle them at some point in the future.)
The state of whatever syscall, if any, the process was in at the time of freezing. (Or you can set errno = EINTR on most syscalls, if this isn't possible.) This would be rather interesting to implement -- what if you're using a different kernel when you thaw? You can't just save the pc of the syscall then...
The file descriptor table. This includes network sockets, which would probably have to be closed (set errno = EPIPE and send SIGPIPE on next read from a thusly closed socket?), for obvious reasons.
The System V IPC state. This means message queues, shared memory, and semaphores, all of which would have to somehow be recreated.
Any child processes, most likely.
More interestingly, any threads, which might be hard to tell apart from ordinary processes since they are ordinary processes with some exceptions.
Everything else...
As you can see, freezing and thawing UNIX processes could get quite nightmarish if you account for all of the possibilities. (Most processes don't use SysV IPC, for instance.) Even the most (seemingly) trivial of syscalls would need to be modified (all socket functions, for instance).
Note that it's a lot easier to freeze and thaw a virtual machine, because it's so much more self-contained -- all you need to save then is:
Core.
Registers.
The state of any simulated hardware devices (virtual screen, for instance).
Most attacks I've had the displeasure of experiencing were carried on either UDP or ICMP packets. Most public services run on TCP. Therefore, blocking all UDP or ICMP packets for a time is sufficient.
There's always a first for everything. Maybe this is just the first healthy, competent ISP to be put out of business by DoS attacks. I guess we'll know for sure if more follow.
In my opinion, the Slashdot effect walks the fine line between a large number of requests for service and denial of service. The two are often confused.
One could say that DeCSS et al are depriving a business (or, in this case, several businesses -- collectively, the movie industry) of the resources it requires to survive (namely, the massive dollars it's stealing from people). It doesn't meet the specification of malicious, though.
Actually, it's enough to simply have a human provide the instructions as to what is hostile and what isn't. Something like this:
31337 H4X0R D00D launches DoS attack.
People start calling tech support complaining.
Tech support tells admin to investigate.
Admin notices that something or another is getting packeted.
Admin gets pissed off.
Admin informs computer about which packets are being used in a DoS attack.
Computer transmits request to upstream router to filter all such packets.
DoS attack ceases. Legitimate packets begin to flow in and out as normal. Normal service is restored.
People stop calling tech support.
Admin calms down.
31337 H4X0R D00D wonders why./hack isn't working anymore.
Obviously, some Quality of Service support will be needed to insure that the request from the computer to the upstream router gets through despite all the packeting.
Better a denial of service attack than all of your customers' credit card numbers getting posted on USENET. Oh, and that's what firewalls, IDSes, and sysadmins are for. Denial of service attacks are easy to notice, easy to block, and easy to perpetrate.
Regardless, that code was intended to run in its own thread. If you don't have such a configuration, you'd better use timeouts or async I/O or something. Otherwise you will be only able to service one client at a time... Java 1.4 (currently in beta) adds many new facilities for asynchronous I/O and a select() type thing.
The solution to this problem is quite simple, really -- write it all in Java instead. That way, if there's a buffer overflow, it's your JVM vendor's fault.;)
You can't make a buffer overflow in Java. Trying to overflow an array will simply throw an ArrayIndexOutOfBoundsException. In most other cases, memory is allocated as needed. It's perfectly safe, for instance, to read a line of text (as in many plain-text protocols, like HTTP, IRC, etc):
Socket socket;//... initialized elsewhere
BufferedReader reader = new BufferedReader(new InputStreamReader(socket.getInputStream()));
for (String s = reader.readLine(); s != null; s = reader.readLine())
System.out.println("Read from socket: " + s);
System.out.println("Socket closed!");
That code fragment reads everything that's received on a network socket, one line at a time, until the socket is closed. Note the absence of any opportunity for creating any buffer overflows...
Slashdot Mirror
Also, ActiveX runs code with caller privileges. Any correctly designed system (such as Java Applets) would never do something so profoundly idiotic.
As for gcc being the Linux C++ compiler, if there were any real alternatives, then I'm sure people would use them. As it stands now, however, gcc is the only compiler that meets all of the demands of the community (such as being Free Software and being portable). Gcc is the Linux C++ compiler because it is the only such compiler that is acceptable.
As for C99 providing for fixed-size integers, well, I didn't know that. Does it provide a 64-bit integer? Arbitrary length integer? (I'm thinking bignum here.) That'd be kinda cool...
Another important benefit is Java's portability. Rather than targeting 90% of the market, why not target 99% of it? And spend about a quarter of the time making the application, to boot?
Of course, writing spyware in Java is kind of hard...
That's not the worst of it. Check this post for more details on what kind of illegal stuff these guys have been doing. Disquieting...
You forgot to consider the Free Software effect on spyware. Spyware in Free Software tends to be discovered much more quickly than spyware in proprietary software, and the mindset of the developers of Free Software does not generally involve defrauding people. (See this post for more on that.)
*Whistle* Pretty bad...
Spyware (and other trojan-type activities, such as the backdoor in Borland Interbase) are often discovered quickly in Open Source software. If memory serves me correctly, the backdoor in Interbase was discovered almost immediately after the source was released. Don't you think that suggests something?
By the way, there is no ActiveX on Linux. It is, therefore, a hell of a lot harder to rm -rf $HOME than you seem to think. Actually, I don't think there are any means of executing untrusted code with caller privileges, short of downloading the binary, chmod +x'ing it, and running it manually. Most people won't do that just because someone asks nicely...
They generally are.
By the way, regarding your sig, isn't BIND completely free?
A good example of a similar tradeoff is in the difference between, say, Java and C. Modularity, portability, and so forth are exchanged in exchange for some (rather small) amount of performance.
Maybe parent was referring to everything with a decent CPU? ;)
Probably why they don't release it thusly.
I was going to say that if you did that you'd go to jail because Big Business (tm) would use its hired Congressdrones to make competition a capital offense, but then again, Linus Torvalds and company are still alive and still kicking Microsoft's ass, so I guess you're right.
As you can see, freezing and thawing UNIX processes could get quite nightmarish if you account for all of the possibilities. (Most processes don't use SysV IPC, for instance.) Even the most (seemingly) trivial of syscalls would need to be modified (all socket functions, for instance).
Note that it's a lot easier to freeze and thaw a virtual machine, because it's so much more self-contained -- all you need to save then is:
Most attacks I've had the displeasure of experiencing were carried on either UDP or ICMP packets. Most public services run on TCP. Therefore, blocking all UDP or ICMP packets for a time is sufficient.
- It's an attack.
- It disrupts or destroys business or lives.
- It makes people feel miserable and afraid.
What are your criteria?There's always a first for everything. Maybe this is just the first healthy, competent ISP to be put out of business by DoS attacks. I guess we'll know for sure if more follow.
In my opinion, the Slashdot effect walks the fine line between a large number of requests for service and denial of service. The two are often confused.
One could say that DeCSS et al are depriving a business (or, in this case, several businesses -- collectively, the movie industry) of the resources it requires to survive (namely, the massive dollars it's stealing from people). It doesn't meet the specification of malicious, though.
- 31337 H4X0R D00D launches DoS attack.
- People start calling tech support complaining.
- Tech support tells admin to investigate.
- Admin notices that something or another is getting packeted.
- Admin gets pissed off.
- Admin informs computer about which packets are being used in a DoS attack.
- Computer transmits request to upstream router to filter all such packets.
- DoS attack ceases. Legitimate packets begin to flow in and out as normal. Normal service is restored.
- People stop calling tech support.
- Admin calms down.
- 31337 H4X0R D00D wonders why
./hack isn't working anymore.
Obviously, some Quality of Service support will be needed to insure that the request from the computer to the upstream router gets through despite all the packeting.And having the cartridge throw up the logo by copying some assembly code or the like from another cartridge does?
Regardless, that code was intended to run in its own thread. If you don't have such a configuration, you'd better use timeouts or async I/O or something. Otherwise you will be only able to service one client at a time... Java 1.4 (currently in beta) adds many new facilities for asynchronous I/O and a select() type thing.
You can't make a buffer overflow in Java. Trying to overflow an array will simply throw an ArrayIndexOutOfBoundsException. In most other cases, memory is allocated as needed. It's perfectly safe, for instance, to read a line of text (as in many plain-text protocols, like HTTP, IRC, etc):
That code fragment reads everything that's received on a network socket, one line at a time, until the socket is closed. Note the absence of any opportunity for creating any buffer overflows...