Jargons of Info Tech industry

[John Bokma]

bokr at oz.net (Bengt Richter) wrote:

> On 16 Oct 2005 00:31:38 GMT, John Bokma <john at castleamber.com> wrote:
> 
>>bokr at oz.net (Bengt Richter) wrote:
>>
>>> On Tue, 04 Oct 2005 17:14:45 GMT, Roedy Green
>>> <my_email_is_posted_on_my_website at munged.invalid> wrote: 
>>> 
>>>>On Tue, 23 Aug 2005 08:32:09 -0500, l v <lv at aol.com> wrote or quoted
>>>>: 
>>>>
>>>>>I think e-mail should be text only.
>>> I think that is a useful base standard, which allows easy creation
>>> of ad-hoc tools to search and extract data from your archives, etc. 
>>>>
>>>>I disagree.  Your problem  is spam, not HTML. Spam is associated
>>>>with HTML and people have in Pavlovian fashion come to hate HTML.
>>>>
>>>>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.
> Are you trolling? No, I don't mean the same problem.
> What an HTML interpreter does by _design_ is not in the same category
> as an implementation error enabling a root exploit.

Ok, what do you think are the bad things in HTML design? (For email that 
is). I can name only two:

1 - remote loading of objects
2 - when a user clicks on a link, this can be seen as a confirmation.

The latter is also possible in the email clients I have used when plain 
text is used. Ok, you can say that in HTML you can hide somewhat the 
destination, e.g. <a href="http://example.com/user-1234">Check out this
</a>. 

OTOH, you are not forced not to read the status bar.

[ ... ]

> Don't get me wrong, I said "all good stuff," as far as control of
> presentation is concerned. And I would be happy to have nice graphic
> email if I could get it as a self-contained file from my ISP's mail
> server, and I had a presentation engine involved that I knew was
> guaranteed to stick to presentation work without communicating over
> the web or doing anything else without my knowledge. 
> 
> I don't see any technical obstacle to that, but HTML is not designed
> to be the solution to that.

Of course: I can compose an HTML file which has the graphics embedded in 
HTML which works in the client I am using. Another option is to include 
the graphics as attachements (this works). I am convinced this also 
works for stylesheets and any other object. So in short, it's possible 
to get a self-contained email.

[ pdf ]
>>Ah, and that's exploit free?
> That's not the issue. All programs can have the kind of exploit
> possibilities that you are talking about. A program with the single
> purpose of interpreting a page description and presenting it
> graphically is easier to eliminate exploitable vulnerabilities from
> than a program that involves a lot of additional stuff.

I thought it was possible to add a remote link to PDF (but I couldn't 
make one with OOo -> export pdf). But I am afraid that as soon as PDF is 
taking over the role of HTML in email, it will certainly going to 
support things you consider harmfull (and are in some occasions, I mean, 
I agree that tracking of images in spam is a bad thing).

>>>>Program listings are much more readable on my website.
>>> IMO FOSS pdf could provide all the layout benefits while
>>> avoiding (allowing for bugs) all the downsides of X/HTML in emails.
>>
>>Amazing, so one data format that's open is better compared to another 
>>open data format based on what?
> I take it you don't understand the difference between pdf and html?
> 
> A primary thing is the monitorable data-moving activity that is
> involved. A pdf can have links, but they are not followed (not
> counting what closed source proprietary softare might risk a PR black
> eye doing) in the process of opening and presenting the document to
> you.

And a link in an HTML file is? (Ok, there are so called caching systems 
that do this with browsers).
 
> The whole file comes as a single unit normally

As I stated, this is possible with HTML, at least Firefox does support 
inline images (data scheme). CSS can already be included in the file 
itself.

> (though I could see the
> temptation to implement automatic font downloads and enable font-bugs
> like web-bugs based on that, though in a FOSS implementation, such
> [mal]features could easily be made optional). 
> 
> You could say features can be optional re HTML CSS and JS and all the
> other automatic web-accessing and other features of HTML, but by the
> time you made them all optional and turned them off, you wouldn't see
> the HTML-author's intended presentation. That is not the case with
> pdf. Also, a single pdf file would be coming from one place. There is
> not an on-the-fly gathering of elements that you have to use a special
> tool to determine for sure where all the requests to get them went, or
> to prevent them from going, and having the activity logged, not to
> mention what the interpretation of unknown elements might do. 

If it's not possible to remote link to an image in PDF, I wouldn't be 
amazed that if it is replacing HTML in email, such a thing will be 
added.

-- 
John                   Small Perl scripts: http://johnbokma.com/perl/
               Perl programmer available:     http://castleamber.com/
                                        I ploink googlegroups.com :-)