retrokit VS cosmic-text

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.

I maintain a web layout library that is designed to be integrated into other software:

https://github.com/DioxusLabs/taffy

It needs to be combined with a text layout engine (such as https://github.com/pop-os/cosmic-text), and it doesn't support everything yet (notable features that are currently missing: "float", "display: inline-block", "box-sizing: content-box", "position: static"). But we have Block, Flexbox and CSS Grid support with more on the way.

All of these projects have in common that they use Taffy (the project that I work on!) for box-level layout (which currently gives them block, flexbox, and grid layout) , and are either using or planning to use cosmic-text for text/inline layout. This gives you a decent first approximation of web layout, but it's not perfect and there are major features like float, display: inline-block, position: static, box-sizing: content-box missing. Not to mention that none of these implementations currently resolve CSS selectors, so you are effectively limited to inline styles (if you're interested in something in that direction then you may be interested in https://github.com/vizia/vizia).

You might be interested in the combination of Taffy [0] which handles box-level browser layout (block, flexbox, grid, etc) and Cosmic Text [1] which handles text-level layout and basic text editing functionality.

Integrating them into browsers while retaining accessibility could be tricky. But in they're general they're relatively small standalone libraries implementing most of the layout algorithms that browsers implement (although there are currently a few key missing features like laying out "inline-block" items in line with text).

[0]: https://github.com/DioxusLabs/taffy

[1]: https://github.com/pop-os/cosmic-text

By integrating the Cosmic Text library from https://github.com/pop-os/cosmic-text, Bevy Cosmic Edit enhances Bevy's UI system with the following features:

https://github.com/pop-os/cosmic-text that does text layout and rasterisation with full support for things like CJK scripts and emojis)

Libraries for a lot of this stuff exist (albeit in many cases not very mature yet):

- https://github.com/pop-os/cosmic-text does text layout (which Taffy explicitly considers out of scope)

- https://github.com/AccessKit/accesskit does accessibility

- https://github.com/servo/rust-cssparser does value-agnostic CSS parsing (it will parse the general syntax but leaves value parsing up to the user, meaning you can easily add support for whatever properties you what). Libraries like https://github.com/parcel-bundler/lightningcss implement parsing for the standard css properties.

- There are crates like https://github.com/BurntSushi/bstr and https://docs.rs/wtf8/latest/wtf8/ for working with non-unicode text

We are planning to add a C API to Taffy, but tbh I feel like C is not very good for this kind of modularised approach. You really want to be able to expose complex APIs with enforced type safety and this isn't possible with C.

There are a number of up-and-coming Rust-based frameworks in this niche:

- https://github.com/iced-rs/iced (probably the most usable today)

- https://github.com/vizia/vizia

- https://github.com/marc2332/freya

- https://github.com/linebender/xilem (currently very incomplete but exciting because it's from a team with a strong track record)

What is also exciting to me is that the Rust GUI ecosystem is in many cases building itself up with modular libraries. So while we have umpteen competing frameworks they are to a large degree all building and collaborating on the same foundations. For example, we have:

- https://github.com/rust-windowing/winit (cross-platform window creation)

- https://github.com/gfx-rs/wgpu (abstraction on top of vulkan/metal/dx12)

- https://github.com/linebender/vello (a canvas like imperative drawing API on top of wgpu)

- https://github.com/DioxusLabs/taffy (UI layout algorithms)

- https://github.com/pop-os/cosmic-text (text rendering and editing)

- https://github.com/AccessKit/accesskit (cross-platform accessibility APIs)

In many cases there a see https://blessed.rs/crates#section-graphics-subsection-gui for a more complete list of frameworks and foundational libraries)