-
Notifications
You must be signed in to change notification settings - Fork 1.3k
[Bug] Cannot browse to file:// URIs #4049
Comments
Is this different from |
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. |
Marking this as wontfix since we don't plan to support |
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? |
I'd also love to know the reasoning, and specially whether it affects |
(though for HTML documents using any kinds of subresources or local links, |
Please reopen. |
I cannot reopen but it'd be nice to get an answer as for the why here... @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? |
Interestingly https://bugzilla.mozilla.org/show_bug.cgi?id=1563422 was just closed as WONTFIX. |
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. |
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. |
I find this really unfortunate. I use |
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. |
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. |
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". |
"Everybody else is doing it" is rarely a good argument. |
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. |
@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. |
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. |
@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 |
@lnicola I have no access to this page |
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. |
It's not a sandbox escape of any sort. |
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. |
Reading the thread here makes me come to one conclusion: |
(Well, I'm a Firefox dev too, just sayin' :)) |
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. |
There is a very good addon |
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. |
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 |
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. |
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. |
Okay, so it's a trade-off. But is this really such an unimportant feature ? I mean, what would you use to open html-files if not a browser ? |
Just a reminder for my future self and for those who are searching for the open-local-files feature in which browser. I tried Firefox, Firefox Lite and Opera Mini on Android yesterday, and none of them seems to have this opening-local-files ability. I eventually tried Opera Browser for Android (NOT the Mini version), and it works. Cheers. |
Using local HTML is a common solution for storing static reference materials. Think teachers reading out their class notes, corporate salesmen out on the road with their tablets, people who work in places with poor Internet access, etc. HTML is the presentation/markup format the world uses. There are tons of solutions out there that use it locally. The tool to do such browsing is called a browser, and I believe Firefox wants to be one. It's understandable that some specific security concern might require restrictions, but the all-out cancellation of local browsing in the real-world, only brings less security with it. In our case, putting everyone on Firefox Android 68 which is the usable browser. How unsafe is that? Some middle-ground solution needs to be achieved, and I'm sure it's possible. Thanks for all the work done on this project. |
For saving of pages for offline you can try Pocket or Evernote. |
That kind of advice is good for some and unacceptable for others.
Hence cannot be considered as a solution.
|
Does anybody know the reasons why this is such a problematic issue in the first place ? |
Steps to reproduce
file://
URI. I was poking at whether [Bug] Fenix doesn't get listed as an option to open html files #3864 was a simple matter of tweaking the manifest, I guess not.Expected behavior
Actual behavior
file://your-file
┆Issue is synchronized with this Jira Task
The text was updated successfully, but these errors were encountered: