What about qute-browser ?
I was reading this last night . Are you saying that it's possible some of those sandboxing options for the ungoogled-chromium package might not have made it into the FreeBSD port?
None whatsoever.How much of the Chromium sandboxing is actually done in the FreeBSD port?
Yeah, I think this is one of the best solutions for now until the web browser ecosystem has a major reshuffle (if it ever does).That's what I do for daily/random browsing. I have a disposable jail which is zfs cloned from a template, and when the jail shuts down, the clone is destroyed and re-created. So a new FF profile is created every time.
FreeBSD's only process sandboxing technology is called Capsicum and you can easily grep those Chromium patches in ports for the evidence of its (lack of) usage yourself. Seccomp-bpf is simply not available there.Is there anywhere I can read more about that? Why wouldn't internal browser sandboxing measures be included in the FreeBSD port?
I think I saw you mention somewhere else that running Capsicum on a browser would make it unusable (or something like that).FreeBSD's only process sandboxing technology is called Capsicum and you can easily grep those Chromium patches in ports for the evidence of its (lack of) usage yourself. Seccomp-bpf is simply not available there.
Definitely not.I think I saw you mention somewhere else that running Capsicum on a browser would make it unusable (or something like that).
I said process sandboxing — something that an individual process can set up for itself. Jails are not suitable for isolating browser components from each other: Chromium creates and kills processes all the time, you won't be able to provision a new jail each time you open a new tab with a new site even if you wanted to.Also, I'm guessing you don't consider jails to be a sandboxing technology? What would be your reasoning there?
Ah okay, thanks for the clarification. I found this thread where you elaborate a bit more on this, thanks for pointing this out again here. I had no idea that sandboxxing wasn't implemented.Definitely not.
I said process sandboxing — something that an individual process can set up for itself. Jails are not suitable for isolating browser components from each other: Chromium creates and kills processes all the time, you won't be able to provision a new jail each time you open a new tab with a new site even if you wanted to.
The original intended use behind jails is dividing a machine between multiple users in the way that would not require them to rely on a single administrator for installing and maintaining software. A hosting scenario, basically.
Oh my god, yes. Anyone tried to use w^x with chromium recently? It. just. does. not. work.Chromium creates and kills processes all the time
elfctl
just does not work on chromium's binary and this constant launching of new processes makes it completely impossible to just disable it momentarily for its launch.What was the question?It's a valid question but wrong thread.
FreeBSD, periodic, dailysecurity. Aweful lot of hits on Chromium.Of the millions of Chrome users, I'd bet very few ever read the security postings.
Of the millions of Firefox users, I'd bet very few have security issues on non-Windows systems.
How long is enourmous long?iridium,ungoogled-chromium&chromium have an enourmous long compile-time...
I see that it's in the "Off-Topic" forum now, in which forum was it originally posted?No, it belongs right here. New people coming to FreeBSD come to this forum to read opinions, perspective, and discussion of various ports and packages. And for anyone running FreeBSD as a desktop, choosing a browser is an important decision.
If you have a difference of perspective or reasoning, then rather than being dismissive, you could share that perspective.
Now there's some insight that raises my curiosity.
Apart from going over a proxy and white listing domains, how do you monitor your web browser traffic?
I forgot how long I am using Qutebrowser but it works very good for me. I didn't have any problem except I was not successful with import withWhat about qute-browser ?
import.py
Firefox bokmarks.html to Qutebrowser bookmarks/quickmarks but I did slowl manual. What is your opinion?If you are a "vi" user IMO is not difficult .There are two browser who take privacy serious. ungoogled-chromium & qutebrowser.
Just for qutebrowser your brain must remember the keys you programmed , like "back".
I'd like to take a look at consistent lists of known vulnerabilities of both, but I didn't found anything really clean. http://vuxml.freebsd.org/freebsd/pkg-firefox.html shows records only up to 2020. Does anybody know why? https://www.cvedetails.com/ shows records for both firefox and chrome unclassified by type and score, so it's hard to estimate impact at glance.Chromium is significantly more secure, hardened, and sandboxed.
% cat chrome.tsv | grep -i -e "file system\|filesystem\|arbitrary code\|malicious code\|code execution\|buffer overflow" | wc -l
36
% cat firefox.tsv | grep -i -e "file system\|filesystem\|arbitrary code\|malicious code\|code execution\|buffer overflow" | wc -l
30
So it looks to me like inter-site (inter-thread?) sanboxing in chrome doesn't really much matter in comparison to firefox.Chromium is ... sandboxed
I've been enthusiastically using qutebrowser for some time. It's great. I've kept iridium for a few sites where the brave adblocker doesn't quite do the trick. The ublock origin extension can be added to iridium through the chrome app store. I've been eyeing the ungoogled-chromium port but read somewhere that extenions require some workarounds. My age induced resistance to learning new things has led me to not yet install it. Please relay your experience!Removing iririum & chromium and installing ungoogled-chromium & qutebrowser.
As i have written in my previous post chrome shows 283 vulnerabilities for the past year. This is 1 vulnerability per 31 hour in average. Situation with firefox is a little bit better, but not too much. Both is very heavy to build from source. So in many real life situation only option I have is to install quarterly build. But installing it normal way with pkg leads to updating libraries that new version of firefox depends on and this in turn leads to updating many desktop software packages just for that. And after such update it is easily may turn out that updated version of some tool are broken some way, and typically I touched this tool not for fun, but because I need my job done right now. So what I doing is building all required libraries (which have unsatisfactory their versions in /usr/local) to some directory, then point to it in LD_LIBRARY_PATH, manually extracting new version of firefox from package to any other directory and run from there. Luckily firefox can run from any directory, not only /usr/local/lib/firefox/. Also I prefer to keep different versions of firefox at same time for testing as sites as firefoxes itself. So what I dreaming of is some community project of relatively separate from ports/pkg frequent Firefox (or/and chrome) builds with all dependencies included (intended to work with ports tree starting from version, packed with initial first major FreeBSD version release), such a way that it may be just extracted into /opt and run from there, no matter on which quarterly/head port tree I'm nowIt has absolutely nothing to do with "installation and maintenance of ports or packages"
I'll take a look at Capsicum. I'm not a dev, and I only know shell and sysadmin stuff, not any full programming languages. But I'll see if I can figure anything out.