Unlike a web server the filesystem does not provide content-types. Therefore the browser has to guess. In this case the outcome is most likely text/plain. At least that’s what file proposes:
$ file --mime-type -b /etc/passwd
text/plain
And for web content with mimetype text/plain there is simply no difference between displayed content and source.
The cat’s out of the bag now. Accusing community members of not providing sufficient customer support in reply to unstructured complaints… haven’t seen that one before, have we?
AFAIU SFOS 4.x has introduced sandboxing for a few (more) apps, like Firefox? And it uses firejail for this?
Firejail has been doing this for a long time now (originally for Firefox as the name implies) and if they decided that the Firefox profile is allowed to read some files in /etc, just like a normal user can, then that’s it.
That’s the beauty of SFOS, it works like a Linux distro, no need to worry about Google’s mobile OS paradigm anymore.
That said, there’s been criticism of firejail not being secure enough. I suspect it’s the same security-buzzword-crazy Android millenials parroting that, but there it is.
But hey, I’m talking out my arse. I don’t positively know if SFOS 4.x uses firejail to sandbox Firefox, and whether it uses the default Firefox profile or something else…?
Clarifying that would be the next constructive step.
FYI the bug report has been updated.
JavaScript code is not allowed to access local files, which is enforced by the browser itself. This has been for quite a while (probably over 10 years by now), due to security concerns. But if an user manually enters a file-url in their browser address bar, the browser will go there.
If you’re not convinced, I’ve thrown together a quick test page you can test out if the browser blocks things. Note that if you download the page, using the link found at the bottom, and open it from your file system, some of the links will work!
Edit:
It seems like the browser has some interesting, unexpected behaviour:
Maybe these have been cached by FF? So it’s not actually showing the files from the filesystem, it’s showing those in FF’s cache?
The image is not showing up anymore on 4.5.0.24.
But opening the html still allows to link to /etc/passwd.
Don’t really know if this is an issue…
How would it have cached the images, if it its not supposed to load them in the first place ?
There seems to be some bitrot here after all…
as far as i know in a linux or unix system any file in /etc is given read access to any user
etc means “editable text configuration” i wonder if the system would work at all if this read access was denied to a regular user
The question is more if the jail the browser is running in should have access to it. But maybe?
Indeed system access is one thing, browser access another.
It remains to be seen if the whole filesystem is also accessible from the browser…i.e. not only etc…
from above aloready gallery pictures seem to be as well…
So what I am wondering here is, is there some bitrot somewhere that potentially gives access to some private data…and which should be fixed.
btw editable text configuration → I was missing this piece, thanks! 
It is also (in addition to repeating what was stated above, that reading passwd is normal, harmless, and required) important to note that what you see in file:///etc is NOT the full content of /etc.
Rather, through sailjail, the browser sees a read-only copy of some of the files from that dir.
It may be interesting to some to read up on the private-etc, blacklist, whitelist, and read-only config settings of Firejail which explains how this works.
https://man7.org/linux/man-pages/man5/firejail-profile.5.html
Okay, thats great reference! Thanks!