Pete,
Your on-going vehement opposition to NT was bound to lead you to this
point. ActiveX objects can be denied, they do not "suddenly activate when I
hit a web page". You don't have to involve yourself in any key exchange if
you don't want to, you can simply say you don't want any ActiveX objects
downloaded to your machine. I seriously doubt that any implementation of
ActiveX object usage within any application is going to ignore that
premise.
If you'd bother to read any of the reference material contained on the
codesign site I mentioned in my message, you would have discovered that
part of code signing is verifying that the source is unaltered from the
authentication servers understanding of it, using a hash to supply the
verification. Exploiting a hole in an object is still possible, but not by
altering it. This is specifically intended to prevent the alteration of
objects by viruses.
"ActiveX can sneak in in a web page with you all unawares."
"But I have to take a deliberate action to install shrinkwrap software, it
won't suddenly activate when I hit a web page."
Both statements are blatant lies and complete misinformation, and obviously
based on no knowledge whatsoever. What you are saying is that you
definitely know of a way of by-passing key authentication, or, of usurping
the browsers ability to adhere to an instruction to dis-allow ActiveX
objects completely. State, with specificity, exactly how to do this or
admit it was a stupid statement. With ActiveX objects disabled in the
browser, you end up with HTML-only.
"But you *can* build a complete and secure sandbox. You just have to
restrict it to known safe actions. This means you can't do certain sexy
things, but you can do useful stuff regardless."
Brilliant thought process here, and we could extend it to say that we would
have no risks from the Internet if we simply disconnect ourselves from the
Internet. Please, publish this widely, there are quite a few people who
have been working real hard on stuff that you obviously believe is
completely useless. We should let them know there is no point. The rest of
your remarks, regarding the viability of other options, are truly amazing,
wonder why nobody has bothered to do much with them???
You obviously missed my main point. Namely, Java attempts to dictate the
environment which your applet can work in, and thereby constrains you to
their security model. The rules by which an applet can function dictate how
the security is implemented. Great, if we can find that one VM that
everyone can do everything they want to in, we'll have it
made...eventually.
ActiveX is forcing the development community to come up with security
solutions that will handle as many different environments as they chose to.
So, we can have industrial strength solutions or light-weight personal
solutions, depending on the user's needs or the MIS department's
forethought (or paranoia...;-])
I've never once been able to buy a piece of clothing marked "one size fits
all" which fit me properly.
Cheers,
Russ
Follow-Ups:
|
|
