Existing solutions are terrible
on
Making PKI Work
·
· Score: 4
I think half the reason you can't do encrypted e-mail (or encrypted anything else, for that matter) is that most "PKI"s are neither public, nor infrastructure.
Company A goes and spends a kagillion dollars on an Entrust solution and gets an overgrown LDAP server that only knows about its own keys. Who cares that Company B spent half a kagillion dollars on a Versign solution? Neither can communicate with the other, because they can't look up each other's public keys.
Everybody wants to push this stuff down to the end user, too. They want every Outlook, Netscape, etc, to have its own list of LDAP servers to query. LDAP is the kitchen sink of directories. It's totally overkill for the problem of "gimme a key!" Plus, why should every application writer have to maintain their own list of LDAP servers, write their own query mechanism, etc.
DNS has long had support for the essential key-distribution features. The resolver library ships on every single OS that can use the internet. The query structure and mechanism is known. The hierarchy rearranges itself flexibly. Delegation is easily achieved, both by InterNIC registration and KX records. If people would give up LDAP and move to something more flexible for key lookup, PKI's goal of being "public" and being "infrastructure" would be more attainable on a large scale.
My programmers have tried it and noticed two phenomena
People don't interrupt them nearly as much while their paired up. Someone who wants to interrupt sees that they're occupied and will come back later or send email.
They can focus on one problem for longer periods of time at one stretch.
Many of us multitask when we're working alone. Code a little, read slashdot a little, read email a little, code a little... My programmers find that when they pair program they don't switch to browsing the web or reading email when their partner is sitting there waiting to make progress on their task. It keeps them focused. Since it's active for both participants, however, they don't get fatigued by staying on one task for a long time.
Quality software cannot be forced into existence by policies. It must be created by talented software engineers that understand what the customer's needs are.
I don't think XP promises quality software if you just adhere to its rules. It's not a check-your-brain-at-the-door methodology. If, however, you adhere to a bunch of its principles (in ways that make sense in your organization), you'll make it hard for the really simple stupid stuff to get out the door. Few real companies are staffed with a complete set of the World's Greatest Programmers.
Programmers often need management, and not all managers understand what programmers are like, nor how to manage them. Given clueless management, XP is an easy way to do better than nothing.
If you work for clueless managers, sticking books (like the one reviewed here) under their noses is not going to fix the problem.
Naturally there is no quick fix to bad management. However, there is a lot of insight into programming and managing programmers in this book and other XP books. I did, in fact, put this book under my managers' collective noses and it did, in fact, improve their awareness of managing software. XP is very accessible to managers who are not familiar with how software needs to be managed. There is a pretty gentle learning curve to it.
Of course it's not perfect. Of course it doesn't solve everything. Management who have no clue, however, and who make an open-minded attempt at XP will probably find things improving over unmitigated chaos. Once they recognize the value of a methodology, they're free to choose one that's more appropriate.
This is the same approach people take with guns. I hate to sound like the NRA, but it's the same story. People want to make all kinds of rules, legislation and litigation around the tool, rather than the people who choose to use the tool irresponsibly.
Like guns, this makes the tool users reluctant to use the tools, because the climate is so antagonistic to the tool. It slurs all tool users with the same stigma.
I used to buy hardware and software for a major university's Computer Science Department. I learned eventually that vendors say "no" for a reason: competance. If the vendor isn't willing to sell you something, or if they're hesitant, it's probably a warning sign. Vendors are increasingly limited on what they're able to do well. This applies equally well to big and large vendors, hardware and software.
I tried asking Uncle Ed's garage-built computers to do SCSI systems. They couldn't tell fast wide from narrow from IDE. I tried getting major name-brand manufacturers to sell me a SCSI system that actually had SCSI components other than hard drives (CD-ROM, DVD, etc). Little success.
I learned this way to stick to what the vendors will readily do. As soon as you ask them to step out of their comfort zone, you're going to be on your own. You might as well save yourself the trouble.
Either find a vendor that lists something ready-made that fits your bill, or plan to do it yourself.
I'm so used to mentally adjusting for bad spelling, that I unconciously saw desperate user base. I had to reread to decide that it was actually spelled correctly.:)
ambiguity ain't it great
Good start. Use it to identify spammers.
on
Gnutella Vs. SPAM
·
· Score: 1
The client then checks the results and... adds it to a filter list.
The client could maintain its filter list (in memory or on disk) and make it a potential search result. E.g. a search for "KnownSpammers.txt" would result in that client's list of known spam bots.
I'm not saying that anyone should actually go off and do anything to the known spammers.:)
Spammers are only happy to spam when they feel relatively confident about their anonymity. If we take that away, they'll be less likely to spam.
This is the kind of reaction that fuels the fires of distrust.
Here we are at/. discussing a tool that has obviously been crafted to help encourage online collaboration without enabling the D00DZ who want to distribute WAREZ. What are the first reactions?
It sucks cuz I can't distribute illegal files
It just makes the suits who are concerned about abuse say "See: we told you so. All they want to do is abuse it."
We shouldn't mindlessly rally around the suits just because they think it's cool. But, we shouldn't snub it because it's not made for warez distributors. Let's judge it on some other basis.
Encrypting the sendmail connection only protects one link in the chain.
What if your external SMTP server gets it encrypted, but has to shuttle it over to the abominable Exchange server in plain text? That can get sniffed. If you use IMAP or POP without SSL/TLS, they can sniff that instead. It will be in plain text as it is downloaded to your mail client. Some software (notably Eudora) have no SSL support, which makes these folks particularly vulnerable.
If e-mail travels over the wire encrypted, but is stored in plain text in your mailbox, it's not safe. They can get a subpeona for your mailbox just as easily as they can get the wiretap order. Wrapping all the e-mail related connections is the only way to completely prevent Carnivore-style sniffing. Even if you do that they could get the the ISP to hand over the contents of your mailbox, and you'd never know.
Antivore uses SSL/TLS on all connections that send your e-mail unencrypted. It also keeps your encrypted email encrypted in your mailbox. Even if they subpoena your mailbox, they can't decrypt it without your passphrase for your private key. It also tries to (but, of course, cannot actually) prevent you from storing all your email unencrypted anywhere. There's even a (coming soon) interface through the Web Horde's IMP web mail interface.
Antivore is not the 100% perfect solution, but it gets encryption into the hands of the average person easily and painlessly. We use it here, and have no fears about our ISP, even if the did install Carnivore
Do we really want to call it our patriotic duty to send all our minutiae past the government's eyes? Do they really have the right to scrutinize any abritrary amount of my sad little life just because I use the same ISP as my drug-dealing neighbor? I just roll over and say "Ok guys, as long as you say it's for national security..."
I'm not sure I object to listening in on a suspected criminal's email. But the Carnivore system is the equivalent of tapping all the phones in a city block and listening to all of them just to hear the few conversations that a suspected criminal makes. Why is it that I'm just supposed to give them my whole personal and/or life details when both they and I know they have no business with those details?
They no longer assure me that I'm not being investigated when I'm not under investigation. They changed the rules big time.
I say encrypt: with antivore and Carnivore-be-damned.
This has essentially just been done. ChainMail released Antivore on monday.
It's basically a set of proxies that sit between your mail servers and your mail clients, and it handles all the encryption. It also handles key lookup and signature verification automatically. It does everything server side, though, so that users don't have to know how to manage all their keys, etc.
It's open source, but in beta condition. No hand-holding installers, yet, but it works. With something like this, you can do transparent encryption, and Carnivore-be-damned.
Slashdot Mirror
I think half the reason you can't do encrypted e-mail (or encrypted anything else, for that matter) is that most "PKI"s are neither public, nor infrastructure.
Company A goes and spends a kagillion dollars on an Entrust solution and gets an overgrown LDAP server that only knows about its own keys. Who cares that Company B spent half a kagillion dollars on a Versign solution? Neither can communicate with the other, because they can't look up each other's public keys.
Everybody wants to push this stuff down to the end user, too. They want every Outlook, Netscape, etc, to have its own list of LDAP servers to query. LDAP is the kitchen sink of directories. It's totally overkill for the problem of "gimme a key!" Plus, why should every application writer have to maintain their own list of LDAP servers, write their own query mechanism, etc.
DNS has long had support for the essential key-distribution features. The resolver library ships on every single OS that can use the internet. The query structure and mechanism is known. The hierarchy rearranges itself flexibly. Delegation is easily achieved, both by InterNIC registration and KX records. If people would give up LDAP and move to something more flexible for key lookup, PKI's goal of being "public" and being "infrastructure" would be more attainable on a large scale.
My programmers have tried it and noticed two phenomena
Many of us multitask when we're working alone. Code a little, read slashdot a little, read email a little, code a little... My programmers find that when they pair program they don't switch to browsing the web or reading email when their partner is sitting there waiting to make progress on their task. It keeps them focused. Since it's active for both participants, however, they don't get fatigued by staying on one task for a long time.
Quality software cannot be forced into existence by policies. It must be created by talented software engineers that understand what the customer's needs are.
I don't think XP promises quality software if you just adhere to its rules. It's not a check-your-brain-at-the-door methodology. If, however, you adhere to a bunch of its principles (in ways that make sense in your organization), you'll make it hard for the really simple stupid stuff to get out the door. Few real companies are staffed with a complete set of the World's Greatest Programmers.
Programmers often need management, and not all managers understand what programmers are like, nor how to manage them. Given clueless management, XP is an easy way to do better than nothing.
If you work for clueless managers, sticking books (like the one reviewed here) under their noses is not going to fix the problem.
Naturally there is no quick fix to bad management. However, there is a lot of insight into programming and managing programmers in this book and other XP books. I did, in fact, put this book under my managers' collective noses and it did, in fact, improve their awareness of managing software. XP is very accessible to managers who are not familiar with how software needs to be managed. There is a pretty gentle learning curve to it.
Of course it's not perfect. Of course it doesn't solve everything. Management who have no clue, however, and who make an open-minded attempt at XP will probably find things improving over unmitigated chaos. Once they recognize the value of a methodology, they're free to choose one that's more appropriate.
 
This is the same approach people take with guns. I hate to sound like the NRA, but it's the same story. People want to make all kinds of rules, legislation and litigation around the tool, rather than the people who choose to use the tool irresponsibly.
Like guns, this makes the tool users reluctant to use the tools, because the climate is so antagonistic to the tool. It slurs all tool users with the same stigma.
I used to buy hardware and software for a major university's Computer Science Department. I learned eventually that vendors say "no" for a reason: competance. If the vendor isn't willing to sell you something, or if they're hesitant, it's probably a warning sign. Vendors are increasingly limited on what they're able to do well. This applies equally well to big and large vendors, hardware and software.
I tried asking Uncle Ed's garage-built computers to do SCSI systems. They couldn't tell fast wide from narrow from IDE. I tried getting major name-brand manufacturers to sell me a SCSI system that actually had SCSI components other than hard drives (CD-ROM, DVD, etc). Little success.
I learned this way to stick to what the vendors will readily do. As soon as you ask them to step out of their comfort zone, you're going to be on your own. You might as well save yourself the trouble.
Either find a vendor that lists something ready-made that fits your bill, or plan to do it yourself.
I'm so used to mentally adjusting for bad spelling, that I unconciously saw desperate user base. I had to reread to decide that it was actually spelled correctly. :)
ambiguity ain't it great
The client then checks the results and ... adds it to a filter list.
The client could maintain its filter list (in memory or on disk) and make it a potential search result. E.g. a search for "KnownSpammers.txt" would result in that client's list of known spam bots.
I'm not saying that anyone should actually go off and do anything to the known spammers. :)
Spammers are only happy to spam when they feel relatively confident about their anonymity. If we take that away, they'll be less likely to spam.
This is the kind of reaction that fuels the fires of distrust.
Here we are at /. discussing a tool that has obviously been crafted to help encourage online collaboration without enabling the D00DZ who want to distribute WAREZ. What are the first reactions?
It just makes the suits who are concerned about abuse say "See: we told you so. All they want to do is abuse it."
We shouldn't mindlessly rally around the suits just because they think it's cool. But, we shouldn't snub it because it's not made for warez distributors. Let's judge it on some other basis.
Encrypting the sendmail connection only protects one link in the chain.
What if your external SMTP server gets it encrypted, but has to shuttle it over to the abominable Exchange server in plain text? That can get sniffed. If you use IMAP or POP without SSL/TLS, they can sniff that instead. It will be in plain text as it is downloaded to your mail client. Some software (notably Eudora) have no SSL support, which makes these folks particularly vulnerable.
If e-mail travels over the wire encrypted, but is stored in plain text in your mailbox, it's not safe. They can get a subpeona for your mailbox just as easily as they can get the wiretap order. Wrapping all the e-mail related connections is the only way to completely prevent Carnivore-style sniffing. Even if you do that they could get the the ISP to hand over the contents of your mailbox, and you'd never know.
Antivore uses SSL/TLS on all connections that send your e-mail unencrypted. It also keeps your encrypted email encrypted in your mailbox. Even if they subpoena your mailbox, they can't decrypt it without your passphrase for your private key. It also tries to (but, of course, cannot actually) prevent you from storing all your email unencrypted anywhere. There's even a (coming soon) interface through the Web Horde's IMP web mail interface.
Antivore is not the 100% perfect solution, but it gets encryption into the hands of the average person easily and painlessly. We use it here, and have no fears about our ISP, even if the did install Carnivore
.Do we really want to call it our patriotic duty to send all our minutiae past the government's eyes? Do they really have the right to scrutinize any abritrary amount of my sad little life just because I use the same ISP as my drug-dealing neighbor? I just roll over and say "Ok guys, as long as you say it's for national security..."
I'm not sure I object to listening in on a suspected criminal's email. But the Carnivore system is the equivalent of tapping all the phones in a city block and listening to all of them just to hear the few conversations that a suspected criminal makes. Why is it that I'm just supposed to give them my whole personal and/or life details when both they and I know they have no business with those details?
They no longer assure me that I'm not being investigated when I'm not under investigation. They changed the rules big time.
I say encrypt: with antivore and Carnivore-be-damned.This has essentially just been done. ChainMail released Antivore on monday.
It's basically a set of proxies that sit between your mail servers and your mail clients, and it handles all the encryption. It also handles key lookup and signature verification automatically. It does everything server side, though, so that users don't have to know how to manage all their keys, etc.
It's open source, but in beta condition. No hand-holding installers, yet, but it works. With something like this, you can do transparent encryption, and Carnivore-be-damned.