Slashdot Mirror
Bill Joy's Takes on C#
f00zbll writes: "Cnet is running an article by Bill Joy on security and how it relates to C# and Microsoft at large. BJ quotes verbatim: 'C# provides the ability to write unsafe code. In unsafe code it is possible to declare and operate on pointers, to perform conversions between pointers and integral types, to take the address of variables, and so forth.'"
Sure, it'd be great (for Sun) for everybody to rewrite the world in Java, but in reality nobody can justify requiring 50% higher CPU usage in exchange for the ability to let programmers be careless.
I'm not saying Java is a bad thing at all, merely that C# isn't any worse than C, C++, perl or python. It's a shame when a press release manages to get linked from slashdot's main page, but that's all this is. Sorry Joy, but I'm not buying it.
You can use C# to write "Unsafe" code, but it's the runtime that ultimately decides whether or not to let it run. For example, if the VM that the browser creates tries to launch a C# app downloaded from the Internet, and it's "Unsafe", the CLR will refuse to run it.
Difference between C# and ActiveX in this case is that in ActiveX, everything is "Unsafe" and you either take it or leave it. In Java, of course, everything is "safe". C# can go either way.
I really hope that Microsoft simply makes it impossible to run "Unsafe" CLR code in the browser. Not even an option.
- Steve
There's been alot of controversy lately over security holes in programming languages. There is one language that has stood the test of time and proven to be the most secure language of all, with a record zero (0) reported security holes.
Here is the link if you want to learn more.
I Heart Sorting Networks
Obviously Bill Joy knows a lot more about this stuff than I do; but I think he, and many of Microsoft's critics as well as supporters, are missing a crucial piece of the puzzle.
/. posters have make comments to the effect that MS isn't capable of delivering technically. It used to be the conventional wisdom here, for example, that any MS OS was destined to crash repeatedly.
.NET and C# are technologies that predate this new ordering of MS's priorities, and that they probably won't be very secure. Passport, the most important .NET application yet written, coded by people who ought to know the technology best, has been hacked (and patched, it's only fair to point out). If MS's people don't write secure apps with .NET, are the low end VB coders the platform is designed for going to do a better job?
/., work for one of those companies.
Many of the features that have contributed to MS's insecurity were there not because MS's engineers were too dumb to think clearly about security, but because other people decided that there was an overriding business interest that the features would serve.
Specifically, these features usually tend to be part of the MS strategy of leveraging success in one sector into another. If you use office, it makes sense to choose VB as your scripting language. If you know VB, it makes sense to run IIS. That's why there's a VB interpreter inside every office app.
I think that what we've seen from MS is an official change in policy -- they're saying that business considerations now suggest that security should be the #1 priority. They're admitting that the market will punish them for security holes, and that they can't sacrifice security to establish leverage from one sector to another.
MS has always put business concerns over technical ones. For that reason, a lot of
It turned out that when MS saw Unix and Linux as a threat, and when they decided that reliability was one of the biggest advantages that Unix/Linux offered, they took reliability seriously and made enormous progress in a relatively short period of time. This suggest that Windows crashed not because MS *couldn't* make it reliable, but because it wasn't a *priority* for them to do so. As soon as they saw a change in the business climate on the edge of their radar screen, they changed their behavior.
Windows and its applications haven't been secure because MS hasn't felt it was worth making security a priority until now. There is no evidence that they couldn't cover a lot of ground very quickly in security if that's what they decided to do. And it seems as if they've decided to do just that.
I do agree that
But the problem that Sun faces is that MS has proven time and time again that they're willing to spend lots of money and go through lots of iterations to take a market. They're relentless. They usually don't get it right the first time, but they usually do get it right after four attempts or so.
I'll say something else that will probably get me modded down. After the recent flirtation between AOL and RedHat, I'm not sure that the moralistic arguments against MS hold up so well. Linux has been at the center of some pretty slimey stock swindles -- our gracious hosts, here at
Meanwhile, the Bill and Melinda Gates foundation is giving extraordinary sums of money to real nuts and bolts making the world a better place kinds of causes. Gates could literally turn out to be the most significant philanthropist in the history of the world. They're giving so much money that you can almost see a chunk of what you spend on MS going to a good cause.
All of which suggests to me that politics and the morality play that have always clouded the linux vs. windows debate should probably be put to rest.
Windows is horribly insecure -- viruses do incredible damage in the real world, especially among the least sophisticated users. That's not political, that's a fact.
But they're saying they're trying to clean up the mess. Sure, it's a big mess, and sure it's going to be a big job to clean it up. I give them credit for admitting it, and to taking on the task.
Really??? What gives you this idea? Java + VM is relatively equivalent to C# + CLR (as mentioned in my article that appeared on Slashdot a while ago). Code can be downloaded from the Internet and run just like with Java applets or RMI applications but this is far from the primary design of the platform .
Of all the people in the world I'd expect to criticize a technology without adequately reading up on it first, Bill Joy would have beemn one of the last I'd expect to do such a thing.
Bill Joy (and your post) go on and on about the vulnerability of network programming then ends with the reference to unsafe code which aims at giving the impression that downloaded
> Like a cast in Java, declaring code as "unsafe" is
> equivalent to saying to the VM, "Hey, I know what
> I'm doing."
This is wrong. A Java downcast is dynamically checked and cannot compromise the integrity of the virtual machine. It is not "unsafe" in any meaningful sense of the word.
First off, I'm primarily a hardware engineer, who writes small programs in C or assembly that deal directly with hardware. So I use pointers and other "unsafe" code a lot; they are both extremely useful and extremely frustrating when it comes to debug time.
.exe or dozens of script-containing formats, it would let it run. Surely virus writers wouldn't be _dishonest_ and change the HTML tag so their .exe's would slip through...
Pointers let you use just about any arbitrary number as an address and poke data in there. The virtual memory system might block this on the grounds that you don't have a page at that address -- but not all computers have the hardware to do that, you can still do horrible things by writing to the wrong place in the pages you do own, and if the protection does block the misplaced write, the resulting invalid page error is not pretty from the user's point of view.
Pointers can be used safely -- if you program very well, like checking every address before you use it (which takes a hell of a lot of extra code), or checking the data going into the pointer calculations to ensure that no way could a wrong value come out (which assumes you didn't make any programming mistakes). And if it is a case of running downloaded code where there is a finite chance that the programmer is _maliciously_ misusing pointers, there is no way for the computer to analyze the code and detect this before you run it. Hence Microsoft's attempt to make internet and e-mail user friendly by automatically running any included executables spawned a plague of viruses, worms, and trojans...
C++ gives you the choice of traditional pointers or references. A "reference" is a sort of super-pointer that includes data on where valid targets must be, and gets checked for validity every time you use it. I don't do Java, but I am under the impression that it uses references only. That isn't enough in itself to prevent writing Java viruses, but it gives the OS a fighting chance of confining them to the sandbox...
OTOH, no computer is going to run entirely on "safe" code. At some level, the code has to read and write hardware registers. To do that, you take the numeric address of the register, and use that as a pointer. True, a good, secure OS would confine all such activities to drivers, which can only be installed by the administrator, who ought to know the difference between a driver and a trojan. But Microsoft doesn't write OS's like that -- NT/2000/XP is rather improved on DOS where direct writes to the video card were almost mandatory, but the security is still swiss cheese.
Incidentally, the original reason for C allowing all sorts of unsafe activities (pointers everywhere, strcpy with no length check, etc.) was performance. Checking the length of a string every time it was used took CPU cycles and RAM to hold the extra machine code. So the creators of C left it up to the programmer to shove in an if statement to check the length when the string was input, and to do the math and pop in another if statement anywhere it was possible for the string to grow too long. This was efficient, but puts quite a load on the programmer. About that time, I was running an 8 bit computer with 16K of RAM, clock speed under 1M, and all the accounting, class schedules, grade reports, etc. for a small college went through it. Efficiency was important! Now, who's going to notice whether the program runs in 1 millisecond or 2? It's better to be reliable. And it's necessary to get the program up and running pretty fast -- that's a lot easier if you don't have to worry about pointers going wild except when you do go to the hardware.
In C# apparently the programmer has the choice of using references and avoiding all "unsafe" code, or of declaring a module "unsafe" and programming any way that gets the job done. By making "unsafe" a PITA, they've encouraged programmers to avoid it except when absolutely necessary. I have a suspicion that once the coders get used to it, that will increase their productivity overall. In addition, it gives any tool that may run code from outside a quick way of determining whether the code was written to be safe or not. In theory...
I have serious doubts about whether that (being able to run "safe" C-sharp programs) will actually work. First off, won't a virus-writer be able to hack the tags that say "unsafe"? Second, ways to do unsafe things in "safe" code will be discovered. Third, if your OS has security like swiss cheese, no program is going to really be safe. Do e-mail viruses actually have to do anything that isn't allowed?
From what I've heard, Microsoft's idea of securing Outlook was to have it look at the HTML tag, and if it said executable pop up a warning which is incomprehensible to the people who are actually ignorant enough to get e-mail viruses. ('Yeah, it's from a trusted source. See the "From" line...') But if the HTML said "text", then it passed the attachment on to the Windows "open" command, which determines the type of the attachment by looking at the attachment, and if it was
Until that sort of thinking changes, giving people a way of tagging the programs "safe" or "unsafe" is just asking for trouble.
Building a system with the sandbox design in minds is easier than taking an existing system and putting it in a sandbox. Active X is already out there. How do you handle the existing Active X and put that in a box? You'd basically have to redesign active X. Word, Excell and Access all rely heavily on VB macros. How do you put them in a sandbox? Actually that may be easier to do but it would also be limiting. In the sandbox that Javascript runs in you are not supposed to be able to access files on the users filesystem. (note not supposed to there have been errors on that though). The idea was there though.
Okay so you operate it in a GUEST account. If that guest is set up or can access files there goes security.
The reality is that 28 days is not enought time to focus on security and Microsoft does not have a good track record when it comes to security. While it may be possible to start building in security into the existing system. Security is a continuous effort that must be thought of as part of the design. When a programmer creates a new language they must start to think security right off the bat. This was done with Java, but not C#.
I say good luck Microsoft, but you have a lot of work ahead of you to prove to me that you can get security right without comprimising usability.
Only 'flamers' flame!
Furthermore, C# isn't even going after the same market as Java. Java's security model primarily comes into play for applets and mobile code, but that's only a tiny fraction of all applications. C#'s purpose in life is to allow programmers to create desktop and server applications more easily. For that purpose, an easy and robust interface to native code (regular expression libraries, XML parsers, etc.) is much more important than security.
The major problem with C# isn't technical, the major problem is that there aren't any good implementations available yet (no, Microsoft's implementation isn't all that great yet) and that C# comes from Microsoft. But once there are C# implementations that are competitive with Java implementations and once C# has a life outside Microsoft, C# will be a serious threat to Java. And we may see a truly open source, efficient implementation of C# before we see one for Java.
For the time being, I still think Java is the more logical choice for open source applications. It may yet be a few years before competitive C# implementations and libraries come along. Sun still can keep their lead by innovating and extending the Java platform, cooperating with the open source community, and being honest about the strengths and limitations of the Java platform. But if Sun continues along their current course, they will lose sooner or later.