87758 - Clicking file hyperlink in mail message has no effect

Status: VERIFIED WONTFIX

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Jon Rubin]

Found in 6.1b build on Win98.

If a mail message contains a file hyperlink (such as file:///c:/), clicking on
the hyperlink has no effect.

Comment 1

[Francisco León]

Does it really make sense to have a file hyperlink on a mail message?
Maybe only on the case "hey guy on our lan, the document you were looking is in
your file:///c:/file.txt" 
I dont see the importance on this

Comment 2

[Bradley Baetz (:bbaetz)]

This is a feature, for security reasons - you can't click on a file url from a
web page, either.

mstoltz?

Comment 3

[Francisco León]

So if this is a feature why look any further?
Should we support this? Like i said i dont see the practical use for it

Comment 4

[Jon Rubin]

In a web page, the file path is not highlighted as a hyperlink (just look at my
original comment on this page); in the mail message, the file path is
highlighted as a hyperlink (look at the mail message that was generated from
this report), which would cause users to expect something to happen when they
click on it.  If there is no practical use for a file hyperlink, then it
shouldn't be highlighted as such.

Comment 5

[Jon Rubin]

Just filed bug 88079, which may be related.

Comment 6

[Dvir]

I agree with Jon.
This is a really irritating problem, especially for people who send emails
inside the office, and want to point the recipient to a html / asp / txt file on
a shared drive. This was supported in Netscape 4, where clicking on the link
opens the file in a browser window. I suggest adding a 4xp keyword to this bug.

Comment 7

[Francisco León]

Perhaps we can add something in the code
A simple algorithm that goes like this:

if(sender_is_on_intranet)
file_hyperlinks_executable=true

Comment 8

[Bradley Baetz (:bbaetz)]

You can't know whether the sender is on the intranet. They could just forge the
from address, so you can't use that.

+4xp, although I think our behaviour is better, so +compat

This got onto bugtraq recently (opening the various special device files, and so
on). There is a pref you can set to allow it, but I forget what its called. Jesse?

This bug should be closed as WONTFIX, I think.

Comment 9

[Francisco León]

We can remember if we want to reply to a user by html or by text only
Using that same "philosophy" we could open file links from certain people
The bugtraq issue is bug 69070, more specifically bug 91316

Comment 10

[Bradley Baetz (:bbaetz)]

But I can forge the from address as being from anyone, and then, if you have set
it up so that that person can enable file links, I can trigger the issues in
those bugs. Maybe if we supported signed mail, then that may perhaps be a valid
RFE, although I'm still not convinced.

Comment 11

[Francisco León]

That would be too complicated
Then, how about just ASKING?
Old ns asked you if you wanted to run or open a file, and with what app did you
want to open the file with

Comment 12

[Jesse Ruderman]

To turn off the restriction on web pages linking to file:/// URLs, add this line
to your prefs.js while Mozilla is not running:

user_pref("security.checkloaduri", false);

Comment 13

[Dvir]

Using a pref seems reasonable to me.
But why there should be a difference in behavior between link a: 
http://www.mysite.com/some_virus.exe 
to link b:
file:///g:/my_virus.exe ?

Also, when the file is just an html or a picture nothing malicious can happen.

Comment 14

[Francisco León]

Clicking on a exe file on a webpage triggers downloading
That's ok

Comment 15

[Dvir]

Clicking on an exe in a http url asks whether you want to save the file or
download and automatically execute it.
This question should be asked when the url is file:// . These are just different
network protocols. Behavior should be the same.

Comment 16

[Jesse Ruderman]

Here's on reason why web pages being able to link to local content is dangerous:

Many programs, including some programs that web pages can cause to run (eg media
players and plug-ins), write files to predictable locations on your hard drive.
 If a web page can cause a .html file to be written to one of these locations,
and then links to it, any javascript code in that file will run as local code. 
That isn't as bad as the code having system principal, but it does allow the
javascript to read other files from your hard drive.

There are also DoS attacks on Win98 (MS released a patch a while ago) and on
Linux (which we could work around) that can happen when web pages can link to or
load local files.

Comment 17

[Mitchell Stoltz (not reading bugmail)]

Thanks for the explanation, Jesse. As mentioned above, the workaround is to set
a pref. Marking Wontfix.

Comment 18

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

verified.