Jargons of Info Tech industry
john at castleamber.com
Tue Oct 18 00:41:36 CEST 2005
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
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
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
> (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
John Small Perl scripts: http://johnbokma.com/perl/
Perl programmer available: http://castleamber.com/
I ploink googlegroups.com :-)
More information about the Python-list