retrokit VS Servo

That's what I did [1]

Need contributors and other maintainers though, because keeping up with upstream is impossible as a single dev.

[1] https://github.com/tholian-network/retrokit

From a technological point of view, TOR still has a couple of flaws which make it vulnerable to the metadata logging systems of ISPs:

- it needs a trailing non-zero buffer, randomized by the size of the payload, so that stream sizes and durations don't match

- it needs a request scattering feature, so that the requests for a specific website don't get proxied through the same nodes/paths

- it needs a failsafe browser engine, which doesn't give a flying damn about WebRTC and decides to actively drop features.

- it needs to stop monkey-patching out ("stubbing") the APIs that are compromising user privacy, and start removing those features.

I myself started a WebKit fork a while ago but eventually had to give up due to the sheer amount of work required to maintain such an engine project. I called it RetroKit [1], and I documented what kind of features in WebKit were already usable for tracking and had to be removed.

I'm sorry to be blunt here, but all that user privacy valueing electron bullshit that uses embedded chrome in the background doesn't cut it anymore. And neither does Firefox that literally goes rogue in an endless loop of requests when you block their tracking domains. The config settings in Firefox don't change shit anymore, and it will keep requesting the tracking domains. It does it also in Librefox and all the *wolf profile variants, just use a local eBPF firewall to verify. I added my non-complete opensnitch ruleset to my dotfiles for others to try out. [3]

If I would rewrite a browser engine today, I'd probably go for golang. But golang probably makes handling arbitrary network data a huge pain, so it's kinda useless for failsafe html5 parsing.

[1] https://github.com/tholian-network/retrokit

[2] (the browser using retrokit) https://github.com/tholian-network/stealth

[3] https://github.com/cookiengineer/dotfiles/tree/master/softwa...

I'm trying to go a different route with Stealth, my programmable peer-to-peer web browser that can offload and relay traffic intelligently - and with RetroKit, my WebKit fork that aims to remove all JavaScript APIs that can be used for fingerprinting and/or tracking.

Note that among a sea of tracked browsers, the untrackable browser shines like a bright star.

Statistical analysis of these values over time (matched with client hints, ETags, If-Modified-Since, and IPs) will make most browsers uniquely identifiable.

If the malicious vendor is good, they even correlate the size and order of requests. Because that's unique as well and can identify TOR browsers pretty easily.

It's like saying "I can't be tracked, because I use Linux". Guess what, as long as nobody in your town uses Linux, you are the most trackable person.

I decided to go with the "behave as the statistical norm expects you to behave" and created my browser/scraper [1] and forked WebKit into a webview [2] that doesn't support anything that can be used for tracking; with the idea that those tracking features can be shimmed and faked.

I personally think this is the only way to be untrackable these days. Because let's be honest, nobody uses Firefox with ETP in my town anymore :(

WebKit was a good start of this because at least some of the features were implemented behind compiler flags...whereas all other browsers and engines can't be built without say, WebRTC support, or say, without Audio Worklets which are for themselves enough to be uniquely identified.

[1] https://github.com/tholian-network/stealth

[2] https://github.com/tholian-network/retrokit

(both WIP)

Source: I forked WebKit into RetroKit and have been busy removing APIs that could be used as an attack surface. From outdated Netscape Plugin APIs to Java Applets...over Geolocation to even URL-based Hacks in the codebase.

Here you go, trying to remove all APIs that are unnecessary for a Web View: https://github.com/tholian-network/retrokit

> 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

> Is there any easy to use/hack HTML layouting engine where I could experiment with custom CSS attributes and bridge that gap? Would anything from Servo be suitable?

Servo could be used for this. You'd want to add support for parsing the CSS properties themselves to the style crate in https://github.com/servo/stylo and then the layout implementation to the layout2020 crate in https://github.com/servo/servo. You do effectively get a whole browser though.

I'm currently working on building a lighter weight / hackable layout engine based on a combination of https://github.com/servo/stylo (for css parsing and selector resolution), https://github.com/DioxusLabs/taffy (for box-level layout) and https://github.com/pop-os/cosmic-text (for flow/inline layout). I expect to have something decent in around 6 months

Neither of these setups currently have any support for pagination though.

Great to see some competition still alive in browser engine development. See also Servo (previously part of Mozilla) https://servo.org/ - that and Ladybird are still very underdeveloped compared to every day browsers.

It's a huge shame that there are no nightly builds of ladybird to try out but I assume that's because they just don't want the bug reports (if everything doesn't work it's pointless getting random bugs filed).

I haven't messed with it yet but from looking into it, this should absolutely work.

https://github.com/servo/servo/wiki/Building-on-ARM-desktop-...

don't know, there was a downtime in 2021 and 22 but since 2023, contributions look back to where it was before .. https://github.com/servo/servo/graphs/contributors

The world has moved on though to opinionated tools, and Rust isn't even the furthest in that direction (That would be Go). The equivalent of those two lines in Cargo.toml would be this example of a basic configuration from the jacoco-maven-plugin: https://www.jacoco.org/jacoco/trunk/doc/examples/build/pom.x... - That's 40 lines in the section to do the "defaults".

Yes, you could add a load of config for files to include/exclude from coverage and so on, but the idea that that's a norm is way more common in Java projects than other languages. Like here's some example Cargo.toml files from complicated Rust projects:

Servo: https://github.com/servo/servo/blob/main/Cargo.toml

rust-gdext: https://github.com/godot-rust/gdext/blob/master/godot-core/C...

ripgrep: https://github.com/BurntSushi/ripgrep/blob/master/Cargo.toml

socketio: https://github.com/1c3t3a/rust-socketio/blob/main/socketio/C...

1. Servo

It won't don't worry. There already are forks, for the worst case scenario. And Servo is on its way. Not yet ready, but it will be. Originally, from Mozilla kitchen.

To pain broad strokes, the layout phase (~= take the HTML, take the CSS, determine the position and size of boxes) is largely sequential in production browser engine today. Selector matching (~= what CSS applies to what element) is parallel in Firefox today, via the Stylo Rust crate originally developed in the research browser engine Servo. Servo can do parallel layout in some capacity (but doesn't implement everything), https://github.com/servo/servo/wiki/Servo-Layout-Engines-Rep... is an interesting and recent document on the matter.

Parallel layout is generally considered to be a complex engineering problem by domain experts.

https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-en... is a really cool article that is related, that is a few years old but what it says is largely correct today.

[Article author/submitter here]

I can only tell you that it is not what this is about, inasmuch as I was at the talk and there was not a single mention of Firefox Reality or Wolvic in the talk.

Wolvic might use Servo – but I think if it did they would mention it, right?

The talk didn't and the word "Wolvic" does not occur anywhere on https://servo.org

So I am guessing not, no.

Igalia has -- or rather is because it's a co-op -- about 100 developers. They are not all working on the same thing.