Bug 84128 - Need user-visible message when CheckLoadURI fails (eg, for links to file: urls)
 Summary: Need user-visible message when CheckLoadURI fails (eg, for links to file: urls)
 Status: NEW This is NOT about enabling file: URLs... helpwanted, relnote SeaMonkey Client Software UI Design (show other bugs) Trunk All All -- normal --- Nobody; OK to take it and work on it file:/// (view as bug list) errorpages 220711 135830 clu 70871 101207 file:// 249603 Show dependency tree / graph

Reported: 2001-06-05 05:33 PDT by Brad Garcia
Modified: 2016-07-19 10:57 PDT (History)
124 users (show)
asa: blocking1.8b-
harshal: in‑testsuite?
kairo: blocking‑seamonkey1.0a-
kairo: blocking‑seamonkey1.0.10-
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---

Attachments
LAN link not supported popup (14.81 KB, image/jpeg)
2002-01-22 08:19 PST, Steven E. Newton
no flags Details
Mozilla 1.3 (48.65 KB, image/jpeg)
2003-03-18 05:49 PST, Petr Franta
no flags Details
This is a bogus attachment -- how do you submit a comment on a bug without a file attachment? (4 bytes, text/plain)
2003-08-22 11:46 PDT, Scott Borisch
no flags Details
Dialog of proposed patch v0.2 (12.84 KB, image/jpeg)
2003-09-29 14:47 PDT, Ian Neal
no flags Details
Proposed patch v0.2 (6.64 KB, patch)
2003-09-29 14:56 PDT, Ian Neal
bzbarsky: review-
Details | Diff | Splinter Review
Patch v0.3 - dialog should only appear from a user generated event (9.27 KB, patch)
2003-10-29 16:31 PST, Ian Neal
no flags Details | Diff | Splinter Review
Patch (2.63 KB, patch)
2004-01-10 23:20 PST, Boris Zbarsky [:bz] (work week until 5/26) (if a patch has no decent message, automatic r-)
no flags Details | Diff | Splinter Review
Patch v0.4 - attempt at event dispatching (19.93 KB, patch)
2004-02-10 06:19 PST, Ian Neal
no flags Details | Diff | Splinter Review

 Brad Garcia 2001-06-05 05:33:51 PDT 2001-06-03-21 linux x86, but should be applicable on any platform. When clicking on a 'file:' link on a page that does not have a 'file:' URL itself, the new page does not get loaded. Currently, the following message is printed in the Javascript console: The link to file:///... was blocked by the security manager. Remote content may not link to local content. However, normal users are not going to open the javascript console to look for error messages. *Especially* when the pages in question don't even contain javascript! (aside - why is it called a javascript console? Shouldn't it be called a "debugging" console?) When a user clicks on such a link, the user must be told why the action failed, otherwise the user is confused. I would suggest one of the following remedies: 1. Print a message in the status bar at the bottom of the page. But some users might miss this, since the status bar seems to be pretty useless anymore for giving accurate status. 2. Load a new page that gives the error message. This is less likely to be missed by the user. It's similar to clicking on a rotted link and getting a "404" page. This could also give more detailed information about the problem, and ways to work around it. This is related to bug 40538. Also, a solution to bug 47128 might also prove to be a solution to this problem. Boris Zbarsky [:bz] (work week until 5/26) (if a patch has no decent message, automatic r-) 2001-06-05 06:21:30 PDT Over to user interface design. We need a spec for the UI here. Mitchell Stoltz (not reading bugmail) 2001-06-05 13:50:21 PDT The error message isn't meant for end users, it's meant for developers. In that sense, it's kind of like an uncaught JS exception, which also shows up only in the JS console. If site developers see this message, they should correct their pages so the error doesn't happen and then it need never be a problem for the user. Brad Garcia 2001-06-06 10:55:45 PDT > The error message isn't meant for end users, it's meant for developers. Of course. But the point of this bug report is that the users need a message too. > In that sense, it's kind of like an uncaught JS exception, which also > shows up only in the JS console. But this doesn't help the user figure out what happened. > If site developers see this message, they should correct their > pages so the error doesn't happen and then it need never be a > problem for the user. Wrong. This does NOT mean that there is something wrong with a site. This is a security feature that mozilla implements that causes it to simply ignore the user when the user clicks on a perfectly-legitimate hyperlink. Neither Netscape nor Internet Explorer implement this restriction. I understand the rationale for having this feature, but a user should be given an indication of why the browser is ignoring her when she clicks on a hyperlink. The current behavior is bad.  Mitchell Stoltz (not reading bugmail) 2001-06-06 13:01:17 PDT A link to local content is not "perfectly legitimate." I've given my .02 on this issue, but if someone wants to implement yet another user dialog, that's fine, I won't object. benc 2001-06-19 10:04:19 PDT To clarify, this is would be "fix" to what some people consider is the incorrect behavior in bug 40538. Jesse Ruderman 2001-06-19 23:25:49 PDT I think fixing bug 47128 is the best way to fix this bug. (I'd mark this bug as a dependency, not a dup, in case there's a problem with the CheckLoadURI message not showing up because it's shown on the JS console as a message rather than an error or warning.) Brad Garcia 2001-06-20 03:20:40 PDT Marking as dependent on 47128 Matthew Paul Thomas 2001-06-26 10:10:11 PDT No, bug 47128 is for script errors, and (as Brad already said) this isn't a script error. It's a you-can't-go-there error. We don't consider an easily missable status bar message to be sufficient for any other you-can't-go-there errors, and it's not sufficient for this error either. Ideally, this is bug 28586 material; but that bug doesn't look like it'll be fixed any time soon. An alert would be better than nothing (which is what we effectively have now), *provided that* the page author including half a dozen s didn't result in half a dozen alerts. So, what's the story here? Can we have different treatement for than we do for hum? If not, why not? Jesse Ruderman 2001-07-02 11:39:18 PDT *** Bug 88727 has been marked as a duplicate of this bug. *** benc 2001-07-17 08:43:43 PDT *** Bug 90902 has been marked as a duplicate of this bug. *** benc 2001-07-20 08:32:29 PDT +mostfreq - starting to get more dupes, which are lost to networking:file. Christopher Aillon (sabbatical, not receiving bugmail) 2001-07-23 07:09:31 PDT *** Bug 91164 has been marked as a duplicate of this bug. *** Mitchell Stoltz (not reading bugmail) 2001-08-10 11:04:57 PDT *** Bug 93761 has been marked as a duplicate of this bug. *** Christopher Aillon (sabbatical, not receiving bugmail) 2001-09-10 02:18:35 PDT *** Bug 99036 has been marked as a duplicate of this bug. *** vance 2001-09-10 02:30:39 PDT  I've got internal pages which are compilations of links to local content. If some feel this is a security problem, pop up a confirmation dialog to make sure the user understands. Totally ruling this out is anoying. timeless 2001-09-20 00:26:34 PDT *** Bug 100485 has been marked as a duplicate of this bug. *** Matthias Versen [:Matti] 2001-09-22 17:19:13 PDT *** Bug 101146 has been marked as a duplicate of this bug. *** Kurt Swanson 2001-09-22 19:06:37 PDT I fail to see how this is a security issue. If I choose to click on a link that goes to my local site, who is this going to hurt, and how? The referring page's server can't do anything with this, nor even be aware that the user has selected the link. Let's even assume that the malicious web site has placed a file on my local machine (somehow), and tricks me into accessing it through a file: link. What damage could mozilla do by loading this file? In any case, this needs to be some sort of user setting. There are a myriad of useful things one could do with file links. (I'm writing here because I'm unable to do one of them...) Kurt Swanson 2001-09-22 19:08:31 PDT P.S. Note that the handling of file: redirects is also poor--partially parsed server redirection html. Boris Zbarsky [:bz] (work week until 5/26) (if a patch has no decent message, automatic r-) 2001-09-22 19:41:52 PDT > The referring page's server can't do anything with this Example. Site http://foo has an link. It detects that the image load succeeds (the onload event for the image is fired). This tells that site that you have a file with that name on your hard drive. The JS sets a cookie to that effect. > What damage could mozilla do by loading this file? Depends on whether you have a helper set up to automatically handle files of that type and how buggy that helper is... In the worst case, there are not-too-difficult scenarios that allow an attacker to execute arbitrary code on your machine this way: 1) Place some code somewhere (eg a browser cache) 2) Point to that file with a file:// url 3) Exploit that fact that file:// urls have a lot more rights than http:// urls > In any case, this needs to be some sort of user setting. It is. :) user_pref("security.checkloaduri", false); will disable this check.  benc 2001-09-22 23:25:24 PDT kurt: lets get a new bug on the redirect issue. Kurt Swanson 2001-09-23 09:15:31 PDT Redirect bug is bug 101207. benc 2001-09-24 11:00:39 PDT RELNOTE for 0.9.4: use text from bug 40538 + "Currently, the errors are visible only in the javascript console." Mitchell Stoltz (not reading bugmail) 2001-09-24 12:52:03 PDT I think I should put up a documentation page explaining why this restriction is there, and how to turn it off. I seem to be getting the same complaints about this over and over, and explaining it over and over. Brad Garcia 2001-09-24 13:21:29 PDT I think creating the document explaining the restriction is a good idea. Your best bet would be to have mozilla pop up a page containing this document whenever a user attempts to click on one of these restricted links. Then this bug could be closed. :^) Brad Garcia 2001-09-25 05:06:41 PDT I see all sorts of neat examples of how local file URLs can be exploited in image tags, etc. What I would like to know is, if a web page contains a simple hyperlink, with no javascript event handlers, like so: Local Linux Documentation And a user clicks on it, what security issues are there? And if there aren't any, then why can't exceptions be made to the security restrictions for such safe uses? Mitchell Stoltz (not reading bugmail) 2001-09-25 10:41:15 PDT *** Bug 101207 has been marked as a duplicate of this bug. *** Mitchell Stoltz (not reading bugmail) 2001-09-25 10:56:35 PDT Brad, look at bug 101207. I mentioned some relevant security concerns there. I'm going to write them all up on a webpage soon so that people can either tell me I'm being too paranoid or stop pestering me about this issue. Brad Garcia 2001-09-25 11:26:30 PDT I can understand why allowing a plain hyperlink to things like file:///dev/* are bad. But this is different from the security issue, for two reasons: 1) If the user clicks on this plain-old hyperlink, there is no data being sent back to any server, so there is no security concern. 2) These links are JUST AS BAD if the page containing them is a "file:" URL as they are when the page is an "http:" URL. So these sorts of links should be rejected regardless of the page from which they've come. Currently, they are not. They probably should be. Kurt Swanson 2001-09-25 11:28:27 PDT Mitchell, in general response, and specifically to your last comment in bug 101207, I commend you for your attention to these security concerns. I agree with them--they are all indeed valid. Please try not to be offended (or exasperated) when others fail to anticpate them. The question is, however, to what extent mozilla should go in addressing wider security concerns. For example, you mention how file:///C:/con/con will crash some Microsoft systems, and how file:///dev/... on unix systems could theoretically cause damage. For the latter, I question this, at least on Linux and Solaris. For both, though, I would suggest that the stringent CheckLoadURI policy would not be sufficient to inhibit such activity. One could receive a malicious html page in email "save this to disk...", etc. In this case, the only safe thing would be to disable file:// entirely... In essence, I would argue that such exploits are the fallacy of the OS, not the browser, which merely acts as a conduit. I don't think Mozilla need be a tool to correct the problems of the OS. This would be tantamount to expecting sendmail to scan for virii, hate mail, etc... In any case, the reason, which I'm sure you're aware of, for the numerous bug reports on this issue, is that the user is not expecting any such security action (other browsers don't block file://), no information is presented when this happens, and no preferences setting addresses this. I don't think putting up a web page describing the situation will suffice. Thus, I suggest that mozilla be augmented to pop up a dialog when such an attempt is made, stating, "This page is attempting to access a local file which is potentially dangerous. Do you wish to allow access to file://...?" With buttong stating "Yes, just this one time", "Yes, and for all future attempts", "Not this time", and "No never". In this manner the situation is clear, as are the options, which allow for a permanence. This should effectively deal with everybody's concerns. beanladen 2001-09-25 13:04:52 PDT I think Kurt's solution will make us all happy. The dialog could even have a 'show details' button with further clarifications why file:// is potentially dangerous. Although, for the 'javascript switched on' case, the warning should be a bit stronger. benc 2001-09-26 09:38:42 PDT + nsenterprise - if you read all the dupes, you can see this affects corporate users b/c of frontpage and corporate groups that like to publish file URLs over HTTP index files. Mitchell Stoltz (not reading bugmail) 2001-09-26 11:32:27 PDT It was for enterprises that I added the "security.checkloaduri" pref. Enterprises can turn the check off. I'm re-evaluating this whole issue and I will post a more detailed response in a few days. In the meantime, read my lips - no new dialogs. :) Jesse Ruderman 2001-09-29 16:24:27 PDT See also bug 86486, "URL: Invalid protocols in HREF links fail silently". Hong Kwon 2001-10-09 19:05:43 PDT marking nsenterprise-; will be reevaluated for nsenterprise in future release.  Boris Zbarsky [:bz] (work week until 5/26) (if a patch has no decent message, automatic r-) 2001-10-15 15:01:40 PDT *** Bug 104842 has been marked as a duplicate of this bug. *** Jesse Ruderman 2001-11-05 01:27:28 PST *** Bug 108490 has been marked as a duplicate of this bug. *** Boris Zbarsky [:bz] (work week until 5/26) (if a patch has no decent message, automatic r-) 2001-12-26 21:20:21 PST *** Bug 117006 has been marked as a duplicate of this bug. *** Martin Turon 2001-12-27 14:17:37 PST Gents, I understand the concern for security, but to disable the ability to view local files from Mozilla makes it feel like a broken browser straight out of the box. Half the links on any decent intranet page won't work if local file links simply do nothing. I think viewing of local files should be made a part of the default feature set ASAP!!! If you want to add an option in Security to turn this off or post a warning that is fine, but as it stands I have to load Netscape to view internal documents under Linux and that sucks... I'm very happy with Mozilla in everyway except this bug. I know this has got to be easy to fix why has nothing been done for 6 months?!?!  Steven E. Newton 2002-01-22 08:18:24 PST The popup error message is clear, but the wording could still be tweaked, especially for Mozilla. I've attached a screen shot of the dialog. The message is "Netscape does not support linking directly to files on the LAN. You'll need to use IE or File Explorer to navigate." Steven E. Newton 2002-01-22 08:19:41 PST Created attachment 65999 [details] LAN link not supported popup Vance Haemmerle 2002-01-22 08:23:22 PST "You'll need to use IE or File Explorer to navigate." Um... not too helpful if you're on something other than Windows. Ever hear of something called "Linux" or "VMS" or "Unix"?  Kurt Swanson 2002-01-22 09:16:45 PST Also, my "file://" file isn't on any "LAN," it's on my local hard drive... I suggest: "Security violation: links to local files currently disabled." beanladen 2002-01-22 10:03:03 PST I think we really want the users to stay with Mozilla. So a hint which prefs variable to set to to enable this unsecure feature (with a short explanation) would be very helpful. I don't think we have to redirect the users to another browser ! See comment #43 : "Security violation: links to local files currently disabled. To enable this feature, you can set the variable security.checkloadURI in your prefs.js. But be aware that you open a possible security hole, esp. in connection with javascript!"  benc 2002-01-22 11:50:21 PST I think we should have more of these 'more info' buttons like we do in prefs. Then people can customize the the detailed message w/ a URL. mpt: any suggetsions for some default text? Gilles Durys 2002-02-18 07:46:12 PST *** Bug 126183 has been marked as a duplicate of this bug. *** neil@parkwaycc.co.uk 2002-02-20 07:57:38 PST I don't know if this is relevant, but when someone posts a news message using Outlook Stationery it includes a URL which fazes MailNews. Hixie (not reading bugmail) 2002-02-20 08:06:46 PST This should IMHO be fixed via the mechanism for bug 28586. Christopher Aillon (sabbatical, not receiving bugmail) 2002-02-21 00:57:02 PST *** Bug 126935 has been marked as a duplicate of this bug. *** Andreas Huppert 2002-02-21 01:38:50 PST I added the user_pref("security.checkloaduri", false); in my prefs.ini to see if this fixes my problem described in bug 126935. It did not. I still can not go from secure pages to a file:// URL. I also put an image in the secure page that accesses a JPG on my local hard drive. This worked! IMO the effect of the setting should be exactly the opposite. Under no circumstances I want a external web page to be able to access files on my PC. The security holes this creates have been discussed above, and I fully agree to this. But I want to be able to jump to file:// URL's from secure pages. A optional warning dialog would be usefull. If this does not work Mozilla is virtually useless in corporate environments. In a corporate environment, users also surf the web, so the security loophole can not be accepted (except for normal links as mentioned above). I also think that a warning dialog could pop up if a non-file: page uses file: in any way - probably it tries to use a security hole. Andreas Huppert 2002-02-21 01:45:47 PST To make matters worse - the image mentioned in my last posting can also be accessed with user_pref("security.checkloaduri", true); So what we got is all the security loopholes but we still can not use file:// URL's.  Boris Zbarsky [:bz] (work week until 5/26) (if a patch has no decent message, automatic r-) 2002-02-21 01:54:06 PST That would be bug 69070 Boris Zbarsky [:bz] (work week until 5/26) (if a patch has no decent message, automatic r-) 2002-02-26 22:07:09 PST *** Bug 127987 has been marked as a duplicate of this bug. *** Boris Zbarsky [:bz] (work week until 5/26) (if a patch has no decent message, automatic r-) 2002-03-15 01:29:40 PST *** Bug 131119 has been marked as a duplicate of this bug. *** R.K.Aa. 2002-04-20 05:49:11 PDT *** Bug 138769 has been marked as a duplicate of this bug. *** Boris Zbarsky [:bz] (work week until 5/26) (if a patch has no decent message, automatic r-) 2002-05-05 21:57:54 PDT *** Bug 142462 has been marked as a duplicate of this bug. *** Dave 2002-05-07 02:17:46 PDT This is about using BASE HREF tags in local HTML docs, which I do very often. Suppose I include the following tag in a local file: . Mozilla honors clicks on file: links when SOME_URL is also a file: URL; but ignores clicks on file: links when SOME_URL is http:, or other. It is nice that Mozilla tries to treat a local document with a specified base URL as though the document actually lives there. But ignoring my clicks on file: links, just like they would be ignored if the page actually _were_ remote, might be too much (might not be, I am not sure). But wait, there's more: With Mozilla ignores my clicks on file: links (to open them in the same tab/window). But Mozilla currently _allows_ file: links in such documents to be opened in _new_ tabs or _new_ windows (right click, "Open in New Tab/Window"). Mozilla does _not_ allow this for genuine remote documents (that is, for documents that actually reside somewhere other than file:///something, Mozilla ignores my requests to open file: links in a new tab or new window). At the very least, IMHO, this second issue (an inconsistency) should be fixed, and maybe this bug is not the place to discuss it. But following either of the following two humble suggestions would address both of these issues: -Either- (a) Even if a document includes a base href, we still know whether the document itself is local or not. Therefore, in the case of local pages that use the base tag with a remote URL for the HREF attribute (), Mozilla should _honor_ requests to open file: links, whether in the current window/tab, or in new window/tab. -Or- (b) When a local document specifies a BASE HREF, it should be strictly applied. Therefore, in the case of local pages that use the base tag with a remote URL for the HREF attribute (), Mozilla should _ignore_ requests to open file: links, whether in the current window/tab, or in new window/tab. The more I learn, the more I favor option (b), because (1) (as in Brad's Comment 29, reason #2), the file: protocol can be dangerous on its own, regardless of whether the file: resources are included in remote _or_ local documents; and (2) when the nice set of preferences and warnings gets implemented ( :) ) this will cause local documents with remote base href's to be treated in all ways just like actual remote documents. (This is why Kurt's Comment 30 Preferences seem to be best for _all_ cases, but I'm just trying to make sure that my BASE tag cases are considered also). Re: Andreas' Comment 50 and Comment 51 - For https: documents that have non-https: resources to be included (even http:), I think what IE6 does is to give the user a warning pop-up window that says something along the lines of "This document contains both secure and unsecure parts. Would you like to load the unsecure parts as well?" This goes along with the suggestion for adding a preference for these kinds of issues, though. Hopefully the suggestions for preferences can be applied both to including mixed permission level resources in the same document as well as to honoring/ignoring requests for file: links to be opened. They sound like related issues to me. Dave 2002-05-07 02:23:17 PDT In the second part of my comment, "But wait, there's more: With ...", I mean "With in local documents..." Kind of an important thing to omit. benc 2002-05-14 23:15:54 PDT Andreas: please see bug 93787. David: I do not qa this feature, but I have read a lot of the bugs, and I don't think anyone has explored this BASE issue. Please create a new bug. This bug is supposed to be ONLY about the lack of a visible error when checkloadURI fires and cuts off a link click. Gert-Jan Vons 2002-06-12 11:04:14 PDT I just ran into this bug, and this really sounds like a case where security is hindering perfectly legitimate user actions. I think this should be fixed, since users expect simply this to work (and as mentioned, it does in IE and NS). Just telling them this is not supported because Mozilla thinks it is better for the end-user is a good way of getting rid of Mozilla users. I do agree that this can be a security issue, and that it should be configurable. However, the current prefs.js setting has two problems: - if I have to tell our users that they need to mess with their Mozilla prefs.js file, they simply take another browser. And if they do modify prefs.js, it is the IS department that will have to correct the mistakes. - the prefs.js setting is global, so if I set security.checkloaduri to false, our corporate users can access the file:// urls that point to our intranet, but they are also vulnerable for exploits when they surf the internet. I may miss something, but why can't this work like IE does, i.e. never open file:// urls automatically but ask the user if he wants to open or save the file? The user is informed, and has a choice (i.e. opening corporate intranet files, but cancelling other, potentially dangerous file urls). Alternatively, it could be linked to the presence of a http proxy. If there's a http(s) proxy configured one could assume that html pages that have _NOT_ been loaded through the proxy are on the local net, and that file:// urls on such pages are safe. This might work for a lot of corporate users, but does not solve it for everybody... In the end, something like IEs security zones does feel like a decent solution for this problem...  Jesse Ruderman 2002-06-21 10:16:16 PDT *** Bug 153386 has been marked as a duplicate of this bug. *** matt wilkie 2002-06-25 10:35:52 PDT I would like to reiterate what Gert-Jan Vons just said "... this really sounds like a case where security is hindering perfectly legitimate user actions." I was getting ready to recommend Mozilla as one of our intranet acceptable browsers, however I cannot do this as long as file:// links within web pages are disabled by default, or a security risk if enabled. I understand not knowing how to address this until the underlying issues are resolved (eg. security zones) but it really is *bad* that Mozilla is *silent* about it. There needs to be some kind of message or people just think Mozilla is broken. It took me the better part of an hour to wade through the bug database before finding out that broken file:// links are by design. Most people will not put themselves through that effort (witness the high number of duplicate and related bug reports). I personally will keep using Mozilla until somebody closes the middle-click bug 148418 (so please don't), at which point I will reluctantly go back to IE.  benc 2002-06-27 08:07:14 PDT Can we get this soon? The majority of new bug activity in Networking:file is whining about the lack of user feedback on this feature. I've even had to create a bug that is left in file to mop up the duplicates, because the current behavior is so irrational and the causative components are so far of the beaten path nobody that doesn't already understand this behavior knows where to go in bugzilla. +asa & timeless: This should have been release noted, but is not in the 1.0 notes. Can we add an entry please? Werner Teichert 2002-06-27 22:48:24 PDT Please display an error message when one is trying to click on "file://". I discussed this problem under other circumstances as bug 107540 until someone mentioned this security feature and how to stop this. A hint would have saved several days of trying and testing because the system did not show up why it ignored file: ´s. Popup a message and offer the user the possibility to decide by himself if he thinks this is a severe problem. On our intranet we have hundreds of DOC files that should be read by other departments and they are all linked as "file:" on dozens of HTML pages. Do you imagine what the reaction was when neither NETSCAPE nor MOZILLA would display these pages? I nearly changed over to the IE but thanks to the discussion I will stay with MOZILLA.  Andreas Huppert 2002-06-28 03:21:45 PDT I support the suggestion to let the user decide if he wants to open the file: link. Brad Garcia 2002-06-28 03:39:19 PDT This bug seems to be getting more attention now that Mozilla 1.0 has been released. We're already up to 14 votes. This bug describes the minimum amount of work necessary - that is, displaying an error message. There are other bugs dealing with allowing the link to succeed. The correct fix (see bug 47988 and bug 40538 for discussion) is to realize that accessing a file: URL from an http: URL is NOT ALWAYS a security issue. If there are no javascript hooks on the parent page that would allow the web server to detect a file: access, then why shouldn't we simply allow the access to succeed? This will probably solve the problem in the most desirable way for all of the intranet cases described. Please also realize that the developer who normally works in this area has no desire to fix this bug. So if we have any hope of getting this fixed, somebody else will probably have to do it, unless we find someone with great powers of persuasion. I've found that I am not that person. :^) Personally, I've about given up. My links don't work, having to edit a text file to turn off this security feature seems bogus, having to turn off a security feature at all seems bogus, expecting all other users of the intranet to turn it off is bogus, displaying the error message in the javascript console (even though there is no javascript involved here) is bogus, and NOT showing an error message in the browser proper is bogus.  benc 2002-06-28 09:07:45 PDT One of the problems with the visiblity of this bug is that the duplicates have been scattered among three bugs: 1- The "ISSUE" bug I created in File, to try to keep the duplicate reports to a minimum. 2- The original feature bug had many "no error" bug duped into it. 3- This bug. So, on the mostfreq report, it shows up in the lower third. Right now, there are 21 dupes, so it is in the middle of the pack. If someone really feels strongly about this, they could correct the duplicate count by finding the misduplicated bugs and duplicating them to this bug. If you want to volunteer for this duty, contact me by email (please don't run off and start changing a lot of bugs unless you know exactly what you are doing). (At some point, I will do that in File because this is needlessly bloating my component).  Brad Garcia 2002-06-28 12:04:31 PDT Benjamin, Perhaps it would be best then to file one bug to handle all aspects of this, and then dup *all* of the bugs to that one bug? Then we could leave it up to a willing-and-able developer to choose whether they wish to fix this by displaying an error message or by allowing the file access. And certainly, the summary for this bug is pretty cryptic (that's my fault, sorry). Any all-encompassing bug should probably have a simple synopsis like "file URL's fail to open", so that more users can find it. Opinions? Good idea? Bad idea? Matthias Versen [:Matti] 2002-07-17 18:01:46 PDT *** Bug 157885 has been marked as a duplicate of this bug. *** Ian Neal 2002-07-18 05:22:18 PDT I can see where bug 157885 is similar to this, but there is no mention of file:// links within mailnews that I can see of in any comments. People need to be aware it affects mailnews too especially when people have access to shared drives and want to save having multiple copies of documents/spreadsheets by linking to it on a shared area. benc 2002-07-19 08:07:46 PDT The creation of "issue" bugs is not a common practice in bugzilla, possibly done only in Networking:*. The MailNews bugs are managed by a separate group. Boris Zbarsky [:bz] (work week until 5/26) (if a patch has no decent message, automatic r-) 2002-08-07 18:01:30 PDT *** Bug 161468 has been marked as a duplicate of this bug. *** Bruce Webber 2002-08-12 13:11:54 PDT I understand that a file link from within an http page can pose a security risk. However, there are legitimate uses for such links. Where I work (a healthcare system with over 15,000 employees), we have documents on corporate servers, and our intraweb page has links to those documents. (These are not html servers; they are file and print servers.) I don't like the security.checkloaduri solution because it removes all protection, and it can be difficult to implement across the enterprise. I recommend that when a user clicks on a file link from within an http page, a dialog box appears that warns the user, giving the name of the file. The user can click "OK" or click "Cancel". This approach is similar to the other warning dialogs that appear (for example, when a page contains both encrypted and unencrypted data.) Some sort of dialog box is needed. I spent several hours "debugging" this until I found the relavent listings here in Bugzilla. Remember: some of the people using Mozilla are testing the web pages they are developing. Thanks for your consideration.  beanladen 2002-08-12 13:46:09 PDT No, bad idea, sorry. If you are working in a large intranet and have to click on all those dialog boxes for every page to view, you will quickly find yourself working with some better brand of browser. This needs a more general solution, maybe something like the detailed hostlist used for cookies, certificates etc. At least the 'checkloaduri' solution is an acceptable workaround for now, as this will only be activated for about 20-30% of all users.  benc 2002-08-12 23:41:30 PDT This *REALLY* needs to be looked at for the next release. mpt: Did you plan on doing the code for this? If not, can we re-assign? Mark 2002-08-15 04:25:35 PDT This REALLY REALLY needs an option to disable this "security" feature, since it is currently preventing us from converting many people away from IE and Windows to Mozilla and Linux. I could not get the user_pref change to have an effect. It is essential this becomes an option, as it is hindering real work. These HAVE to be made options otherwise people and especially companies which rely on these features will be unable to make the change -- do you want people to use free software or not?! benc 2002-08-15 09:30:17 PDT what line did you add to prefs.js? you shouuld use about:config to verify your results, and you use use all lower-case (someone spelled URI w/ uppercase somewhere and it stuck, but the prefs system is caps sensitive). Boris Zbarsky [:bz] (work week until 5/26) (if a patch has no decent message, automatic r-) 2002-08-15 15:23:37 PDT I don't care one whit whether people use free software. I about not exposing users of software I write to security exploits. It has been made abundantly clear that IE does _not_ care about this. Should we emulate IE in this irresponsible attitude?  Gert-Jan Vons 2002-08-16 00:20:08 PDT This is not about emulating IE's insecure behavior, this is about not being able to use functionality in environments considered secure. I like Mozilla's security approach, I don't want file links to work for any internet site, but I do want them for corporate websites, for my home web server, and so on. And that's exactly why the prefs.js setting is not a solution, since enabling it makes file urls work for *any* website. As long as Mozilla doesn't sport something similar to IE's intranet/internet/... zones, I'd be happy with an option (not in prefs.js but in the preferences dialog, users should be able to find it!) that enables file urls for sites that are excluded from the http proxy for example. Not an ideal solution, but better than nothing IMHO.  beanladen 2002-08-16 00:25:43 PDT Not a bad a idea ! But I would still vote for the explicit 'secure sites' list, as the necessary infrastructure for such lists is already there (see cookies, images, etc.). Maybe with the non-proxy sites included as default entries ? Mark 2002-08-16 02:31:06 PDT So this is a 'security feature' is it?!?!? Next you'll be saying that Mozilla crashing is a 'security feature' to stop peoples children looking at pr0n sites. For goodness sakes you can only hold peoples hands so much and if they choose to ignore a warning box then the results are down to them. Prehaps a better way to approach it would to be have a warning with specific approval list or an 'intranet zone' as suggested.  benc 2002-08-16 11:46:49 PDT Gert: file a bug that describes what you want. (For example, I suggested bug 93787 as one possible solution). You should be aware that there are some problems with the way internet zones are designed as well, so I don't think you'd ever see anyone implement exactly what MS has done. Mark: please, avoid comments that sound idiotic. I could, for example suggest that we reduce airport security because I think it wastes my time... I'd like to emphasize that people should be doing as much background reading as possible before commenting on things like architecture and security. Use some common sense, if mozilla broke something that is commonly used, and there are more than 25 comments in a bug, someone probably told us. On the other hand, I've been finding two things that are interesting about this bug: 1- Very few people know that you are not supposed to use file URL's to publish content. RFC 1738: The file URL scheme is unusual in that it does not specify an Internet protocol or access method for such files; as such, its utility in network protocols between hosts is limited. RFC 1630: There is clearly a danger of confusion that a link made to a local file should be followed by someone on a different system, with unexpected and possibly harmful results. Therefore, the convention is that even a "file" URL is provided with a host part. This allows a client on another system to know that it cannot access the file system, or perhaps to use some other local mecahnism to access the file. The suggestion that nfs: and afs: be created a separate protocol schemes in the original RFC suggests that file was meant for locally mounted files only. 2- Even fewer people currently understand enough about the security issues I know I don't, and I get asked to provide networking expertise on security issues pretty regularly. Anyone not familiar with how this security exploit works should read up before commenting. The fact is that Mozilla has a stated goal of making security a very high priority. I agree that this feature was not implemented with much consideration, but that can be fixed by focusing on finding solutions. At this point, I think the consensus is that hiding the error message in the javascript console is too deeply burried. Lots of people live and die by publishing file URL's, I don't know why, but it is part of the computing environments in many places. (They also publish a lot of completely incorrect file URLs, you can look in Networking:File for that). My personal experience is that hacking the pref, esp. in Mac OS, is really time-consuming and error prone. It would also leave you badly exposed to anyone who wanted to server you a page that could read your local files. So, what we need are two things: 1- A code fix in this bug. 2- Other bugs, that are filed as RFE's for other solutions (maybe allow file URLs that are remotely mounted, allow file URL's on pages that are in your default domain, etc.) benc 2002-08-19 13:14:23 PDT per asa - going to xp-apps. benc 2002-08-26 12:46:16 PDT *** Bug 164653 has been marked as a duplicate of this bug. *** Matthias Versen [:Matti] 2002-09-04 08:46:48 PDT *** Bug 166582 has been marked as a duplicate of this bug. *** Ian Neal 2002-09-04 08:51:28 PDT *** Bug 166482 has been marked as a duplicate of this bug. *** Christopher Aillon (sabbatical, not receiving bugmail) 2002-09-10 16:46:48 PDT *** Bug 167806 has been marked as a duplicate of this bug. *** Gordon Schumacher 2002-09-11 09:30:46 PDT Having just stumbled onto this bug the hard way (my searches for dupes didn't show up) I thought I'd add my US.02... Yes, this needs to get fixed, and soon! Now that Mozilla's stable, there's a bunch of people at my company (and a fairly large one, at that) who have been Making The Switch. But this is kind of a showstopper for us. I understand now the security implications of file links - and they make good sense. However, the fact of life is that I don't have the political pull to kick the people who run our Intranet IIS (gack) server into providing us server-visible links to the entire network storage hierarchy. Thus, as merely a lowly webmaster for part of my department, I am forced to do things like: <A HREF="file://///BIGSERVER/share/my_app">Browse MyApp distribution</A> Yuck... but my other choice is to mirror the entire application distribution hierarchy onto the webserver - double yuck. So, I've heard two solutions to this which - between the two - sound like gold to me. 1) Allow a list of websites, vaguely similar to IE's zones, that can have escalated privileges. Yeah, something could theoretically spoof the site... perhaps allow for a IP/mask to be checked against? 2) Pop up a dialog when the user clicks on a file: link. The link you have clicked on is directed at a local file. This is a security risk, and may allow harmful code to be executed. Do you want to open this link? Yes/No/Always for this link/Always for this site/Never for this site/Never Those two options could possibly be combined into a single structure of sites and/or links which are allowed as file: links. The other route that should perhaps be pursued is an Evangelism path... spreading the word, perhaps through articles in webmaster publications, that file: links are bad - and possible solutions to avoid them. This could perhaps be carried so far as that people skilled at writing CGI and ASP could write scripts that would fetch an approved list of files and directories from the local file schema and (in the case of files) present them for download, and (in the case of directories) present them as a list of HTML. (I am unfortunately not that person. I am slowly learning Perl in my freetime but I am not a CGI programmer... I do C++ right now.) In any case, I've rambled enough, but in summary: 1) If we want Mozilla to have a chance of displacing IE, this needs to be fixed. 2) Shooting the users in the foot is bad. Giving them a gun isn't, as long as you explain that they could shoot themselves in the foot if they're not careful. 3) Yet Another Dialog Box isn't a bad thing, dammit. Users need feedback... if we were writing a developer-only tool... well, things would be different. beanladen 2002-09-11 10:52:36 PDT I just checked the release notes 1.1, still no hint on this problem there. Can somebody quickly put a note under the 'Security' chapter that file links do not work as expected ? That would at least save people a lot pain (see the comment above). TIA. Ere Maijala (slow) 2002-09-14 09:42:50 PDT *** Bug 168669 has been marked as a duplicate of this bug. *** beanladen 2002-09-18 14:27:26 PDT I'm not a native speaker, but here's my try: " Because of possible exploits, 'file:///' links to local resources from within a 'http://' page are blocked by default. Currently, there is no user visible message (bug 84128). To enable these links, set the variable "security.checkloaduri" to false in the user.js file." Ian Neal 2002-09-19 16:15:16 PDT That seems to cover the browser side of things but there also needs to be mention of it not working in emails too. beanladen 2002-09-19 16:30:24 PDT Oh yes, here's the revised note: " Because of possible exploits, 'file:///' links to local resources from within a 'http://' page or a mail message are blocked by default. Currently, there is no user visible message (bug 84128). To enable these links, set the variable "security.checkloaduri" to false in the user.js file." Mark 2002-09-20 01:19:11 PDT Jo end user will want a tick box somewhere in preferances not to go hacking through a file that they may not know the whereabouts of. Besdies which you shouldn't need to be able to hack at a prefs file to use a browser. Voting for a simple tick box under prefs/privacy & security.  Ere Maijala (slow) 2002-09-20 01:24:14 PDT I'd rather vote for a very smart system to distinguish a user clicking on an url from other ways of loading it and allowing that specific case (the same way you can type the url to address bar). Ian Neal 2002-09-20 09:01:59 PDT Having a tick box is a short term answer but I'd like to see that replaced in the long term by a graded access as per RFE bug 135830 Ron Yorston 2002-10-18 02:32:44 PDT I have no problem with the security issue underlying this bug. It's entirely reasonable that file: URLs shouldn't be accessible from pages loaded from http: URLs. I'd written a simple server that searches an index of documentation. As an option it allowed the server to return file: URLs. When I tested the server with Mozilla it didn't work as expected. As a result I've seen the error of my ways and have changed the server so that it doesn't return file: URLs. And it's all the better for it. However, that isn't what this bug report is about. This report is about the lack of any sensible feedback when the user clicks on an impermissible link. I spent something like two hours trying to figure out why my server wasn't working as I'd expected, with detours into the proper handling of 301 and 307 HTTP responses (bug 48202) and the inconsistent behaviour of file: URLs with the middle mouse button (bug 148418). It was really annoying to waste two hours of my life tracking down the problem only to find that it's a well known issue that could easily have been remedied months ago with a dialog. I am angry that the Mozilla developers should have so little respect for the time of others that they haven't implemented this simple fix. beanladen 2002-10-18 10:27:05 PDT And still no word in the release notes: see comments #89, #91-93.... Samir Gehani 2002-10-24 14:29:25 PDT Nav triage team: nsbeta1- charles allen 2002-11-27 14:52:30 PST 1: users should be warned when they attempt to do dangerous things, not ignored. 2: this needs to be in the release notes. PLEASE! if you want to be able to use file:// from an http: served page in an intranet setting like I do, vote for bug#93787 Norman Gray 2002-11-29 09:25:01 PST (a) Whatever one feels about the security issue, there really has to be _some_ sort of feedback in this case. It's completely unreasonable for mozilla to block the link silently, not least because it wastes so many people's time working out why it's done that, eventually finding this bug report, and working their way to the bottom. (b) Surely the resolution is more subtle than just file: URLs are evil, use http: URLs only'. As a concrete example, the case where this bit me was using a little wiki on an intranet to keep track of, for example, different documents and trees on the intranet -- a flexible and locally-sharable bookmarks page, in other words. Now I _could_ work out a way of referring to the local shared disks via http, but (i) this would make this wiki solution effectively unusable, and more importantly (ii) if I make a mistake implementing that, I've accidentally exposed our whole shared filestore to the public internet. In other words, working around this security feature means that I'd have to worry about a whole new class of security problems, and I would have effectively _lowered_ the security of the whole setup. The only realistic way of dealing with this feature is to disable it entirely, which is not a win for me, since it means I'm just as exposed to the real security problem as I would be if the feature didn't exist.  Jean-Francois Ducarroz 2002-12-04 14:41:45 PST Blake, ny status on this bug? Sascha Carlin 2002-12-05 03:18:24 PST Perfect solution would be enabling the user to configure a list of domains from where requests to file:// are allowed. charles allen 2002-12-05 10:13:52 PST regarding comment #103: That's what bug#93787 is about. If that's what you want to do, please go vote for it as well. This bug is about mozilla silently ignoring the FILE:\\ requests rather than being noisy about it, as I would prefer.  Mitchell Stoltz (not reading bugmail) 2002-12-05 10:39:00 PST Just FYI, I may soon re-enable links to file: URLs if I can figure out how do do it without opening any security holes. Matthias Versen [:Matti] 2002-12-15 07:29:14 PST *** Bug 185468 has been marked as a duplicate of this bug. *** R.K.Aa. 2002-12-19 22:03:47 PST *** Bug 186207 has been marked as a duplicate of this bug. *** bradmcc 2002-12-20 01:09:28 PST I am impressed that *any* problem that has generated this much controversy merits some kind of attention. For instance, I would not have had my difficulty if there had been an error message saying "By default you are not allowed to follow file:/// links in pages loaded from the network because the results can be unpredictable. There is a parameter in all.js [name it here] to change trhis if you need to." I agree with another poster in this comment chain: No matter what a purist may think, why turn people away from using Mozilla because of something they need in this world even if in a better world they would not need to do it?  benc 2002-12-20 02:20:24 PST keyword update. Blake + Paul, this bug is pretty high up on the duplicate list, as well as not even being correctly marked a dupe because of problems with writing the correct bug. Can anything be done to fix this for the next big release? Mitchell Stoltz (not reading bugmail) 2002-12-23 08:29:49 PST Ben, I'm going to try and relax the CheckLoadURI policy if possible so that a dialog is not needed. I stand by my assertion that adding a dialog is not the right thing to do. charles allen 2002-12-23 09:09:32 PST Ok, no new dialogs. How about a message on the status bar at the bottom of the window? "Security restriction: file:// not allowed from this domain." Hans Deragon 2002-12-23 11:31:01 PST As a user, I would rather get a dialog box than a message error on the bottom status bar, unless you make the status bar flash red for 2 seconds, to get the attention of the user. I rarely check the status bar at the bottom and if I click on a link that does nothing, I will not necessarly think of checking the status bar. We users are simply not used to look at the status bar, since 99% of the time we never have to look at it. Actually, until I have read the last comment, I did not know it was called the status bar. BTW, flashing the status bar red for 2-3 seconds with a 0.5s interval is a good way to get the attention of the user. I worked on GUIs implementing this and got positive feedback for such a feature. Users see right away the error whitout the dialog on which a button needs to be pressed and hide the main window. benc 2003-01-06 14:35:40 PST *** Bug 170654 has been marked as a duplicate of this bug. *** Matthias Versen [:Matti] 2003-01-07 15:31:09 PST *** Bug 188107 has been marked as a duplicate of this bug. *** Volker Kleinschmidt 2003-02-05 19:29:07 PST Another functionality not mentioned before that is blocked by this bug: in online education it is not uncommon to send out CDROMs with content, and to link to materials on such CDs via file:/// URLs (with dynamically set drive letter/name). So once again users of Mozilla-based browsers don't have useful functionality that users of other browsers have. Does anyone really think this is a good thing? Boris said he doesn't care, but if you guys don't care whether your users are happy, then why on earth are you doing this mammoth project? Just for yourself? Besides, there is always so much talk about standards compliance within Mozilla. Clicking on a file:/// link is supposed to open that file, if the link is valid. That's the standard. Where is Mozilla compatible with that? Instead, Mozilla just sits there, doing nothing. A real quality user experience. Alt-F4 or Command-Q would be the most common user response.  Boris Zbarsky [:bz] (work week until 5/26) (if a patch has no decent message, automatic r-) 2003-02-05 19:37:47 PST I said I don't care whether people use free software in general. This is not the same as not caring whether people use Mozilla. But yes, I, personally, work on this project just because I sorta feel like it. ;) Mitch _is_ working on fixing this bug. It's just taking a while because the problem of not opening up security holes is a little delicate, ok? Mitchell Stoltz (not reading bugmail) 2003-02-06 12:51:34 PST If I had a nickel for every "Mozilla would be great if it weren't for bug XYZ" comment I have to read, I wouldn't have to work here :) Seriously though, I am looking for a way to remove this restriction on file: URLs without popping up yet another dialog. Trust me, you don't wand another dialog. Links to file: URLs from non-file pages ought to work - the trick is that we want to disallow scripts from linking to file: URLs, and it's hard to distinguish link clicks from script-initiated loads sometimes. Brad Garcia 2003-02-07 12:51:42 PST > Seriously though, I am looking for a way to remove this restriction on file: > URLs without popping up yet another dialog. Mitchell, you just made my day! I think that would be the perfect solution to this problem. > the trick is > that we want to disallow scripts from linking to file: URLs, and it's hard to > distinguish link clicks from script-initiated loads sometimes. Understandable. I wish you the best of luck! I'll be downloading the nightly the minute you get a fix in. :-) Thanks again! Boris Zbarsky [:bz] (work week until 5/26) (if a patch has no decent message, automatic r-) 2003-02-18 12:05:42 PST *** Bug 193901 has been marked as a duplicate of this bug. *** David Buehler 2003-02-18 14:03:56 PST One source of my confusion about this bug (sorry for the duplicate bug filing) was that when I right-click on a file:// link embedded in an http:// page and select "properties"... the resulting "Element Properties" dialog that gets popped up says, "Link Properties [...] Will open in: Same window"... It might be nice if the "Element Properties" dialog would indicate that in fact, the link will NOT be opened in the Same Window!  Neil Marshall 2003-02-18 14:16:53 PST David, the bug you're looking for is Bug 91108 Greg Lindauer 2003-02-25 10:09:17 PST As with many earlier comments, I just ran into this bug for the first time. I have the same problem as comment #101: The wiki I am setting up doesn't work well with the Mozilla client because it can't use file: links, and the only alternative seems to be opening a huge possible security hole by opening the entire intranet through the web server. (Please let me know if there is an alternative!) However, I understand the seriousness of the issue, and appreciate that the Mozilla Developers are thinking so far ahead of security issues as to foresee this and take a stand on it 1.5 years ago. If there is any way to get the file: to work safely it would be a great boon to wiki users. Thanks! Ian Neal 2003-03-13 14:45:18 PST There is actually a bug/workaround for getting the linked file in mail messages which have a file:// link in to open. Make sure you have no browser windows open. Right click on file:// link and select open in new tab New browser window opens and file in link opens in correct application. Logged this as bug 197252 Petr Franta 2003-03-18 05:49:55 PST Created attachment 117595 [details] Mozilla 1.3 Petr Franta 2003-03-18 06:07:27 PST I have Windows XP SP1, Procesor Intel 2533 MHz, 750 MB RAM. If I use Mozilla v. 1.2.1 it's all OK. Boris Zbarsky [:bz] (work week until 5/26) (if a patch has no decent message, automatic r-) 2003-03-18 06:52:32 PST *** Bug 197092 has been marked as a duplicate of this bug. *** benc 2003-03-27 12:59:45 PST *** Bug 199295 has been marked as a duplicate of this bug. *** Boris Zbarsky [:bz] (work week until 5/26) (if a patch has no decent message, automatic r-) 2003-03-31 21:53:42 PST *** Bug 200051 has been marked as a duplicate of this bug. *** Darin Fisher 2003-04-16 17:00:35 PDT *** Bug 202262 has been marked as a duplicate of this bug. *** benc 2003-04-23 00:24:54 PDT *** Bug 191895 has been marked as a duplicate of this bug. *** benc 2003-04-23 01:19:19 PDT *** Bug 151253 has been marked as a duplicate of this bug. *** benc 2003-04-25 15:56:51 PDT *** Bug 169682 has been marked as a duplicate of this bug. *** Matthias Versen [:Matti] 2003-04-25 19:30:05 PDT *** Bug 203416 has been marked as a duplicate of this bug. *** Boris Zbarsky [:bz] (work week until 5/26) (if a patch has no decent message, automatic r-) 2003-04-26 08:30:46 PDT *** Bug 203472 has been marked as a duplicate of this bug. *** Michael 2003-05-19 12:07:08 PDT As per the comments below, I added the line user_pref("security.checkloaduri", false); to every .js file I could find with no change in the behavior. I still get the security message in the javascript console, and I cannot open the file. Any further ideas? I am running NS 7.0.2 on various OS's. Thanx! -Michael Josh Birnbaum 2003-05-23 09:06:48 PDT *** Bug 206889 has been marked as a duplicate of this bug. *** Tom Fotherby 2003-07-12 03:49:34 PDT To continue to put the case forward to get this fixed I want to say that this issue is making _thousands_ of people regularly have to resort back to using IE/Netscape. Surely you pity us? The 3 things that seem to effect most people are: 1) CD-roms that self-reference material via file:/// URLs 2) wiki's 3) LAN sites that index files on the LAN (very common where I work). Gunstick 2003-08-13 06:49:47 PDT My idea to distinguish for corporate Intranets between Intranet webpages (file: allowed) and Internet pages (file: not allowed) is to use the proxy settings. Usually, proxy config should be done so that Intranet pages are accessed directly and only external pages go through the proxy. No new dialogs necessary and would work seamlessly in a correctly set up enterprise Intranet. Steve Anderson 2003-08-22 08:53:02 PDT Please, for the love of God, can this be fixed. Mozilla has a perfectly good mechanism for preventing/allowing cookies/pop-ups/everything else from a site; why can't this be applied to file:/// URIs as well? I'm missing work being updated on our corporate Intranet because I refuse to bow down to Billy Gates any more than I have to in this job (I run WinXP but with Mozilla, OpenOffice.org and Abiword instead of the M\$ equivalents) and it's getting frustrating, not just for me but for my boss as well. I hate IE. He will make me go back to it if Mozilla can't handle file:/// URIs (and also as

 Note You need to log in before you can comment on or make changes to this bug.