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.'"

Comments

So what?

[mosch]

Since when does the ability to use pointers mean that something is wrong? C allows a lot of 'unsafe' code to be written, yet we're all using operating systems writting in C, with very little trouble caused by the OS itself.

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.

Trustworthy Code

[SteveX]

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

Sun shouldn't be complacent

[astrashe]

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.

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 /. 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.

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 .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?

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 /., work for one of those companies.

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.

Where do you get your facts?

[Carnage4Life]

I think the difference is that .NET and C# are designed as a network-based platform; e.g., you grab code off of the 'net as you need it, rather than storing everything locally.

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 .NET code can be unsafe. However this is incorrect, and I quote

From a technical viewpoint, the term unsafe refers to whether the program is known to be safe. Before a program is converted from intermediate language (IL) to native code, there's a part of the runtime security system known as the verifier that looks at the IL to determine whether it's safe to execute. In this context, safe means that the verifier can prove that the IL doesn't do anything unsavory.

IL safety is important for certain Microsoft .NET scenarios--it's nice to know that the chunk of code that you downloaded from a Web site isn't going to do anything bad to your machine. The default policy for remote code (either from a Web site or from a net share) is that the code must be verified safe to execute.

In other situations, it's useful to write code that can't be verified to be safe. In C#, any use of pointers generates unsafe code, as does any use of interop, such as COM interop or platform invoke.

Since you don't want to write such code inadvertently, C# requires you to use the unsafe keyword on your class or method whenever you write code that deals with pointers. When you use the unsafe keyword, the resulting IL is marked as unsafe and can only run in a fully trusted environment (usually, security policy only trusts local assemblies). In the current version of the runtime, unsafe is defined at an assembly level, so having any unsafe code in assembly makes the entire assembly unsafe.