Jargons of Info Tech industry

[John Bokma]

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

> - Javascript.

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
>>them. 
> 
> 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 :-)