Ubuntu Looking To Bring Click Packages To The Desktop
Phoronix: Ubuntu Looking To Bring Click Packages To The Desktop
Ubuntu developers are moving forward with their plans to support Click packages on the Ubuntu desktop...
May I suggest a click version of Firefox as an option?
I really like the way Torbrowser runs from a portable folder. You can copy it to /tmp when running a tmpfs for /tmp, run from it and throw it out when you are done. All supercookies and other forms of tracking that require client-side file storage are defeated.
Doing the same from system Firefox is much more complex, requiring a script that runs with sudo priviliges to make the necessary tmpfs, copy over the .mozilla files, mount this over .mozilla, then chown everything back to your user account and drop priviliges to run Firefox. You still use system copies of binaries, making it harder to isolate the whole process unless of course you want to fire up an entire VM just to run the browser, something I have in fact considered doing.
Hey Luke, seeing as you commented about systemd stuff just now, did/are the recent systemd changes allowing for something like this in general? Based on your you're suggestion making it easier in system.
And this process being used by Ubuntu sounds a bit like Docker. Are they related? Is it Docker?
It would be nice to have a better installation process for desktop applications on Ubuntu. It would also allow better separation of system packages and applications and make it easier for new users.
I think Click bundles any additional dependencies in the file, meaning if an application requires an older or newer version than available, or a dependency not in the default repository, it doesn't fail to install.
Not familiar with Docker, but systemd not a factor in this
I am not familiar with Docker at all, so I can't comment on that. As for systemd, browsers are not started up at boot, so they do not interact with the boot process at all. The way I use Torbrowser is just open /tmp, which is always on a tmpfs in my systems, drag the Trobrowser folder to it to copy it, then launch from there. Delete and repeat for each subsequent Tor session to destroy flash/supercookies, etc.
Originally Posted by stiiixy
For system Firefox, I have a script in /home and a shortcut in the Cinnamon panel to fire it up. It makes a tmpfs, copies all of ~/.mozilla to it, mounts it over ~/.mozilla, changes ownership to the user who launched it, then launches Firefox. Systemd is not involved in this, it's just something else I have been playing with lately. The only way you will interact with systemd (or upstart, or sysVinit) is if you want to automatically shut off something like an ssh or other such server so as not to have that as attack surface while using a non-local network. That was important to me when I only went on line by a netbook on the road, then connected it to an offline desktop later to move files. The laptop needed an ssh server, but I wanted that shut off when connected to the Internet on the road.
What would make normal Firefox easier to do all this with would be packaging it in a local directory holding the binary, the .mozilla files, and libraries needed to run it the way Torbrowser does, as a "portable" or "noinstall" package. I think that's how Click packages work. Windows also installs programs this way, the fact that ALL the top level software installs like that is why a Windows install can take up 30GB. That brings up another point: only packages where there is a need for portability or a need to use specific library versions (like development versions of kdenlive) really benefit from this, and there is a space cost. Fortunately, I can easily afford to put a 100MB application folder in /home, which is an encrypted RAID of HDD's. I would not want to put them on the encrypted root volume, which is a tiny SSD.
The point to all this is to run Firefox and Torbrowser from RAM as a disk-avoidance strategy, just as though I had turned my entire system into a live DVD. Nothing better for defeating cookie respawning via other forms of browser data storage than keeping all of it in RAM, and nothing better for preventing a locally-stored history from being available if an attacker manages to somehow defeat my encryption after another house raid. Never put all your trust in a single-layer defense!