Re:Why kernel development still uses email
by dredmorbius on Monday October 03, 2016 @11:18PM
(#12633096)
First: thanks for a point-by-point commentary.
I disagree with some of your points, but also want to note that what I gave as email's weaknesses are frequently also strengths. I'll try to clarify the distinction.
1. Clients: There are cases in which functions which ought be standardised aren't. These are particularly problematic where archives of email from multiple systems are presented. References, quoting, and reply styles are three long-standing friction points. Various conventions for noting changes in documents -- GUI client users relying on word colour won't play well with those using text-oriented platforms. Including now a great many mobile email clients, not just mutt and pine users.
Standardisation is what makes more complex interactions possible, whether you're talking messaging formats, file formats, or nuts and bolts sizing. This makes for an interesting though likely side conversation. My point is that the lack of agreement across major families of email clients makes more complex email interactions quite painful, something I've noted for decades.
The biggest problem I'm seeing is that client tool vendors simply aren't addressing numerous areas of concern, such as those I've listed here, or working in the least toward interoperability. This is for quite understandable reasons (gaming and abusing standards for selfish gain is an old trick), but it doesn't make the resulting situation any more desirable.
2. PGP/GPG doesn't address metadata privacy at all. It's not supported by many clients (see above), and has posed very long-standing issues by way of key management and web-of-trust issues. Moxie Marlinspike is among the voices suggesting PGP may have to be swapped for something else. I'm not sure I agree with his assessment, but his isn't a voice to be trifled with.
Without encryption at the transport layer, and on a guaranteed basis, privacy protections simply don't exist. The level of concentration of email services leads to other massive concerns. Much of that is due to a lack of sufficient trust mechanisms built in at the peering level, so one problem (spam + trust) feeds another (privacy).
3. The issues of user idiosyncracies is amplified by other factors, including the client issues above. Tools to standardise formats, or convert to/from various standards, might help. My primary issue is that problems in one area of the messaging world amplify those in others. It's a mess, and neither users nor tools are helping much.
I'm aware that people aren't robots. Not all of them, at least. Providing tools that make it harder to do the wrong thing would help considerably. That's not what we have now.
4. File formats: again, it's a matter of standards. Negotiation of what is/isn't permitted, and/or required, on a given conversation, for example, might go a long ways to addressing this.
5. The directory. Addressed elsewhere. More a characteristic / non-characteristic of email as a whole, though one many proposed replacements get on the wrong side of (trying to provide a total global directory).
6. Ties in to clients, security, authentication, privacy, and a mess of other factors. It's a problem, but it's a problem grounded in virtually every other part of the email system.
7. Reputation: see above. Though I agree that it's not something that can be addressed through a central agency. Another much longer discussion.
Again: the point in my list is to note where email fails most egregiously. I like email. I've used it for thirty years. I've defended it, strongly, against numerous previous criticisms. But I've come to change my mind, in that several of the fundamental premises and capabilities of it are now fatally flawed. It needs a massive refresh.
I disagree with some of your points, but also want to note that what I gave as email's weaknesses are frequently also strengths. I'll try to clarify the distinction.
1. Clients: There are cases in which functions which ought be standardised aren't. These are particularly problematic where archives of email from multiple systems are presented. References, quoting, and reply styles are three long-standing friction points. Various conventions for noting changes in documents -- GUI client users relying on word colour won't play well with those using text-oriented platforms. Including now a great many mobile email clients, not just mutt and pine users.
Standardisation is what makes more complex interactions possible, whether you're talking messaging formats, file formats, or nuts and bolts sizing. This makes for an interesting though likely side conversation. My point is that the lack of agreement across major families of email clients makes more complex email interactions quite painful, something I've noted for decades.
The biggest problem I'm seeing is that client tool vendors simply aren't addressing numerous areas of concern, such as those I've listed here, or working in the least toward interoperability. This is for quite understandable reasons (gaming and abusing standards for selfish gain is an old trick), but it doesn't make the resulting situation any more desirable.
2. PGP/GPG doesn't address metadata privacy at all. It's not supported by many clients (see above), and has posed very long-standing issues by way of key management and web-of-trust issues. Moxie Marlinspike is among the voices suggesting PGP may have to be swapped for something else. I'm not sure I agree with his assessment, but his isn't a voice to be trifled with.
Without encryption at the transport layer, and on a guaranteed basis, privacy protections simply don't exist. The level of concentration of email services leads to other massive concerns. Much of that is due to a lack of sufficient trust mechanisms built in at the peering level, so one problem (spam + trust) feeds another (privacy).
3. The issues of user idiosyncracies is amplified by other factors, including the client issues above. Tools to standardise formats, or convert to/from various standards, might help. My primary issue is that problems in one area of the messaging world amplify those in others. It's a mess, and neither users nor tools are helping much.
I'm aware that people aren't robots. Not all of them, at least. Providing tools that make it harder to do the wrong thing would help considerably. That's not what we have now.
4. File formats: again, it's a matter of standards. Negotiation of what is/isn't permitted, and/or required, on a given conversation, for example, might go a long ways to addressing this.
More generally, email as with the Web operates as an error condition: http://deirdre.net/programming-sucks-why-i-quit/
5. The directory. Addressed elsewhere. More a characteristic / non-characteristic of email as a whole, though one many proposed replacements get on the wrong side of (trying to provide a total global directory).
6. Ties in to clients, security, authentication, privacy, and a mess of other factors. It's a problem, but it's a problem grounded in virtually every other part of the email system.
7. Reputation: see above. Though I agree that it's not something that can be addressed through a central agency. Another much longer discussion.
Again: the point in my list is to note where email fails most egregiously. I like email. I've used it for thirty years. I've defended it, strongly, against numerous previous criticisms. But I've come to change my mind, in that several of the fundamental premises and capabilities of it are now fatally flawed. It needs a massive refresh.
(I'm also a fan of IRC.)