Robert A. Hayden writes:
I said it last week, and I'll say it again. From a sociological standpoint, it's those 10,000,000 computer-illiterate e-mail users that we need to focus all of our efforts towards. Those 5,000 literate people we really don't have to care about. [...snip...] Imagine if some people with REAL writing ability worked on some programs... [...snip...] I think the politics of PGP is stagnated at about two years ago or so. The demographics are no longer accepting to long technical rants. Today's generation of net.user doesn't need 100% security 100% of the time, what they need is "good" security when they want it, but in a way that they don't have to think much about.
This has been hashed over on the list many, many times in the past. I suspect there are competent programmers out there who want to write easy-to-use interfaces for PGP (I know at least one), but there are problems. To write a good GUI interface (with proper key-management features) on Windows or Mac, for instance, you need to have access to PGP's internal crypto routines as well as the routines for reading and writing PGP messages and key certificates. The problem is that the PGP 2 code does not have the internal 'core' routines separated from it's command-line interface. The answers are to either shell out to PGP (which, AFAIK, is what every interface except MacPGP does), hack the PGP 2 code, or use PGPTools. Shelling out to PGP isn't going to cut it for a slick GUI package, especially if you want to have a decent key-management interface. You could do it, but it will be slow and kludgy and you will have to change it all when PGP 3 comes out. Hacking PGP would be a major effort. Additionally, there is risk of introducing a subtle flaw in the crypto routines. However, the main killer is that PGP 3 is going to have a brand new key-ring format along with many other enhancements, fixes, and other changes to the crypto code. All of the work will have to be done again to bring the interface up to date when PGP 3 is released, which could be within 6 months (who knows?). PGPTools is buggy and not supported. Any effort to bring PGPTools up to a stable level would likely be thrown away when PGP 3 is released. The real solution is that PGP 3 will have all of it's core routines in a separate library with a stable API specifically for the purpose of writing slick interfaces. So basically all of the would-be PGP interface developers are waiting for beta releases of the library. Unfortunately, this has been the situation for almost two years now. By now the PGP 2 code could have been completely turned into a library with a clean API and no command-line interface remnants, but developers have been discouraged by the promise of PGP 3 coming out 'RSN'... andrew ...still waiting for pgp 3 news...