Fenix: [Bug] Cannot browse to file:// URIs

[emilio]

Steps to reproduce

• Try to open a file using a file:// URI. I was poking at whether #3864 was a simple matter of tweaking the manifest, I guess not.

Expected behavior

• File is opened, and I can view it.

Actual behavior

• Searches for file://your-file

[kbrosnan]

I doubt we want to fix this. Not having this feature stopped 1558299 from working in Fenix. I am removing that ability from Firefox for Android in 1563422.

[emilio]

Is this different from content:// urls? AIUI content:// urls resolve to file:// urls in Fennec. Will this stop all ability to open external HTML files in Fennec?

[robsmith11]

Why wouldn't you support opening local files on Android as you do on other platforms?

I use it frequently to play local media and load offline websites.

[NotWoods]

Marking this as wontfix since we don't plan to support file:// URLs.

[robsmith11]

Is there a discussion somewhere explaining this decision?

Chrome on Android supports opening local files. Why wouldn't Firefox on Android support a useful feature that Firefox supports on all other platforms?

[emilio]

I'd also love to know the reasoning, and specially whether it affects content:// URIs, which Fennec uses translating to file:// URIs.

[buttercookie42]

(though for HTML documents using any kinds of subresources or local links, content://-URIs are mostly useless anyway because Google never really thought things through...)

[ildar]

Please reopen.

[emilio]

I cannot reopen but it'd be nice to get an answer as for the why here... @snorp?

[snorp]

I don't know the reason either, but I suspect it's in order to prevent a whole category of thorny security problems. Over the years, Fennec (and Chrome) have had several of these. @liuche do you know the full reasoning here?

[emilio]

Interestingly https://bugzilla.mozilla.org/show_bug.cgi?id=1563422 was just closed as WONTFIX.

[Kakitoru]

This is asinine. Why not stop Firefox from opening web sites as well, then? That would also prevent a whole lot of thorny security problems for sure.

If this is not fixed, how to open local files (text, images, etc), play local media, run local wikis, test web sites and coded web apps locally, open presentations, or work offline?

This certainly kills Firefox for me and my co-workers.

[kbrosnan]

Bug 1563422 was wonfix'ed because we are limiting the amount of Firefox for Android work that is being done. It was not selected as the fix in 68 so changing the behavior in following ESR releases was not worth it.

[theres-waldo]

I find this really unfortunate. I use file:// URIs all the time in Fennec to load documents saved for offline viewing, as well as local testcases and such.

[kumarharsh]

Why is this issue being handwaved away as just a security issue - only for Fenix? Please provide a proper answer or a bugzilla bug link at the very least.

[Crandel]

Please reconsider. A lot of people have a terrible internet and save pages to open them later from file. Even in Germany very poor internet underground and I always save important pages to read them while going to work. SingleFile, recommended by Mozilla, is a very popular extension also make no sense with this decision.

[andreicristianpetcu]

Maybe Fenix should implement screenshots like Firefox Lite to facilitate offline navigation. Opening local html files is a terrible idea. Lots of malware can spread like that.

I often see users not asking for a fix for a problem but asking for a specific fix in their specific way. This is not how software is built. People have problems: "I need to see offline sites" now that is a problem. "I need to open local html files". That is a solution.

Fennec can access offline bookmarks. That is another fix for the offline sites issue.

Please tell your problems to devs and let them find solutions. Does their solution not fix your problem? Tell them but please do not propose solutions.

[lnicola]

Every browser, from lynx and Netscape to Chrome can open local files. There are plenty of reasons to do so, from learning HTML to reading web pages you saved as a backup, to opening pages sent with the wrong Content-Disposition. What you are saying is basically "why would you want to open pictures from your hard drive when there is Google Photos, that's crazy and dangerous".

[andreicristianpetcu]

"Everybody else is doing it" is rarely a good argument.

[lnicola]

Removing features that every browser has for security theater is a bad idea. Why not remove add-on support, there's plenty more malware on a.m.o than in local HTML files.

[Crandel]

@andreicristianpetcu I want to open local html files. I don`t need any screenshots or anything else. What security problems this feature creates? I create my German dictionary as an html page manually and want to open it on desktop and mobile. I saved a lot of pages locally and have a search and index on them. Most of these pages are gone and lost forever but I have this information. The main job for browser is to open html pages, no matter there they are coming.

[emilio]

I also think this should be fixed. If I receive an HTML file as an email attachment, which I do somewhat often, I still cannot open it using Fenix, which sucks.

[theres-waldo]

@kbrosnan Given the feedback in this thread, would you be willing to reconsider this?

Or, if not, to at least make access to file:// URIs available behind a setting or about:config flag?

[kbrosnan]

No, I can't. There is a valid security issue that this allows. I will bring it to group triage and discuss with product.

[Crandel]

@kbrosnan

There is a valid security issue

Do you have any links to this security issue? I'm not able to find any reasonable description of issues, connected with file://

[lnicola]

@Crandel https://bugzilla.mozilla.org/show_bug.cgi?id=1558299 seems to be one, but it's under embargo.

[emilio]

That bug also affected desktop, and I don't think people are considering removing file:// access from desktop... Plus it is fixed?

[Crandel]

@lnicola I have no access to this page

[lnicola]

I imagine it's a sandbox escape -- I don't have access myself. But then again, there's been a lot of those, even in newer features like Activity Stream or pdf.js, and they didn't get removed to avoid security bugs. I can appreciate that removing local file access can prevent a whole class of issues, but this doesn't feel like the right decision.

[emilio]

It's not a sandbox escape of any sort.

[emilio]

In particular, it's really a version of https://bugzilla.mozilla.org/show_bug.cgi?id=1500453 / https://bugzilla.mozilla.org/show_bug.cgi?id=803143, which had a few more security implications in Android because paths are more predictable. But that's pretty much it AFAICS.

[andreicristianpetcu]

Reading the thread here makes me come to one conclusion:
Users clearly know more here on security than the devs!

[emilio]

(Well, I'm a Firefox dev too, just sayin' :))

[emilio]

And it's not about knowing more or not. I'm pretty sure the Fenix team is perfectly aware of the security implications here (and there may be some others that I'm missing), but as a user I think the trade-off here is not acceptable. People ought to be able to open HTML pages from their own file system.

[Crandel]

There is a very good addon SingleFile, that saves all page as single html file, so we do not need to load anything else from file system. What if sandbox will allow open only this file, without access to other files? Even such limited access to local file will be fine for me.

[buttercookie42]

There is a very good addon SingleFile, that saves all page as single html file

While that merges all the associated support files (images, CSS, JS, etc.) into the same file, it still only works for a single document at a time, so of limited value when you have a complete collection of multiple documents which all reference each other.

[kumarharsh]

In particular, it's really a version of bugzilla.mozilla.org/show_bug.cgi?id=1500453 / bugzilla.mozilla.org/show_bug.cgi?id=803143, which had a few more security implications in Android because paths are more predictable. But that's pretty much it AFAICS.

Thanks for the links @emilio. From the discussions in the links, I would conclude that in-case a change is needed, Firefox should just go with what Chrome is already doing. Banning file:// URIs altogether just gimps the browser.

[emilio]

My point in the comment above is that that bug _is_ fixed on Firefox and Fennec since a while ago, so that particular bug/threat model shouldn't be a concern anymore, again unless I'm missing something.

[Kakitoru]

Opening local html files is a terrible idea.

I'm assuming you've never worked on developing a web page or web application, ever. It involves browsers opening local files. Many, many, many times. In our organization we use local wikis extensively, again, something you may not be familiar with.

And how is opening a local file made by the user herself (plenty of examples have been given, a bookmarks file, a preferences file, a dictionary, a wiki, a media file, an image, etc, etc, etc...) more dangerous (or at all) than opening an unknown site, loaded with running scripts, trackers, spyware, data mining suckers, geolocation, served by a stranger's computer somewhere?

This is akin to you saying, if the text editor crashes when typing the letter "A", don't type the letter "A", egad you fools! Why would you ever need to do that. There are plenty of letters other than "A".

If there is a security issue, then the security issue must be addressed, not a fundamental function taken away instead.