JFK: NG troops have M-16s (or AR-15s) on their backs--they may as well be unarmed or wearing bullseyes. Two NGs at each entrance. My guess is safety off or round not chambered.
Most of the NG troops don't even have a clip in the rifle. You don't exactly want your weekend warrior types shooting off rounds accidentaly.
The guards carrying guns at European airports are typically elite units that specialise in armed security.
This is bullshit, as the C# bytecode virtual machine is not by any stretch of the imagination language agnostic
As I stated in the post the difference between the C familly languages is likely to be least. In particular I don't expect there to be a speed penalty for J#.
I also stated that functional languages are likely to be somewhat disadvantaged. I suspect that overall however the differences between languages will be somewhat reduced compared to traditional contests where the quality of implementation is the dominant variable being measured.
Not that it's different than with any other topic, it just happens that I'm a Compiler Expert (TM).
Pity you don't appear to be an English comprehension expert.
Proof? Of course, there cannot be one, but if you like benchmarks, compare the Great Computer Language Shootout [bagley.org]. Though C "wins", I wouldn't exactly call it "much slower".
One of the fun things.NET does is to finaly make a fair comparison of programming languages possible. In the past the problem has been that most competitions of that type tended to be won by FORTRAN, not because the language was any good or fast but just because of the humongous amount of work that has gone into optimizing FORTRAN compilers.
C compilers have recently overtaken FORTRAN for the same reason, the effort put into optimization, plus C is quite a bit friendlier to the optimiser than FORTRAN.
With.NET you can use the same back end to produce code for practicaly any mainstream language and plenty of far from mainstream ones. It is very unlikely that there will be major performance differences between Basic, C#, and J#.It will be interesting to see how much the gap between C and Perl is narrowed.
Some of the traditional gap between the C languages and functional languages will be narrowed because CLI is a managed code environment. I suspect there is still some performance penalty to using functional languages in a functional maner but it will probably be irrelevant since you only need to use thefunctional code for the parts where functional languages help.
Case in point here is I remember once writing a prolog program to do soe stuff. Prolog was great for the real problem but when it came to all the support code to do the UI and I/O it really started to creak. Not only was the code slow, it was also really hard to write and was full of kludges (anyone remember the cut?).
Windows NT is not based on VMS. It is in essence OS/2 version 3.0. MS did all sorts of things to OS/2 that the IBM engineers were disgusted by so MS took their bat and ball and went to play in their backyard. The only relation that NT has with VMS is the one guy.
Twaddle. IBM screwed up OS/2 by insisting that it support the PC AT with the derranged 286 memory scheme.
Microsoft hired much more of the VMS team than Dave Cutler. Even if they did just hire 'one guy' it was the guy in charge.
The first release WNT internals were so close to those of VMS that VMS system programers such as myself pretty much knew most of the O/S when it was released. That would be quite a coincidence if it was OS/2 underneath.
And 30 years ago the bleeding-edge filesystems (non-UNIX) did have metadata and resource forks and other whizbang ideas. Guess what? They sucked.
That was the opinion of Ken Thomson and co. However I don't believe that the view was widely held by people who had extensive experience of using the systems you cite.
The real problem was that making use of the features required you to write bespoke code to the O/S. That and the fact that on the class of hardware Thomson and Co had available there was no real performance penalty for performing complex file management at the process level. Modern network attached storage architectutres essentially recapitulate the older data concentrators which were designed to take load of the processor and storage/processor communications bandwidth.
The arguments about pipes and such are just UNIX ideology. Serializing a data structure is easy if you have metadata.
Of course you might be right in thinking that the last word in computer architecture was made in the 1970s. Personally I disagree with you, UNIX is a crock and as I pointed out to Denis Ritchie I am one of the few people who can say they worked on a system that was more successful and has more users.
How long do./ readers think it will be until the Linux kernel and/or Samba will be able to read OFS shares?
The question is 'at what level'. I would guess that OFS will continue to export the traditional file system interfaces and emulating the file system interface would be relatively straightforward.
Accessing the object level methods is going to be very hard. UNIX does not support analagous data abstractions. To UNIX everything is a file is a stream of binary data. To OFS everything is an object that is indexed six ways from sunday.
For the record, I'm no DB Admin, but, as I understand it, relational is the choice of DB for almost all projects for its sheer speed, OO is only good for academic reasons to show off organization...
It is quite a while since I last wrote a database. However if you want speed you don't want the overhead of relational. ISAM is much faster.
Traditional measures of speed are going to become progressively less relevant as RAM prices continue to drop. The bulk of the Oracle architecture is concerned with optimizing the path of R/W heads over disk platters. A lot of the constraints of the SQL model are due to trying to lay out data structure on disk.
Massive simplification is possible if you start from the position that the data structure will be in-memory and the only thing written out to disk will be the transaction log.
I think you are right, at least in part. I think that the other issue to consider is the close relationship between WNT and VMS.
The last major release of VMS with a major improvement was back in about '91 when they added in the low level support for transactions in the file system. This was a truly major breakthrough. it is a pity that it came towards the end of the VMS era and as a result was never really exploited by applications.
The advantage of a transaction based file system is that you can write updates out to disk without having to worry about partial completion. You know that the write will either succeed completely or fail completely. It is not possible for the program to crash in mid write and leave the data in a corrupted state.
This would be a major advantage for application programmers. You could get ACID properties without having to mess arround changing your data structures to use SQL. You would not need to deal with the twits who think that Entity Relationships are the latest thing in comp sci rather than what they really are, an obsolete throwback from the COBOL era. You would not need UML or any of that rubbish either. And you can hand your Oracle DBA their pink slip.
All in all a win win situation, unless that is you are an Oracle DBA or hold Oracle stock.
So, according to the article, NDS spent "huge sums" cracking the codes. It seems to me, that if the codes were sound, it should have been mathematically impossible for them to crack it for any amount of money (short of an optical, or quantum computer, of course). And if they weren't, why did they need to spend so much money on it?
Actually this is not true when it comes to DRM measures. The problem here is that you are trying to keep information secret while sharing it with a few tens of millions of subscribers.
Ultimately any crypto scheme depends on the secrecy of a small number of keys. If a person reveals their key deliberately then anyone can read the information sent to them.
That said the Canal+ scheme does not have a great reputation for security. There are plenty of schemes that at least require the attackers to extract secret keys from smart cards. The satelite TV DRM problem is much easier than the DVD type problem. With a DVD player you can't issue a different key to each user and withdraw use rights on a per player basis. With satelite TV you can.
They could very well have used a non-proprietary core, as the original poster suggested.
Exchange is a 'non-proprietary core' (at least in the DMS usage).
Exchange 5.5 is an X.400 MTA. The is nothing proprietary about X.400, it is just that Microsoft is the only vendor that still sells that junk.
Exchange 2000 removes the X.400 junk from the core. It is not an OSI MTA that also does Internet, it is an Internet MTA that also does OSI.
Don't judge Exchange by the horrors of 5.5, those horrors are mostly intrinsic to the OSI junk it is based on (plus the MAPI horrors).
The problem with DMS is not that they chose prorpietary software, they simply chose the wrong open standard. Even today we have DMS folk comming to the IETF with drafts proposing some form of X.400 interop for S/MIME.
What it comes down to is that the military defined a mail system that was so complex that Microsoft was the only company arround with the resources to provide client support.
I think in hindsight, that would have been a very sensible decision, don't you?
It isn't a matter of hindsight, there are plenty of reasons why DMS and the Federal govt. PKI are problematic. Most of those were known at the start.
We (actually, the US military) have recently implimented a MS only messaging solution using Exchange and Outlook called DMS. The solution took well over 6 years to develop secure email (snicker), and still doesn't work right. Even though there is freeware that could have been implimented that we would be able to see the source code for - the PHB lemmings of the AF chose, instead, to go with a MS solution.
And what public domain software is there out there that suports S/MIME security labels as mandated by the DoD?
PGP is simply not up to the task of providing a military messaging system. In fact the principle insight that Phil Z. had was that PEM was being designed with the assumption that the rest of the world ran according to the strict hierarchical principles of the military.
What the posters on this whole story don't understand is that they have a radically different approach to security than the Air Force. In the real world you increase security by removing features. In the military you increase security by adding security features.
DMS was designed in the days before 'Commercial Off the Shelf' (COTS) became a US govt buzword. The military do genuinely have a number of requirements that are not shared by the general public, such as the ability to continue functioning after the loss of 80% or more of the infrastructure in a particular locality. But there is no reason why they need their own message formats and there is no reason why DMS can't use COTS to provide at least a core.
Re:I've written my representatives
on
SSSCA Editorials
·
· Score: 2
(I blame Vermont for this mess. If Jumpin' Jim Jeffords had stayed with the people who put him in the Senate, we wouldn't have an idiot like Hollings in a position to introduce such a crappy piece of legislation as the SSSCA.)
And the folk who gave us the DMCA would be? Oh yes thats right, Orin Hatch and the GOP.
OK so Hatch has since discovered that the RIAA lied to him repeatedly and took him for a fool, but the fact is that the GOP record on this issue is no better.
It is Ashcroft's 'justice' dept that has been out to make 'high proile arrests' to enforce DMCA.
I don't think this is a left/right issue at all. This is a donor/citizen issue. Hollings and his cronies in the Senate care more about the interests of the donors than the voters.
As for Jeffords, put the blame where it belongs. GWB began his term of office in the most divisive and partisan manner imaginable. Jeffords had run as a moderate conservative, not as an extreemist.
Answer: Mac because it is the least available operating system and as such fewer attacks have been created for it, even if there are hypothetically more bugs. As such, you would be less likely to suffer a problem, all else being equal
Let us supose that someone discovers a bug in the MAC O/S that is only relevant to online control. almost no MACs are used for online control, what is the probability your bug will ever get fixed?
The original story in this case is posted with the intention of obtaining a particular answer. The poster is not really interested in what system would be secure, he wants to have his original prejudice reinforced.
Design of ship control systems is a real time control problem. As such it is not an application for which 'Linux' is a solution, you have to be much more precise and specify exactly which real-time enhanced Linux you are considering. It would also kinda help to actually specify the problems to be addressed
As for 'security', one would hope that you would not be hooking your control systems up to the Internet or running any sort of user application other than controls for the ship. The references to worms viruses etc suggest to me that the poster does not understand the problem or is trolling for anti-Microsoft stories to tell his manager.
I see I've been moderated down to flamebait. Well, it's a free country, thank God, so fine. However, read and understand.
I have noticed that a lot of the moderators who use their mod points to punish views they don't like but know people are likely to think fair will use 'overated' to mod people down. That way they reduce the risk that they will be metamoderated as 'unfair' which they know would be likely if they used 'troll' or 'flamebait'.
I think that this is basically a pretty pointless and largely ideological argument. In the one camp we have the Microsofties who don't like the idea of competing with 'free'. In the other we have the Open Sauce zealots who hate the idea of paying for anything.
As usual with idealogues, both sides are wrong. However they find plenty of followers because lots of people are lazy and would like others to do their thinking for them. Plus they have the idea that they can gain credibility and prominence by advocating the most extreeme position out there.
What I find most significant in the Perens article is that all the quotes he gives can be found in the original reports of the Mundie speech. He gives no more context than the original reports. This strikes me as a staggering coincidence, he found the exact same quotes from a 40 minute speech significant as the previous report! Was Perens present at the speech? Did he even listen to a tape of the speech? given the state of US journalism I strongly suspect that he did not and that he is not reporting on the speech, he is reporting on the reports of the speech.
That was awfully clever...setting Microsoft on Netscape like that...wish I would've thought of it...*polite cough*
I suspect the outcome was overdetermined. Whatever anyone outside Netscape did could hardly compete with Marc's own behavior.
Marc took every opportunity he could find to trash Microsoft and claim that Netscape was going to replace them.
Meanwhile Gates was stating in the press that he was concerned that Microsoft would become complacent and lazy as Lotus, Wordperfect and co had become. Marc offered himself up as the perfect enemy at the perfect time.
But don't discount the fact that there were plenty of people outside Microsoft looking to stick a knife in Marc's back.
He was not trying to compete with microsoft when he made netscape either.
He might not have been trying to compete with Microsoft, but others thought the competition would be interesting to watch.
Netscape was from the start paranoid about Microsoft, some of them even thought that Redmond might have bugged their HQ and would take you outside to dish the dirt on MSFT. Meanwhile they had made plenty of enemies, including me.
Microsoft at the time was snoozing away oblivious about the Internet. The entire focus of their company was on the launch of Windows 95 and the original MSN which was an AOL rip off. If Marc had not been mouthing off about replacing Microsoft or Microsoft had continued to ignore them as ridiculous rantings Netscape would have had time to consolidate its base before the Microsoft onslaught.
In order to prevent that I made it my business to make it impossible for the upper echelons of Microsoft to ignore Netscape.
Setting Microsoft on Netscape was a win-win situation, one of them would take the other out. Taking out Netscape was the win I was after however.
As Oscar Wilde said 'choose your enemies carefully'.
Actually, they licensed the spyglass browser and then gave it away for free. Nearly killed the company (Spyglass)
That is not really fair. Spyglass had already given up on the Web browser when they licensed the code to Microsoft. They found they could not make a profit because Netscape effectively gave the browser away for free (sound familiar?).
The Spyglass browser for Windows started from the worst of the Mosaic code bases. The X-Windows code was completely separate. The Windows code was a mess for many reasons, not least the fact that Windows 3.1 was a crock.
By the time Spyglass had cleaned up the code Netscape were way ahead and were puring far more effort in than Spyglass management would pay for. Spyglass Mosaic lacked basic features like tables support, adding something like Javascript or SSL was just not happening on 'Internet time' - or any time come to that.
Microsoft took the spyglass code base and used it for their first IE release, but the later releases share very little code. I doubt there would be much if any of the original code left by now.
More likely the issue is that all the ex-DECies who went to work in Redmond prefer to work with an O/S that looks as much like ULTRIX as they can find these days.
Re:Please do correct me if I'm wrong, but
on
How to Save PGP
·
· Score: 4, Informative
Encryption (S/MIME) in Netscape and outlook is it's own worst enemy, because of the requirement to submit your personal information to a "trusted" third party (ie, a corporation - who many of those smart enough to know that encryption isn't a good idea won't trust at all) and then rely on the same "trusted" party to verify that everyone else in the world is who they say they are.
You don't have to be a corporation to sign keys. In fact there is a certificate signer distributed with every copy of Microsoft Office and Windows XP. Code to create X.509 certs is available as freeware in many open source distributions.
If you try to do this with any S/MIME client that I know of, it will claim that the certificate is untrustworthy because Friendly Trusted Company, Inc hasn't signed for it.
You can select the certificate and say 'trust this certificate' explicitly in all the popular implementations.
If you don't like the way the S/MIME cert handling is done it is easy enough to do it any way you choose.
Another scheme would be to set up an XKMS interface to a PGP web of trust and then drop an XKMS client into the CAPI or cryptoAPI layer of your favorite email client. Then you can configure any trust semantics you like in your Web O' trust service. No different in principle from using the BaL keyserver at MIT but a lot more powerful.
Re:Sorta Phil's fault
on
How to Save PGP
·
· Score: 3, Informative
The PGP algorithm was not Phil Zimmerman's to sell. He basically made a freeware version of a popular commercial program, using their proprietary algorithm, and spread it all over the internet.
No he did not. Phil did not have rights to use the RSA algorithm. But the code, the message formats, everything that was all Phil and Phil alone.
Drove the rest of us working on secure email up the wall. Phil had a point about the PEM certification hierarchy nonsense. But he could have reused the PEM message formats instead of rolling his own.
The version of PGP in use today is largely the MIT version set up by Jeff Schiller and Hal Abelson and coded by Derek Atkinson arround RSAREF. That version has always been GPL as far as I know, with the major proviso that it linked to RSAREF which was encumbered big time but had no choice 'cos of the patent.
Re:Please do correct me if I'm wrong, but
on
How to Save PGP
·
· Score: 2
Isn't PGP kind of a dead end, ultimately? Based on my limited (and quite possibly wrong) understanding, as quantum computing research continues, it will become possible to break this encryption. Right?
Well PGP is a dead end but not for the reasons you give!
Quantum computing is practically irrelevant for mainstream crypto. If someone does build a big enough quantum computer it is unlikely that we will ever know about it. But we do know that there are some pretty severe limits on what it can do, it is not a magic wand. A quantum computer does not help against AES or SHA-1 for example. I suspect that long before Quantum computing is real there will be replacements for RSA that are robust against quantum computing.
The reason PGP is a dead end is that it was only deployed for email and only gives good privacy. PGP is not a good mechanism for signing binding e-commerce contracts.
It would be much better if people spent their time persuading people to use the crypto that is already built into Outlook Express, Communicator, Notes etc. rather than trying to resurect a competing message format.
Cookies were not invented to so that advertisers could track users. They were invented to give the web a semblance of statefulness.
I don't believe you were involved in the development of the Web at the time. I was.
All Netscape cared about was pushing as many features into the browser that they could to support their corporate customers business plans. Protecting privacy was not a consideration.
Man, you are smoking some good stuff. I don't know which of your fantasies is crazier:
(1) J2EE, which currently dominates the Enterprise software market, losing out anytime soon to.NET.
(2) Itanium rescuing itself from its current death spiral.
Letsee, I predicted the rise of the Web in 1992, that the Interactive TV model would fail 1993, that the established retailers would see off most of the etailers 1994, that the supermarket distribution model would kill Webvan et al, 1995. All of which was against the general consensus of the day.
The risk to J2EE is very real. Microsoft's CLI technology can run Java faster than any JVM. No amount of JVM tweakage can make up the difference, CLI is simply the intermediate stage of the standard C++ compiler and contains all the optimization info needed to make the highest performance code. Expect a rash of server adverts benchmarking a.NET server against J2EE.
Itanium is only having difficulty because there is diddly squat to run on the chip. Once Itanium can run everything that x86 can it will wipe the floor with the older architecture.
Just open source it...but then again open source and security software aren't best used in the same sentence.
PGP does not depend on keeping the code secret for security.
However the idea that open source automatically means good security software is not generally accepted in the crypto community. The canonical example being Kerberos whose design and code were public for 10 years before a major flaw was found.
The point is that the ability to review code does not translate into the code being reviewed and where security code is concerned who is doing the review matters. Open or closed source does not make as much difference as expert or inexpert review.
Most of the crypto code in use in closed source software is based on BSafe which has been extensively reviewed by at least as many crypto specialists as PGP.
It is a pity that folk talk about 'death of PGP' rather than 'using encrypted email'. How the email gets encrypted is not as important as the ability to encrypt. The major commercial email packages have been supporting S/MIME for a long time now.
That makes about as much sense as saying "Spammers invented open relays so they could spew their crap across the Internet."
The only thing SPAMers invented was spam and new techiques to spam.
Cookies are not a part of the HTTP protocol. They are an extension that was originated at Netscape and deployed without any consultation in the IETF HTTP working group.
Netscape knew that there were privacy issues with cookies but simply did not care. Until PGP cookie cutter came out the only way to turn off cookies was to have the browser ask you each time if you would accept them.
Slashdot Mirror
Most of the NG troops don't even have a clip in the rifle. You don't exactly want your weekend warrior types shooting off rounds accidentaly.
The guards carrying guns at European airports are typically elite units that specialise in armed security.
As I stated in the post the difference between the C familly languages is likely to be least. In particular I don't expect there to be a speed penalty for J#.
I also stated that functional languages are likely to be somewhat disadvantaged. I suspect that overall however the differences between languages will be somewhat reduced compared to traditional contests where the quality of implementation is the dominant variable being measured.
Not that it's different than with any other topic, it just happens that I'm a Compiler Expert (TM).
Pity you don't appear to be an English comprehension expert.
One of the fun things .NET does is to finaly make a fair comparison of programming languages possible. In the past the problem has been that most competitions of that type tended to be won by FORTRAN, not because the language was any good or fast but just because of the humongous amount of work that has gone into optimizing FORTRAN compilers.
C compilers have recently overtaken FORTRAN for the same reason, the effort put into optimization, plus C is quite a bit friendlier to the optimiser than FORTRAN.
With .NET you can use the same back end to produce code for practicaly any mainstream language and plenty of far from mainstream ones. It is very unlikely that there will be major performance differences between Basic, C#, and J#.It will be interesting to see how much the gap between C and Perl is narrowed.
Some of the traditional gap between the C languages and functional languages will be narrowed because CLI is a managed code environment. I suspect there is still some performance penalty to using functional languages in a functional maner but it will probably be irrelevant since you only need to use thefunctional code for the parts where functional languages help.
Case in point here is I remember once writing a prolog program to do soe stuff. Prolog was great for the real problem but when it came to all the support code to do the UI and I/O it really started to creak. Not only was the code slow, it was also really hard to write and was full of kludges (anyone remember the cut?).
Twaddle. IBM screwed up OS/2 by insisting that it support the PC AT with the derranged 286 memory scheme.
Microsoft hired much more of the VMS team than Dave Cutler. Even if they did just hire 'one guy' it was the guy in charge.
The first release WNT internals were so close to those of VMS that VMS system programers such as myself pretty much knew most of the O/S when it was released. That would be quite a coincidence if it was OS/2 underneath.
That was the opinion of Ken Thomson and co. However I don't believe that the view was widely held by people who had extensive experience of using the systems you cite.
The real problem was that making use of the features required you to write bespoke code to the O/S. That and the fact that on the class of hardware Thomson and Co had available there was no real performance penalty for performing complex file management at the process level. Modern network attached storage architectutres essentially recapitulate the older data concentrators which were designed to take load of the processor and storage/processor communications bandwidth.
The arguments about pipes and such are just UNIX ideology. Serializing a data structure is easy if you have metadata.
Of course you might be right in thinking that the last word in computer architecture was made in the 1970s. Personally I disagree with you, UNIX is a crock and as I pointed out to Denis Ritchie I am one of the few people who can say they worked on a system that was more successful and has more users.
The question is 'at what level'. I would guess that OFS will continue to export the traditional file system interfaces and emulating the file system interface would be relatively straightforward.
Accessing the object level methods is going to be very hard. UNIX does not support analagous data abstractions. To UNIX everything is a file is a stream of binary data. To OFS everything is an object that is indexed six ways from sunday.
It is quite a while since I last wrote a database. However if you want speed you don't want the overhead of relational. ISAM is much faster.
Traditional measures of speed are going to become progressively less relevant as RAM prices continue to drop. The bulk of the Oracle architecture is concerned with optimizing the path of R/W heads over disk platters. A lot of the constraints of the SQL model are due to trying to lay out data structure on disk.
Massive simplification is possible if you start from the position that the data structure will be in-memory and the only thing written out to disk will be the transaction log.
I think you are right, at least in part. I think that the other issue to consider is the close relationship between WNT and VMS.
The last major release of VMS with a major improvement was back in about '91 when they added in the low level support for transactions in the file system. This was a truly major breakthrough. it is a pity that it came towards the end of the VMS era and as a result was never really exploited by applications.
The advantage of a transaction based file system is that you can write updates out to disk without having to worry about partial completion. You know that the write will either succeed completely or fail completely. It is not possible for the program to crash in mid write and leave the data in a corrupted state.
This would be a major advantage for application programmers. You could get ACID properties without having to mess arround changing your data structures to use SQL. You would not need to deal with the twits who think that Entity Relationships are the latest thing in comp sci rather than what they really are, an obsolete throwback from the COBOL era. You would not need UML or any of that rubbish either. And you can hand your Oracle DBA their pink slip.
All in all a win win situation, unless that is you are an Oracle DBA or hold Oracle stock.
Actually this is not true when it comes to DRM measures. The problem here is that you are trying to keep information secret while sharing it with a few tens of millions of subscribers.
Ultimately any crypto scheme depends on the secrecy of a small number of keys. If a person reveals their key deliberately then anyone can read the information sent to them.
That said the Canal+ scheme does not have a great reputation for security. There are plenty of schemes that at least require the attackers to extract secret keys from smart cards. The satelite TV DRM problem is much easier than the DVD type problem. With a DVD player you can't issue a different key to each user and withdraw use rights on a per player basis. With satelite TV you can.
Exchange is a 'non-proprietary core' (at least in the DMS usage). Exchange 5.5 is an X.400 MTA. The is nothing proprietary about X.400, it is just that Microsoft is the only vendor that still sells that junk.
Exchange 2000 removes the X.400 junk from the core. It is not an OSI MTA that also does Internet, it is an Internet MTA that also does OSI. Don't judge Exchange by the horrors of 5.5, those horrors are mostly intrinsic to the OSI junk it is based on (plus the MAPI horrors).
The problem with DMS is not that they chose prorpietary software, they simply chose the wrong open standard. Even today we have DMS folk comming to the IETF with drafts proposing some form of X.400 interop for S/MIME.
What it comes down to is that the military defined a mail system that was so complex that Microsoft was the only company arround with the resources to provide client support.
I think in hindsight, that would have been a very sensible decision, don't you?
It isn't a matter of hindsight, there are plenty of reasons why DMS and the Federal govt. PKI are problematic. Most of those were known at the start.
And what public domain software is there out there that suports S/MIME security labels as mandated by the DoD?
PGP is simply not up to the task of providing a military messaging system. In fact the principle insight that Phil Z. had was that PEM was being designed with the assumption that the rest of the world ran according to the strict hierarchical principles of the military.
What the posters on this whole story don't understand is that they have a radically different approach to security than the Air Force. In the real world you increase security by removing features. In the military you increase security by adding security features.
DMS was designed in the days before 'Commercial Off the Shelf' (COTS) became a US govt buzword. The military do genuinely have a number of requirements that are not shared by the general public, such as the ability to continue functioning after the loss of 80% or more of the infrastructure in a particular locality. But there is no reason why they need their own message formats and there is no reason why DMS can't use COTS to provide at least a core.
And the folk who gave us the DMCA would be? Oh yes thats right, Orin Hatch and the GOP.
OK so Hatch has since discovered that the RIAA lied to him repeatedly and took him for a fool, but the fact is that the GOP record on this issue is no better.
It is Ashcroft's 'justice' dept that has been out to make 'high proile arrests' to enforce DMCA.
I don't think this is a left/right issue at all. This is a donor/citizen issue. Hollings and his cronies in the Senate care more about the interests of the donors than the voters.
As for Jeffords, put the blame where it belongs. GWB began his term of office in the most divisive and partisan manner imaginable. Jeffords had run as a moderate conservative, not as an extreemist.
Let us supose that someone discovers a bug in the MAC O/S that is only relevant to online control. almost no MACs are used for online control, what is the probability your bug will ever get fixed?
The original story in this case is posted with the intention of obtaining a particular answer. The poster is not really interested in what system would be secure, he wants to have his original prejudice reinforced.
Design of ship control systems is a real time control problem. As such it is not an application for which 'Linux' is a solution, you have to be much more precise and specify exactly which real-time enhanced Linux you are considering. It would also kinda help to actually specify the problems to be addressed
As for 'security', one would hope that you would not be hooking your control systems up to the Internet or running any sort of user application other than controls for the ship. The references to worms viruses etc suggest to me that the poster does not understand the problem or is trolling for anti-Microsoft stories to tell his manager.
I have noticed that a lot of the moderators who use their mod points to punish views they don't like but know people are likely to think fair will use 'overated' to mod people down. That way they reduce the risk that they will be metamoderated as 'unfair' which they know would be likely if they used 'troll' or 'flamebait'.
I think that this is basically a pretty pointless and largely ideological argument. In the one camp we have the Microsofties who don't like the idea of competing with 'free'. In the other we have the Open Sauce zealots who hate the idea of paying for anything.
As usual with idealogues, both sides are wrong. However they find plenty of followers because lots of people are lazy and would like others to do their thinking for them. Plus they have the idea that they can gain credibility and prominence by advocating the most extreeme position out there.
What I find most significant in the Perens article is that all the quotes he gives can be found in the original reports of the Mundie speech. He gives no more context than the original reports. This strikes me as a staggering coincidence, he found the exact same quotes from a 40 minute speech significant as the previous report! Was Perens present at the speech? Did he even listen to a tape of the speech? given the state of US journalism I strongly suspect that he did not and that he is not reporting on the speech, he is reporting on the reports of the speech.
I suspect the outcome was overdetermined. Whatever anyone outside Netscape did could hardly compete with Marc's own behavior.
Marc took every opportunity he could find to trash Microsoft and claim that Netscape was going to replace them.
Meanwhile Gates was stating in the press that he was concerned that Microsoft would become complacent and lazy as Lotus, Wordperfect and co had become. Marc offered himself up as the perfect enemy at the perfect time.
But don't discount the fact that there were plenty of people outside Microsoft looking to stick a knife in Marc's back.
He might not have been trying to compete with Microsoft, but others thought the competition would be interesting to watch.
Netscape was from the start paranoid about Microsoft, some of them even thought that Redmond might have bugged their HQ and would take you outside to dish the dirt on MSFT. Meanwhile they had made plenty of enemies, including me.
Microsoft at the time was snoozing away oblivious about the Internet. The entire focus of their company was on the launch of Windows 95 and the original MSN which was an AOL rip off. If Marc had not been mouthing off about replacing Microsoft or Microsoft had continued to ignore them as ridiculous rantings Netscape would have had time to consolidate its base before the Microsoft onslaught.
In order to prevent that I made it my business to make it impossible for the upper echelons of Microsoft to ignore Netscape.
Setting Microsoft on Netscape was a win-win situation, one of them would take the other out. Taking out Netscape was the win I was after however.
As Oscar Wilde said 'choose your enemies carefully'.
That is not really fair. Spyglass had already given up on the Web browser when they licensed the code to Microsoft. They found they could not make a profit because Netscape effectively gave the browser away for free (sound familiar?).
The Spyglass browser for Windows started from the worst of the Mosaic code bases. The X-Windows code was completely separate. The Windows code was a mess for many reasons, not least the fact that Windows 3.1 was a crock.
By the time Spyglass had cleaned up the code Netscape were way ahead and were puring far more effort in than Spyglass management would pay for. Spyglass Mosaic lacked basic features like tables support, adding something like Javascript or SSL was just not happening on 'Internet time' - or any time come to that.
Microsoft took the spyglass code base and used it for their first IE release, but the later releases share very little code. I doubt there would be much if any of the original code left by now.
More likely the issue is that all the ex-DECies who went to work in Redmond prefer to work with an O/S that looks as much like ULTRIX as they can find these days.
You don't have to be a corporation to sign keys. In fact there is a certificate signer distributed with every copy of Microsoft Office and Windows XP. Code to create X.509 certs is available as freeware in many open source distributions.
If you try to do this with any S/MIME client that I know of, it will claim that the certificate is untrustworthy because Friendly Trusted Company, Inc hasn't signed for it.
You can select the certificate and say 'trust this certificate' explicitly in all the popular implementations.
If you don't like the way the S/MIME cert handling is done it is easy enough to do it any way you choose.
Another scheme would be to set up an XKMS interface to a PGP web of trust and then drop an XKMS client into the CAPI or cryptoAPI layer of your favorite email client. Then you can configure any trust semantics you like in your Web O' trust service. No different in principle from using the BaL keyserver at MIT but a lot more powerful.
No he did not. Phil did not have rights to use the RSA algorithm. But the code, the message formats, everything that was all Phil and Phil alone.
Drove the rest of us working on secure email up the wall. Phil had a point about the PEM certification hierarchy nonsense. But he could have reused the PEM message formats instead of rolling his own.
The version of PGP in use today is largely the MIT version set up by Jeff Schiller and Hal Abelson and coded by Derek Atkinson arround RSAREF. That version has always been GPL as far as I know, with the major proviso that it linked to RSAREF which was encumbered big time but had no choice 'cos of the patent.
Well PGP is a dead end but not for the reasons you give!
Quantum computing is practically irrelevant for mainstream crypto. If someone does build a big enough quantum computer it is unlikely that we will ever know about it. But we do know that there are some pretty severe limits on what it can do, it is not a magic wand. A quantum computer does not help against AES or SHA-1 for example. I suspect that long before Quantum computing is real there will be replacements for RSA that are robust against quantum computing.
The reason PGP is a dead end is that it was only deployed for email and only gives good privacy. PGP is not a good mechanism for signing binding e-commerce contracts.
It would be much better if people spent their time persuading people to use the crypto that is already built into Outlook Express, Communicator, Notes etc. rather than trying to resurect a competing message format.
I don't believe you were involved in the development of the Web at the time. I was.
All Netscape cared about was pushing as many features into the browser that they could to support their corporate customers business plans. Protecting privacy was not a consideration.
Letsee, I predicted the rise of the Web in 1992, that the Interactive TV model would fail 1993, that the established retailers would see off most of the etailers 1994, that the supermarket distribution model would kill Webvan et al, 1995. All of which was against the general consensus of the day.
The risk to J2EE is very real. Microsoft's CLI technology can run Java faster than any JVM. No amount of JVM tweakage can make up the difference, CLI is simply the intermediate stage of the standard C++ compiler and contains all the optimization info needed to make the highest performance code. Expect a rash of server adverts benchmarking a .NET server against J2EE.
Itanium is only having difficulty because there is diddly squat to run on the chip. Once Itanium can run everything that x86 can it will wipe the floor with the older architecture.
PGP does not depend on keeping the code secret for security.
However the idea that open source automatically means good security software is not generally accepted in the crypto community. The canonical example being Kerberos whose design and code were public for 10 years before a major flaw was found.
The point is that the ability to review code does not translate into the code being reviewed and where security code is concerned who is doing the review matters. Open or closed source does not make as much difference as expert or inexpert review.
Most of the crypto code in use in closed source software is based on BSafe which has been extensively reviewed by at least as many crypto specialists as PGP.
It is a pity that folk talk about 'death of PGP' rather than 'using encrypted email'. How the email gets encrypted is not as important as the ability to encrypt. The major commercial email packages have been supporting S/MIME for a long time now.
The only thing SPAMers invented was spam and new techiques to spam.
Cookies are not a part of the HTTP protocol. They are an extension that was originated at Netscape and deployed without any consultation in the IETF HTTP working group.
Netscape knew that there were privacy issues with cookies but simply did not care. Until PGP cookie cutter came out the only way to turn off cookies was to have the browser ask you each time if you would accept them.