What about qute-browser ?
None whatsoever.
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).
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 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.
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.
Oh my god, yes. Anyone tried to use w^x with chromium recently? It. just. does. not. work.
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?
FreeBSD, periodic, dailysecurity. Aweful lot of hits on Chromium.
How long is enourmous long?
I see that it's in the "Off-Topic" forum now, in which forum was it originally posted?
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 with
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
.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.
% 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
30So it looks to me like inter-site (inter-thread?) sanboxing in chrome doesn't really much matter in comparison to firefox.
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!
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 now
