Jargons of Info Tech industry
john at castleamber.com
Sun Oct 16 07:06:39 CEST 2005
gordonb.8p4v4 at burditt.org (Gordon Burditt) wrote:
>>>>But HTML is not the problem!
>>> Right, it's what the HTML-interpreting engines might do that is
>>> the problem.
>>You mean the same problem as for example using a very long header in
>>your email to cause a buffer overflow? That is possible with plain
>>ASCII, and has been done.
> Before worrying about the possible bugs in the implementations,
> worry about security issues present in the *DESIGN*.
You mean like email travels like plain text over the Internet?
> Email ought
> to be usable to carry out a conversation *SAFELY* with some person out
> to get you. Thus features like this are dangerous (in the *design*,
> not because they *might* hide a buffer-overflow exploit):
> - Hyperlinks to anything *outside* the email in which the link
> resides ("web bugs").
Same holds for a link in plain ASCII
Is not HTML
>>>>That is like hating all choirs because televangelists use them.
>>>>HTML allows properly aligned table, diagrams, images, use of
>>>>colour/fonts to encode speakers. emphasis, hyperlinks.
> The trouble is, it allows way too much dangerous stuff.
Same with attachements, shall we remove those too?
>>> All good stuff, but I don't like worrying about side effects when I
>>> read email.
>>Then you should ask people to print it out, and use snail mail.
>>Exploits in email programs are not happening since HTML was added to
> Yes, they are.
No, they are not. Buffer overruns with plain ASCII text have happened in
the past. Dangerous attachements have been sent before HTML was
available in email.
> Why do you think people put "web bugs" in email?
> Because they work.
Same with attachements...
John Small Perl scripts: http://johnbokma.com/perl/
Perl programmer available: http://castleamber.com/
I ploink googlegroups.com :-)
More information about the Python-list