Jargons of Info Tech industry

[John Bokma]

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.
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.

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.

How about pdf?

Ah, and that's exploit free?

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?

 

[Gordon Burditt]

But HTML is not 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*. 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").
- Javascript.
- Any ability to automatically generate hits on sender-specified
servers when the email is read.
- Any kind of return-receipt mechanism that doesn't require initiation
by the recipient.
- Any kind of return-receipt mechanism that indicates that the
message got past the spam filter.

The trouble is, it allows way too much dangerous stuff.

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. Why do you think people put "web bugs" in email?
Because they work.
Gordon L. Burditt

 

[John Bokma]

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

The trouble is, it allows way too much dangerous stuff.

Same with attachements, shall we remove those too?

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...

 

[Roedy Green]

How about pdf?

End users HATE PDF. Why?

It takes so long for the reader to load.

It is so slow on older machines to render and scroll.

My complaint with it is it is Adobe proprietary. This make the tools
very expensive.

I like PDF because:

1. documents have to be prepared before posting. This means you don't
have malformed syntax in them.

2. You can reasonably quickly turn computer printouts or paper
documents into web content.

3. You don't have to guess what the end user will see.

 

[Ben Pfaff]

End users HATE PDF. Why?

It takes so long for the reader to load.

xpdf comes up almost instantly here. Maybe end users should
consider finding a better PDF reader.

 

[Bengt Richter]

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.

Then you should ask people to print it out, and use snail mail. Exploits

_I_ should, because _you_ can't think of a better solution?
Always happy to get useful advice, though ;-)

in email programs are not happening since HTML was added to them.

You mean they didn't start happening, presumably. But I'm not talking about exploits,
I'm talking about what HTML is designed to do, which is to describe a presentation
composed of elements which in general requires retrieving many elements separately
as the indirect references (links) are interpreted and the data is requested from
the indicated servers -- all at HTML interpretation-time, whatever client engine is
doing that for browser or email reader etc.

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. IMO pdf comes close. I recognize that a pdf interpreter
can also have exploitable implementation errors, just like an ascii email client,
but that is not what I am talking about.

I prefilter email into plain and X/HTML-containing mailboxes, and I don't open
HTML email from unknown sources, though if I am really curious I will drag and
drop the email into a "probtrash" mailbox and use a python script that extracts the
text or other info as text in a console window. All the ones purportedly from ebay and amazon
and paypal have been phishing attempts which would look pretty convincing if displayed
by normal X/HTML interpretation. If my ISP had a better filter or I imporved mine,
I wouldn't see that, but in my normal ascii email boxes I don't have to worry about that,
I just have to resist the social engineering of the offers from Nigeria etc. ;-)

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.

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.

The whole file comes as a single unit normally (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.

Regards,
Bengt Richter

 

[Pascal Bourguignon]

3. You don't have to guess what the end user will see.

If you include the fonts, which makes big documents which slows down
the loading and rendering... I've seen quite a number of PDF that are
ill-rendered or not rendered at all.

 

[Mike Meyer]

My complaint with it is it is Adobe proprietary. This make the tools
very expensive.

No, it isn't. The standard is publicly available, so anyone can write
tools that produce and/or manipulate PDF. Lots of people do. Pretty
much any WP or DP package worth using will generate PDF at out of the
box - and some of those are free.

<mike

 

[John Bokma]

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 ]

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

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.

 

[Tim Tyler]

There was a pretty good one that went something like

Click this link to download latest security patch!
<a href=http://www.mxxxxxx.com.....>Microsoft Security Center</a>

where "mxxxxxx" is "microsoft" with the letter "i" replaced by some
exotic Unicode character that looks exactly like an ascii "i" in normal
screen fonts. The attacker had of course registered that domain and
put evil stuff there.

I didn't think unicode domain names existed.

It seems that they are in the pipeline:

``After much debate and many competing proposals, a system called
Internationalizing Domain Names in Applications (IDNA) was adopted as
the chosen standard, and is currently, as of 2005, in the process of
being rolled out.''

- http://en.wikipedia.org/wiki/Internationalized_domain_names

It looks like the security issues are probably going to be dealt
with via technical fixes:

``On February 17, 2005, Mozilla developers announced that they would ship
their next versions of their software with IDN support still enabled,
but showing the punycode URLs instead, thus thwarting any attacks while
still allowing people to access websites on an IDN domain. This is a
change from the earlier plans to disable IDN entirely for the time
being.''

- http://en.wikipedia.org/wiki/Internationalized_domain_names

Anyway, I'm inclined to suggest this is a DNS problem. It would
apply to any format that allowed rendering of domain names using
the unicode character set they are intended to be displayed using.

Even without unicode, the "homograph attack" is still viable, due
to things like the "l"/"I" issue in many fonts - as pointed out on:

http://www.centr.org/docs/2005/02/homographs.html

 

[Tim Tyler]

Roedy, I would just _love_ to see the response from the industry when you
tell them they should dump their whole mail infrastructure, and switch
over to a whole new system (new protocols, new security holes, new
problems start to finish). [...]

That's essentially what the IM folk did.

It seems quite possible that future email systems will evolve out of
existing IM ones.

Essentially, IM can do pretty-much everything email can these days, but
the reverse is not true at all.

IM also seems more evolvable than email is managing to be.

About all email has going for it these days is an open format and a
large existing user base.

 

[Tim Tyler]

Before worrying about the possible bugs in the implementations,
worry about security issues present in the *DESIGN*. 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").

Acceptable risk, IMO.

- Any ability to automatically generate hits on sender-specified
servers when the email is read.

I hadn't though of that one. As well as use in DDOS attacks, that
can help let spammers know if they have reached a human :-|

Even a link in a plain text email can be used (though with reduced
effectiveness) in such a context :-(

 

[Roedy Green]

I didn't think unicode domain names existed.

you can even buy them. See http://mindprod.com/jgloss/domainnames.html

under "Chinese Domain Names".

 

[Roedy Green]

I hadn't though of that one. As well as use in DDOS attacks, that
can help let spammers know if they have reached a human :-|

If you think about it, much as you hate spammers you WANT them to have
that information. If you never read spam, and they know that, they
eventually might stop sending it to you and focus on the nitwits who
read it.

 

[Roedy Green]

Essentially, IM can do pretty-much everything email can these days, but
the reverse is not true at all.

The problem with IM is the various IM schemes don't talk to each
other. You need a client that knows all the IM protocols. But that
seems to be happening with Jabber and Trillian.

You have too much reliance on a central server. You have to trust the
relaying company. I think it is time that nearly all mail was
routinely and transparently end to end encrypted, with the exception
of long enclosures that are explicitly marked not confidential.

You still have spam to a lesser extent and strangers just wanting to
talk.

 

[Mike Meyer]

About all email has going for it these days is an open format and a
large existing user base.

Yeah, and all that Windows has going for it is being on 9X% of the
desktops. Nothing really important at all.

<mike

 

[noah bedford]

It is almost like providing ladders and setting out cookies and milk
for the burglars.

Fire escapes at christmas.