On Tuesday 19 November 2002 11:51 pm, Chuq Von Rospach wrote:
On Tuesday, November 19, 2002, at 08:44 PM, Phil Barnett wrote:
...and so we should dumb down all their software so it doesn't offend them...
No, the proper question is whether it's appropriate for the list server software to take the lead in pushing this technology out to the users.
In the case of List-ID and List-*, it's clear that the list server has to go first, because otherwise the mail client authors have no motivation to implement support for the headers. Asking the mail clients to add support first here is wrong.
But encryption? Since no mainstream client supports encryption, and building in encryption is hard to use (even for geeks) and non-trivial, tell me why it's the list server's responsibility to blaze this trail?
As far as I can see, there's only one reason. The server is locking the client into passing plaintext passwords around the planet without an alternative. If this alternative is not offered at the server, no client can implement it. The server is the only appropriate location to offer this capability. Modifying the client will never make this capability available.
IMHO, it's not. Themail clients need to get their encryption act together. Until they do, builting encryption into the server tools is stupid, because it won't be compatible with stuff when they DO build it into clients (and until they do, it'll be there, but only the five geeks out there will use it).
so putting it into the server when there's no acknowledged standard and no client support -- why?
Standards are ALWAYS out of date. That's what makes them standards. What comes before standards? Implementation by people who didn't wait for standards to exist. What happens then? Standards emerge.
Do we wait for standards or go for capability?
Explain why it's the server's responsibility to go first here?
I'm not sure that I agree that there are no mail clients that went first.
Every mail client that I've used on both Linux and Windows supports GPG or PGP for several years. (when I've had a choice of which mail client to use)
Now, with that said, it's not the point. Why should this be implemented?
Because we're sending passwords in plaintext. That alone is enough reason.
Ideally, these capabilities would be developed in tandem, but that would require a controlled environment, such as a business controlling it's deployed software. As open source advocates, we don't have that luxury. In open source, it's always been features first, adoption and implementation second. Every open source 'standard' that we use today grew out of this method. Let the strong survive and the weak die. Darwin in high speed.
Sending passwords as plaintext in 2002 is downright negligent considering the current state of sniffing, monitoring and penetration. I admit that the developers might need to rip out PGP/GPG and use whatever becomes the standard in the future, but that is no reason to continue to treat the internet like it's 1988. At least by the time this feature needs an overhaul, a working framework will exist and it will be easy to move forward with whichever standard eventually evolves.
It's not like our planet is flat and we'll fall off the edge if we sail too far...
Now, with all that said, it's likely to increase support requirements (which can be mitigated to some extent with proper documentation). That, IMO, and developer time and effort would be the only good reasons to not persue opt-in sending of encrypted passwords. And, I'm not married to PGP/GPG, but I don't think there's a more ubiquitous encryptor out there.
I'm not a developer on this project and won't be in the foreseeable future, so from my end, it's just another wishlist item. In open source, it's the developer who is king and gets to decide these things. If this problem bugs an active project developer enough, I would expect him/her to scratch the itch. I'm content to wait for that time to arrive or not. Such is the life of an open source advocate.
--
Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo