-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 14 February 2004 04:03 pm, John Andersen wrote:
On Saturday 14 February 2004 11:25, Steven T. Hatton wrote:
I have often wanted to be able to use some kind of style feature in email, but understand the security consequences of using HTML. That got me to thinking about some kind of XML that could be conjoined with CSS (perhaps a restricted subset of CSS) to produce nicely styled, safe emails. Does anybody follow what I'm saying? Has anybody tried such a thing already?
STH
I think you mis-understand the objection to html in email.
It is not objectionable ONLY because of security issues, but also due to the bulk it imposes on the email itself,
I think the bulk is a non-issue. It could be compressed to the point it is completely negligible. Also, with the increased speed of the net, doubling the size of text messages would not have much impact on download times, etc. Now, if this were to support images as well as typographical markup, that could increase the bulk significantly.
and the fact that it is not universally readable (such as when non-graphical mail readers are used).
UTF-8 has similar problems. As for typographical markup, that can be handled on a tty console in a way similar to lynx. Sure there would be a transition period, and there would always be a few clients which didn't adapt the technology. One big problem I see is that of handling replies that are constructed of a excerpts from previous mails, such as this one.
So comeing up with a non html solution solves only one minor aspect of the problem. It is after all, mostly a Microsoft problem of offering mail readers that can not be made secure.
I was seriously wonder if a class action against MS for gross negligence in the security area would be sustainable. My mail server is hit by an incredible amount of suff that is clearly MS propagated Trojan horses or viruses.
Kmail can be easily locked down and set up to never honor Html and security is then enhanced.
One problem with HTML is the fact that it can force a load of external content if it is fully enabled. That is something that should not be supported. And any actual links should be clearly identifiable as such by the non-technical user.
But in spite of the security, Size, and universal accessability issues there is ALSO the sheer annoyance factor of having to put up with someone's wild and crazy ideas of formating, Fonts, Colors, backgrounds.
Personally, I find the ability to markup text very powerful when expressing myself in written form. Just today I received a message on this list that was intended to be viewed as fixed width in one particular area. It would have been nice if the author could have included a simple <code> tag, or something to indicate what kind of content it held.
A growing number of people reject the idea that anyone with a keyboard and a modem gets to determine what appears on someone elses screen.
The kind of functionality I'm thinking of could probably be turned off with only limited impact on the actual content. I'm really not aware of a growing number of people actively fighting to precent someone form italicizing words in their sentences. Or providing color coded text. I believe the real concern is that 12-year-olds are being exposed to objectionable material.
The beauty of plain text is that ideas stand by themselves.
The beauty of syntax highlighting is that different ideas stand out, and are easily identified.
So I ask, will the free exchange of Ideas and discussion be enhanced in any meaningfull way if you succeed in developing a new style/graphic format that resolves security issues?
I suspect not, but that's just me... -- _____________________________________ John Andersen
That's what people used to say when we argued for better GUIs in Linux, back when Only a few dozed or so people could even spell KDE. Certainly there are potential problems, but there used to be mailing list that required all text to be ascii-7. I don't know if that still applied to the Mathematica list, but it did two years ago. STH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFALqHEH2SF0i7rrGwRAsTjAJ44SDCK5aM8ZBdz7DBLCsiguBe11QCgwTKb dRKNC7zcLyM+LHJnJoDUG7c= =ljOa -----END PGP SIGNATURE-----