108004 - RFE "view HTML inline" menu item and/or toolbar icon

Status: RESOLVED INVALID

(SeaMonkey :: MailNews: Message Display, enhancement)

Description

[william.allen.simpson]

From Bugzilla Helper:
User-Agent: Mozilla/4.78 (Macintosh; U; PPC)
BuildID:    201103108

need a new menu item "View HTML Inline".

However, better yet, a Eudora-like per message button on the toolbar.  The 
setting would be saved in the database so that that particular message would be 
viewed as desired after the user had verified that they want to view the HTML
attachment(s).

As a security feature, should always default to "off".  Some forms of 
HTML can execute script or load images with comments that copy personal 
information back to the image server.

From a security point of view, this is "Critical"!

Comment 1

[Matthias Versen [:Matti]]

*** This bug has been marked as a duplicate of 69529 ***

Comment 2

[[e-mail] (gone - use [e-mail] instead)]

verified dup

Comment 3

[[e-mail] (gone - use [e-mail] instead)]

reopening per discussion via mail with wsimpson.

Comment 4

[william.allen.simpson]

It was never really related to #69529, except peripherally.

The recent implementation of (some) global preferences for disabling HTML display 
does not provide an opportunity for reading a particular message in HTML, saving 
the state of display on a per message basis.

Good security practice would be to never show HTML, until the user had reviewed 
the potential behaviour, and then selected this button/menu to enable display for 
the single message.

I've also been asked what would be displayed instead of HTML, which this RFE 
didn't address.  That was specified by several earlier reports, which I have now 
added to the dependencies.  (I'm sure I've missed some more.)

I still believe this is critical.  Without this feature, most users will simply 
turn on HTML processing, and be vulnerable to attacks.  Experience shows that 
unless security features are easy to use, users won't use them!

Comment 5

[Ben Bucksch (:BenB)]

Additional Comment #3 From [e-mail] 2002-02-01 11:12:
> reopening per discussion via mail with wsimpson.

wsimpson, since we discussed this per email, too, it would have been nice to cc me.

> The recent implementation of (some) global preferences for disabling HTML
> display does not provide an opportunity for reading a particular message in
> HTML

As I explained to you per email, it does. You have a relatively easily
accessible menu item (in contrast to a checkbox in the prefs window). You just
have to switch  back to plaintext after reading in HTML.

It is inconvient, and you might forget to switch back, yes, but given how
obscure that feature is for the average user, more UI for it (a checkbox *and* a
menuitem) would be overkill IMO.

> Good security practice would be to never show HTML, until the user had
> reviewed the potential behaviour, and then selected this button/menu to
> enable display for the single message.

Since most users don't even understand what HTML is (let alone any potential
risk), this proposal is unworkable.

> I've also been asked what would be displayed instead of HTML, which this RFE 
> didn't address.  That was specified by several earlier reports, which I have
> now added to the dependencies.

That still doesn't answer my question, because the bugs you added as deps
propose different, conflicting alterntives.


I still don't know what this bug is about. Please clarify. See my mails to see
what is missing.

Comment 6

[dylang]

View HTML inline would be a part of bug 30888.  Potientially a part of 28327 as
well.

I'd say it's a dupe.

Comment 7

[william.allen.simpson]

Well, Dylan, long ago I probably might have agreed with you.  Folks said it would 
be implemented as part of #69529.  It wasn't.  Or maybe #30888.  It wasn't.  
Those are both completed now.

Since it's not yet implemented, it's not a duplicate.  QED.

Ben, when implementing #69529 and #30888, you argued that the old way of viewing 
message source was good enough, just "inconvient".  We argued forcefully that we 
needed to turn on HTML source viewing as a global preference.  It's not good 
enough to look at the source _after_ it has destroyed your machine or given your 
email address to a spam haus.

Likewise, this is a convenience feature.  It's needed to make HTML useable.  If 
users need to be educated about the security problems with HTML, then of course 
they SHOULD be educated!  Or there shouldn't be any HTML mail support.  It's too 
dangerous.

Remember the problems educating 4.x users about inline attachments?  How they 
have to read most email with the menu item turned off, and turn it on for a 
message, and then turn it off again?  THAT'S REALLY INCONVENIENT.  USERS DIDN'T 
DO IT.  IT COST ISPS A BUNDLE IN SUPPORT!

Yep, this is a convenience feature....  It saves money and time.

Comment 8

[Ben Bucksch (:BenB)]

wsimpson,

you *still* fail to define, what exactly you want in this bug. I am tempted to
just mark it INVALID, but instead, I'll try to do the work for you:

* In prefs dialog, global View As Plaintext pref (bug 30888).
* In menu or toolbar, item/button for View As Plaintext for the
  current message only.
* Switch default to View As plaintext.

Is it that what you want?


> Since it's not yet implemented, it's not a duplicate.  QED.

You have not yet sufficiently defined what "it" is.

Don't throw around mathematical terms, if you fail to deliver mathematical
precision in your argumentation.

> It's not good enough to look at the source _after_ it has destroyed your
> machine

For security, I suggested bug 30888, which does provide a global pref to disable
HTML viewing.

> Likewise, this is a convenience feature.

The problem with this "convience feature" is that it's not convient. Users don't
want to push a button to view the mail the way it has been composed, just for
security reasons. If users care about security at all, they want it to "just
work", they don't want it to cause more work for them, like pushing a button to
view a mail with formatting.


Netscape is not going to switch the default to plaintext (which is what you
suggest, as I understood you) and let users enable HTML on a per-message basis,
because, as mentioned elsewhere, they are pushing HTML mail.
Beonex might switch the default to plaintext anyway.
So, whom are you arguing with?

> It's needed to make HTML useable.

No, it is not. There are other approaches to make HTML more secure. E.g. bug
108153. There, you could display HTML formatting without security risk (apart
from the normal potential buffer overflows).

Comment 9

[Ben Bucksch (:BenB)]

No answer. INVALID.