Our great sponsors
-
dooble
Dooble is a scientific browser. Minimal, cute, unusually stable, and available almost everyware. Completed?
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
The feature list at https://github.com/textbrowser/dooble is... interesting for a minimal browser:
> Original implementations of AES-256, Threefish-256.
> Native graphing of data.
> Floating digital clock.
etc.
> it uses Qt's WebEngine (Chromium)
Came here to post this after taking a look at the source code.
Honestly, I don't think this is what we need. Midori and others already switched to Electron, and we have dozens of Electron GUIs describing themselves as "secure" Web Browsers, even though they just use a element and that's basically it. They don't even care that all their users are fingerprinted and tracked by Google's TURN servers for WebRTC, which are automatically connected-to on every start of the program. I mean, really? You didn't even use a software firewall to check what's going on?
I think that what we need is an alternative that values privacy and security over everything else, without compromising on that. Even the TOR Browser threw their towel in the past, and meanwhile decided to use a script that replaces some APIs in upstream Firefox with stub APIs - instead of removing them from the codebase. If something is added and forgotten to add to this stubbing script, it's an exposed API.
Personally I believe we have to reduce the attack surface of Web Browsers. It's okay to have an Ungoogled Chromium to play your WebGL games occasionally. But do you want it to be able to fingerprint your hardware, and even your network devices? Probably not.
I wish Permission Management and Access to APIs would play a bigger role in the Web Browser market, but most vendors use Privacy more as a marketing thing that has no meaning at all anymore. Firefox fingerprints you by default every time you open the program by default via their shitty geolocation and ocsp services, and the Tracking Prevention basically is useless against fingerprint.js or fingerprint.css or even against HTTP2/HTTP3 fingerprinting through ETag headers. I mean, uBlock does a better job with that; even without the same amount of capabilities.
And Web Extensions can't filter response bodies, and therefore "abuse" injected CORS headers to block the loaded content. Well, at least it worked as long as google decided to not allowlist their own domains, which they now did. (well, additionally to the Manifest V3 shitshow, which I won't dig into)
We desperately need a secure _Web Engine_ alternative that removes all that crap that can be abused for fingerprinting. In regards to opsec we need something like an integration to another Browser a la "Open this in an Incognito Tab with an isolated Browser Session inside /tmp/randomized-profile-1337". The other things won't last, and there's always be bypasses and exploits in the JIT world. All the Cookie Clearing extensions just ain't gonna cut it anymore.
Over the holidays I started to revisit my idea to fork WebKit into something more secure [1], and spent some time in removing all kinds of features from it. I was kind of shocked how many APIs were available that were built with no permission management at all. Things like detecting Airplay-capable devices, hardcoded behaviours for specific domains, bluetooth APIs, payment request APIs that basically get full access to your local keyring, bugs in FTP directory parsers that could be abused to see whether you have working credentials in your keyring, picture in picture APIs that can be easily exploited, media capture APIs that are delegating streams through 3 processes, shared buffers that aren't really implemented and still exposed as an API, preconnect and prerender functionalities that can be used in an endless loop...etc.pp.
From an opsec perspective Web Browsers are a nightmare, and I don't think chromium is any different in that regard.
[1] https://github.com/tholian-network/retrokit