My explorations here, viewtopic.php?p=21516#p21516 and here, viewtopic.php?p=35555#p35555 suggested the following:
If the Chrooted-OS was packaged as an ordinary SFS and SFS-loaded, under ordinary circumstances a Web-browser run from the Chrooted-OS could not access any drive/partition including the drive/partition from which it had been loaded but that drive/partition could not be unmounted.
If the Chrooted-OS was packaged as an ‘alphabet’ SFS –an adrv.sfs or a ydrv.sfs automatically used on boot-up-- and the entire system located on a USB-Key, after boot-up the USB-Key could be unplugged and the entire system would continue to be fully functional.
Despite that in the creation of the Chrooted-OS only some applications were specifically linked to the MainOS to be started from the MainOS, once the Chrooted-OS was active applications within it could be run which hadn’t been specifically linked to the MainOS. [This will create RAM and improper shut-down problems; but that’s not a hacker’s concern]. For example, having remastered a 32-bit OS to include Wine, Wine-File could open any application within the Chroot, including rox and terminal emulators. And, of course, if the Chrooted-OS’s rox-file browser was specifically linked to be run from the MainOS, it could start any application within the Chrooted-OS.
Web-browsers run from a Chrooted-OS could not access the MainOS; but with such a browser running, Ctrl-o could be used to access any file within the Chrooted-OS: at least to see it -and if a text file its contents-- even if not to able to run that application. But when a Ctrl-o was executed and a file selected a GUI would appear inquiring as to what application should be used to open that file.
The foregoing suggested the possibility that some hacker might be able to use applications within the Chrooted-OS to escape the Chrooted-OS. There’s nothing I can do to eliminate the capability of a Web-browser to inter-act with files via their built-in Ctrl-o capability. Nor is there anything I can do to prevent a hacker from injecting files into RAM. [See Tip below]. But there was something I could do to make a hacker’s objective more difficult: eliminate all obvious applications in the Chroot-OS which might be of use. After all, one’s MainOS usually has whatever applications we want: the only thing we want from the Chroot-OS is a web-browser providing security and privacy.
[“Obvious”: I don’t have the technical skills to safely remove ‘low-level’ infra-structure without breaking an OS. Suggestions are welcome].
The download link:
Chroot_IronFoxEsr-91.4.1_8.0.sfs can be obtained here, https://www.mediafire.com/file/re3qtoz6 ... 0.sfs/file. The web-browsers it offers are the current latest firefox-esr-91.4.1 and Iron 96.0.4664.45 –thanks, fredx181 and MikeWalsh for the portables. Both web-browsers have been hardened for security and privacy as discussed here, viewtopic.php?p=19203. They operate from a Chrooted-OS constructed employing Barry K’s xenialpup_7.5-r2_amd64.sfs from here, http://distro.ibiblio.org/easyos/amd64/ ... tu/xenial/. Thanks, Barry.
The latter was unpacked into the /cont folder of what would become the ChrootOS, see viewtopic.php?t=3721, Before packaging (dir2sfs) this Chroot that folder was examined using pfind, and all the binaries of all rox-filemanager, every console/terminal, every text-editor, word-processor and many other applications I thought could pose a threat were deleted. [Binaries only: I did not bother to delete their now useless desktop, libraries and config files].
The best way to use this application is to rename it (Right-Click>Rename) as an adrv.sfs or ydrv.sfs consistent with your MainOS [e.g. with Bionicpup64 name it adrv_bionicpup64_8.0.sfs]; booting your MainOS from a USB-Key. That way, after boot-up you can unplug the USB-Key. But before renaming it, know what applications you have in any adrv.sfs or ydrv.sfs. You may want to rename an existing adrv.sfs to ydrv.sfs; or combine an existing adrv.sfs with an existing ydrv.sfs. Note, the contents of an adrv.sfs have priority over the contents of a ydrv.sfs.
Usage Tips:
These Chrooted Web-browsers and the ChrootOS, itself, only exist in RAM. Rebooting, of course, is probably the best way to clear RAM and anything existing in RAM which you might not want and might not even know is there. Rebooting is, however, inconvenient. The following, I think, does are reasonably good job of clearing RAM. Install either CleanRam, viewtopic.php?p=25645#p25645 or Cleanup-Memory, viewtopic.php?p=27559#p27559. Menu>Exit>Restart Graphical Servers (AKA restart-x) will terminate any running applications. Then run either of the applications mention to Clear RAM of vestigial files.
The web-browsers are configured to download files into /cont/root/downloads and can only upload files that are already within the Chroot: /cont/root/downloads is OK even for uploading. 
You can rox-bookmark that location (or any other location in the Chroot) in your MainOS and add such locations to your MainOS's Right-Click>Copy-to options. [Tip flinched from Mike Walsh]. The Chroot-OS may be crippled; but your MainOS still has root-privileges to anything and anywhere.
This is a ‘locked’ application. You can’t add book-marks. Supposedly, when you Ctlr-click a URL written in a LibreOffice or OpenOffice document your web-browser should open to that web-page. I’ve never gotten that to work. What I do is keep a list of frequently accessed URLs in a text file. I can open that in my MainOS, then copy-and-paste it into an open Web-browser’s URL-box.
It won’t update and you can’t change or update extensions/addons. [Well, maybe you can: but then you’d have to create a SaveFile/Folder and loose the ability to unplug your USB-Key]. If and when these operations become necessary you can up-pack it, run it’s unpacked version, updating and changing add-ons and settings and then repackage. Unpacked, they retain all a portable’s capabilities and advantages. Warning: Keep the old version until you’re sure then ‘update’ works. It doesn’t always. And frankly, getting firefox-esr’s addons to display properly was a PITA. Substitute firefox for firefox-esr at your own risk. I couldn’t get firefox to work, at all.
Many of the addons/extensions function automatically: no user intervention required; nothing to Click. They’re present but not ‘pinned’ to the toolbar. Others, however, do their job only when you click them. They should be on the toolbar. I’ve never had a problem with Iron. But sometimes when firefox opens the toolbar and my other settings weren’t present. Closing firefox-esr and reopening it revealed them. I think I’ve fixed that. But the only way to tell is, the first time you use firefox-esr, close then re-open it. If the toolbar icons change, you’ll have to do that each time you boot-up.
Although amethyst has provided tools for working with adrv.sfs and ydrv.sfs, viewtopic.php?p=12983#p12983, I don't think they take into consideration the existence of a /cont folder or the applications within it.