[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PM's Netscape rant
On Mon, 25 Sep 1995, Vladimir Z. Nuri wrote:
> I thoroughly enjoyed PM's vituperative, venemous, and vitriolic
> Netscape rant. it just wouldn't be the cypherpunks list without
> the pit bull of the internet nipping at everyone's heels here
> and slaying any unwarranted peace!! however I haven't seen any
> well-deserved rebuttals however, so..
>
> I'm again going to be a netscape apologist and say, GEEZ, PM,
> will you take it easy, and untangle your underwear knots?
>
> as has been pointed out numerous times, the encryption in the Netscape
> code is designed to handle credit c
rd number transport, *not*
> actual cash transport. its really silly to have more security
> present than is available than the weakest link. it would be like
> worrying about a fence around the white house when one is giving
> open tours to the public every day!!
Uh, there is a fence around the White House and they do give daily tours.
I might add that there are a good number of people who worry about it
every day.
I might also add that it is even more silly to design a software package,
where additional security might easily be added, which has too little
security to be expanded into other roles. This is called 'designed
obsolesence.' Wells Fargo bank is allowing account transactions over
their webpage, one assumes this does, or will soon include "cash transfers."
>
> PM is rather secretive about the systems he is working on, but
> I suspect they are stock systems that must be highly secure because
> they actually involve *transfer* of cash, and *large*amounts* of it,
> in a *time-critical* environment, with *large corporate clients*. these
> are all inappropriate criteria to judge Netscape by.
I believe this is a demonstration of your lack of vision, "vznuri."
Netscape's potential in the next 8-12 months alone dictates that they
should be concentrating on attracting corporate clients, as does their
new obligation to stockholders who have yet to see a penny of profit not
related to speculation and stock price fluxuation.
in the Netscape
> scenario, the software is *not* transfering cash itself, *not* transferring
> large amounts of it, and *not* in a time critical application, and *not*
> geared toward large corporations, but instead individual users.
> it is relying on another infrastructure (credit cards) for the actual
> transaction mechanisms.
For now, perhaps. It seem you would have that limitation written in stone.
>
> as has been pointed out numerous times, the whole
> credit card apparatus is somewhat based on "security through obscurity",
> i.e. the obscurity of a credit card number, and it doesn't make a whole
> lot of sense to try to make this more "secure".
I'm not quite sure you mean this, but if you do, you're just small minded.
Why don't you read it again.
this is a problem for
> credit card companies to fix (I agree it is a horrible problem, that costs
> us billions, and should have been fixed a long time ago) .. but holding
> credit card *using* companies responsible for this deficiency
> doesn't make sense. they are not the enemy!! they would surely seize the
> most secure mechanism available, if there were alternatives.
There are, they haven't.
> the distinction is subtle, but I think a relevant one:
Then it's unfortunate that you have missed it so completely.
> is
> the software itself transfering cash, or building on another system
> that does so? hopefully in the latter case, the requirements for a
> successful implementation are not so difficult to achieve (so that
> even fresh-out-of-college CS students can call the functions to
> do so, and perhaps code packages are written such that the user
> is protected from their own naivete, or what PM would call stupidity
> or incompetence).
Looking at Netscape, and moreover, the entire set of browsing programs,
you speak like a petty government offical. By limiting the scope of
potential of various browsers you do nothing to further the cause of easy
to reach strong crypto for everyone in a transparent and widely
distributed package. Instead you believe we should forgive Netscape it's
oversights (and carelessness) because it was never meant to transfer
funds over the internet. "It's a petty program, you should ignore it" is
what you're really saying, which completely misses the fact, that
millions of people are using/going to use it, and they are as likely to
use it for banking as for shopping at home as for 'surfing.'
Then again, perhaps your intent was never to make strong encryption
available to the masses.
> --
>
> PM gives some excellent techniques for improving code security (some
> of these may not be exactly what he proposed):
>
> 1. hiring experts
> 2. code reviews
> 3. restrictions of who can work on what code (security clearance)
> 4. heavy testing
> 5. antagonistic attacks (i.e. hiring someone trying to crack the code that
> others have written)
> 6. open review of key code
>
> however, put all these things together and you get a company apparatus
> a bit more like the NSA than a commercial company. I agree that all
> these precaution are relevant for banking and stock transaction software
> transferring millions of dollars. but holding a joe-schmoe GUI and
> Web company responsible for this kind of paranoid oversight is really
> impossible and unrealistic and *unnecessary*.
>
> there will be some companies that specialize in creating the
> *secure*infrastructure* for communications transactions. other companies
> will just *latch on* to this existing infrastructure. hopefully the
> requirements for *latching on* will not be too difficult, otherwise we
> are all in trouble!!
>
> now, admittedly, it would be ideal if the netscape code was highly
> secure, but again, I just don't think it is in the best interests of
> this company to become security paranoid to the degrees that I have
> listed above, and the extreme degrees that people here are ranting about.
> rather they should try to blend in with other companies
> who specialize in cryptographic security. the latter companies should
> as much as possible provide foolproof modules. they should take care
> of all functions that have a potential for problem, such as random
> number generation, key exchange, etc. they should try to provide
> a minimum of training where the code is not foolproof.
>
> many have been making the point that one cannot judge the security of
> a package based simply on analyzing key modules. I actually don't think this
> has been proven in general and completely resolved yet. I can imagine
> modules that communication with software such that the module
> itself is a "secure environment" in general, and
> it is almost impossible to misuse the software itself. (for example,
> the software might never store the actual keys of transactions itself,
> this being handled by a secure module, making it impossible to
> accidentally reveal them).
>
> some day we might actually see "secure module support" built into a
> microprocessor. in many ways the microprocessors that guard against
> illegal memory accesses and illegal function calls are in a sense
> providing a kind of cryptographic security. and people who study
> secure OSes generally eventually conclude that for ultimate security,
> you almost have to work from the ground up, starting with memory,
> microprocessors, and network hardware.
>
> --
>
> so my general point is that PM's rant, while lots of fun to read..
>
> >you @#$%^&* whippersnappers!! you don't have a @#$%^&* clue about
> >REAL code!! us old timers were writing code as secure and impenetrable
> >as granite bricks, impregnable as a frigid victorian gandmother,
> >before you were a twinkle in your mama's eye!! learn some
> >sufficent grovelling skills for your superiors or you will
> >not only be fired from your JOB but be excommunicated from the
> >entire INDUSTRY, perhaps even tarred, feathered, drawn, quartered, and
> >hung from your neck in the nearest tree!!! your employer will throw
> >you to the wolves, your customers will spit on your flayed carcass,
> >your family will look upon your shrivelled remains with shame, the
> >vultures will vomit your undigestable eviscerated entrails,
> >and the world immediately explode, if you have a
> >SINGLE BUFFER OVERFLOW *anywhere* in your code!!
>
> (ahem) this is not appropriate in the context of Netscape's aims, unless they
> want to become financial transaction experts more in line with banking
> expertise. netscape is more a "bring cyberspace to the masses" company,
> not "bring secure transactions to cyberspace". it's just because so
> few companies are successfully doing the latter, that netscape is forced
> to implement some "key" aspects of it to support the former. but I suspect
> they may ease out of the cryptographic security business in the long run,
> delegating it to other companies' plug-in-packages.
>
> furthermore, cyberspace is growing gradually. the way we get to really
> incredible secure transactions is through a growing process, an evolution
> in which mistakes are made at different levels, and which in the beginning
> the software is not much more than a toy that looks pretty and has the
> fewest moving parts and most simplistic design imaginable.
>
> I fully believe that some day a company in cyberspace will exist
> that satisfies PM's and all other cypherpunk's most erotic dreams
> about secure transactions. however that day is years away and it
> will take a long time to reach it. and I doubt that it will be the
> same company that is playing around with GUI's for the end user and
> hiring college programming hot-shots and Java geeks. IMHO netscape
> is probably not going to be the company that will try to bring the
> *lowlevel infrastructure* for cash, judging by the current winds,
> although that could change. they will definitely help guide its
> progress and be interacting with the companies that do, however.
>
> when the big Secure Transactions Inc. company is invented for
> cyberspace, *then* the kinds of absolutely uncompromising standards that PM
> embodies will be in place. but again, we cannot expect the companies
> of today to embody that ideology and atmosphere for a few years yet.
>
> the cypherpunks play a very valuable role in finding these "growing
> pain" mistakes of beginning companies such as Netscape,
> but we are not really serving our own best interests or the
> harmonious growth of cyberspace by vilifying/ embarrassing/
> browbeating/ humiliating companies or their employees over their security
> problems, at least if they are clearly responsive to far less ammunition.
> keep in mind that NSA unbreakable security is *just*not*appropriate* in
> every situation, and in fact "weak" encryption does have legitimate
> uses (i.e. in a world where people routinely lock their keys in their
> cars). (although I agree, in general one should always try to design a
> system to be as secure as possible.)
>
> (oops, I used the term "we" in that paragraph, a grave cypherpunk sin..
> my humble apologies; @#$%^&* cryptoanarchist vocabulary)
>
> that all said, nevertheless, I do enjoy PM's periodic displays of
> undigestable bile eruptions at least as much as one of the other
> infamous amusing crackpots circulating in this corner of cyberspace..
> (but geez, PM, were you raised by a pack of wild wolves or what?)
>
> p.s. to TCM: why do you continually find my login name abbreviation so
> fascinating??? my apologies to anyone if I am missing some kind of
> inside joke here, I'm a little dense at times <g>
>
>
---
"In fact, had Bancroft not existed, potestas scientiae in usu est
Franklin might have had to invent him." in nihilum nil posse reverti
00B9289C28DC0E55 E16D5378B81E1C96 - Finger for Current Key Information