cookiengineer

retrokit

C++2021–2026

cookiengineer / retrokit

retrokit

:joystick: Bring back the old Web(Kit) and make it secure

Web Development Security & Privacy

Explore on GitHub Read Hacker News discussions

2Distinct people

16Mentions

0Explicit recommenders

56GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

:joystick: Bring back the old Web(Kit) and make it secure

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

tholian-network/stealth · linked in 4 of the same discussions
webkit/webkit · linked in 3 of the same discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year16 dated mentions

Observed mentions: 2021-12-27 21:38:45 UTC to 2026-01-10 07:31:10 UTC.

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	1	1
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	8	8
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	3	3
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	1	1
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	2	2
2026 (partial)	2026-01-01 00:00:00 UTC	2027-01-01 00:00:00 UTC	1	1

What Hacker News says

16 sources

cookiengineer·Jan 10, 2026

Are you looking for people who worked on WebKit in the past? I really hope you refactored WebKit's Bridge, because it allowed a lot of exploits in the past, and was neglected upstream by Apple. When I started my RetroKit fork I was aiming to reduce that attack surface while offering farbled apis based on other browser behaviors and their profiles. [1] My fork has been neglected a bit due to lack of time, as I'm currently still busy with other APT related things before I can get back to it. Would love to chat whether your plan is to open source your WebKit fork, maybe there's some overlap and we can work together on it? (I currently hope that ladybird will be getting into a more forkable and modular state, because servo passed by that goal a long time ago). [1] https://github.com/cookiengineer/retrokit

In Kagi releases alpha version of Orion for Linux

hans_castorp·Feb 28, 2025

> Try going to gitlab.com with librewolf, you'll see a white page with no content. > If you want a headstart, I tried forking webkit and do exactly this > [1] https://github.com/tholian-network/retrokit I just opened that page on LibreWolf without any problems.

In Mozilla owns “information you input through Firefox”

cookiengineer·Feb 28, 2025

Try going to gitlab.com with librewolf, you'll see a white page with no content. Librewolf is blocked off from half the internet that uses cloudflare, so it's kind of a useless browser. Every browser that's not a majority browser will be associated with these kind of blocking risk. I can't risk access to my financially important accounts, nobody can. So to me this is not a feasible alternative. The only way to build a browser is to act like one of the others, and to behave like one of the others. Can't use brave, given their history, but farbling approach is the most sustainable solution in my opinion. My remaining hope is that ladybird will actively deny implementing web standards that can be used for fingerprinting. Something as simple as overflow:hidden is used on every website to force people to get tracked by having to activate JS, a

Read the rest

nd things like this should be something a web browser should protect its users from. We need a CSS engine that denies setting these kinds of things, because JS fingerprint prevention isn't enough if every website breaks because of it. If you want a headstart, I tried forking webkit and do exactly this. Project is unmaintained because couldn't work fulltime on it without funding. Maybe somebody else picks it up? [1] [1] https://github.com/tholian-network/retrokit

In Introducing a terms of use and updated privacy notice for Firefox

cookiengineer·May 29, 2024

I would continue to (re)build my decentralized Web Browser network, which aimed to combat fake propaganda, fake news, shit storms etc by creating evidence trails and by correlating articles with similar or opposing entries. That, and a lot of nice things you can do when you have trust ratios of local/global peers, more efficient bandwidth usage etc. Anyways, long story short, needs lots of time and money to build something like this. But seeing how messed up Mozilla's future plans are, I really think someone should do it. After I got doxxed by kiwifarms, /pol/ and others I decided that I have to fix the cybersecurity problem first before I can go back to this. [1] (prototype) https://github.com/tholian-network/stealth [2] (privacy focussed fork of webkit) https://github.com/tholian-network/retrokit

In Ask HN: What would you spend your time working on if you didn't need money?

cookiengineer·Sep 22, 2023

That's what I did with WebKit [1] because it turns out servo is not as modular as it was before. And Gecko is the definition of monolith, so removing the attack surfaces is impossible, even TOR has a crappy replace-with-stubs approach that breaks with every internal API or bridge change. Need contributors and other maintainers though, because keeping up with upstream is impossible as a single dev. I tried to document the attack surfaces [2] from my cyber security perspective as good as possible, with tasks left to do and which need to be eventually removed. It's probably pretty opinionated because I want to use RetroKit as the webview for my own Browser Stealth which acts as a filtering proxy, scraper and decentralized cache [3] [1] https://github.com/tholian-network/retrokit [2] https://github.com/tholian-network/retrokit/blob/main/SECUR

Read the rest

I... [3] https://github.com/tholian-network/stealth (ongoing rewrite in golang)

In I'm fed up with it, so I'm writing a browser

cookiengineer·Aug 7, 2023

The sad state behind KaiOS is that the dev docs are basically useless. There is this guy who maintains bananahackers.net which was a google page for most of the time with all kinds of instructions to get debugging other webapps going, but if you have a device without the GSM code unlock support then it's kind of useless. The Firefox debugging support from old ESR versions (pre ~42 versions) are super outdated and don't work anymore if the rest of the system is updated, because they heavily rely on the android-tools, so making them work with a snapshot of an 8 years outdated linux distro is also very painful. I had a nokia 800 tough for a while, and I was having a gaia fork which you could install on it, together with the system apps. Backups of it still there in case anyone is interested to reboot a fork, I gave up fighting against the DM

Read the rest

CA bullshit takedown requests coming from everywhere, because it's just not worth my time anymore. WhatsApp support was kind of weird because they built a custom web client which somehow worked, but not inside Europe and only globally (e.g. when traveling abroad), so I'd assume there was some kind of geo-regional deal with them being allowed to support KaiOS while maintaining their own web app for it. Oh, before I forget it: most unlock procedures rely on the Android kernel rooting technique that has a MediaTek chipset, because the SDK app and root backdoor was leaked a while back. So if you plan on developing anything, you should choose a MediaTek chipset which is a little older (pre-2018 ish). Note that all the FirefoxOS based WebIDE-reliant workflows require a Mozilla Firefox from before the Certificate Authority fuckup in 2020 when they bricked _all_ extensions irreversibly, including the ADB helper extension which you have to fork and modify to get it to run again. This also means that any time your system is having a date time set to post 2020, you're done and nothing works again. I wrote them together on the blog, not gonna link it though because of DMCA bots. As feasible alternatives there's a bunch of other projects which started using WebKit, Servo and others; but either are dead by now or are unmaintained. I'm gonna link them here just in case you're interested in those. I did my own fork called RetroKit a while back, with a different focus on Privacy; which was coupled on my Pinephone with an ArchLinuxARM kernel and autostarted to host the webapp/"app screen" of my pentesting tools. This was done using a simple systemd service that autostarts the web service for controls and the UI as a fullscreen GUI window process with Restart=always. [1] (unmaintained boot2servo) https://github.com/fabricedesre/servonk [2] (electron based) https://github.com/webianproject/shell [3] (unmaintained boot2gecko based) https://gitlab.com/nuinalp/open-source/icewolfos [4] (KaiOS hacking page of Ivan) https://sites.google.com/view/bananahackers/home [5] (Not maintained on GitHub anymore due to 4/8chan raids, moved my stuff to my own local instance) https://github.com/tholian-network/retrokit

In Ask HN: Are there any FirefoxOS revival projects, except for KaiOS?

cookiengineer·Jul 12, 2023

The current CVE-2023-37450 seems to be related to the InjectedBundle API, which also allows IndexedDB access. Back in 2021 there was the "history leaking" bug where you could write a little JS code to access the devtools whose window shared the IndexedDB with the rest of all tabs (and cookies, and userdata etc). If you take a look at the recent WebKit commits, it seems like there were a bunch of bugs related to the InjectedBundle, that's why I am assuming it might be a critical RCE that results in yet another use after free in the IndexedDB or related code. Back when I forked off RetroKit as a WebKit fork, I also decided to reduce the attack surface in terms of what is shared across the web contexts. I decided to remove a lot of APIs that I thought were too unsafe, both in terms of tracking and exploitation. [3] [1] https://googleprojectz

Read the rest

ero.github.io/0days-in-the-wild/0day-R... [2] https://github.com/WebKit/WebKit/commits (see also the other release versions, not only main branch) [3] https://github.com/tholian-network/retrokit/blob/main/SECURI...

In Ask HN: What happened to Apples “rapid response” security updates

cookiengineer·Mar 18, 2022

I don't understand why this is news? Spyware watchdog posted about this years ago. It's been in there at least since 2016, and every time you open Firefox (not start!) it will happily broadcast its geo position information to their geolocation backend. The same goes for the WebRTC related STUN servers, which are always connected to when Firefox starts. I mean, come on folks. Never trust any software blindly. Use MITM proxy to verify. Use a host firewall like opensnitch. For the moment the best alternative is ungoogled chromium with ublock origin, even though the CSP headers cannot influence the DNS resolver mechanics in the CEF code. I am still busy forking webkit into retrokit and it's a shitload of work to remove these tracking features. [1] But a project like this needs more privacy like minded people. I mean, even the TOR people kind

Read the rest

of gave up on this. Just look at their codebase, trying to stub everything anew with upstream changes. There's no point in trying to race against chrome in "whose browser has the most features", you can't win anyways. I don't care about WebGL or WebGPU, I don't care about WebRTC, I just want privacy back. [1] https://github.com/tholian-network/retrokit

In Each Firefox download has a unique identifier

cookiengineer·Mar 14, 2022

OP's setup looks actually pretty similar to my one, though where the pinephone really - really - shines is pentesting. The compatibility with external Wifi USB adapters and BT hardware like the ones from scott's gadgets make it an amazing pentesting device. For serious mobile-friendly usage I don't think that we can build UIs the way they're built on Linux systems anymore. I challenge every defender of that GTK/QT crap to build a swipeable sidebar into their native and responsive UI. If it takes more than 10 minutes, you lost, cause that's what it takes to use CSS, even without any IDE or toolkit. I wish GTK wasn't built inhouse and would focus on using established toolchains instead of reinventing their own programming language ecosystem with every new release. Nobody wants to use vala. Nobody wants to use glade. Nobody wants to use any

Read the rest

of the ecosystem, because it's much more pain than any established UI framework's methodology. There's a reason why everyone uses electron, and the reasons are not the same why you think your GNOMey toolchains matter. And this has to stop. Otherwise everybody will hop on QT at some point. I still hope that webkit, javascriptcore and nodejs can be combined into something that allows to easily call C-ABI compatible libraries without 300MB of build size like electron. [1] [1] https://github.com/tholian-network/retrokit

In My Pinephone Setup

cookiengineer·Mar 6, 2022

Yep, I did the same. Currently, I am still building my own fork of WebKit (RetroKit [1] ) that removes all attack surfaces it still has (e.g. canvas, webgl, webaudio, applet and embed support, pdf plugins...you name it). I realized at some point that all bridge concepts are super buggy, in Gecko, in WebKit, in Blink...and the only way to reduce the attack surface is to remove the featureset. Tried to do the same with chromium and gecko before...but arguably both projects come with so much overhead (repo tools, hardcoded git urls everywhere, custom clone scripts for each platform and environment etc) that they're inforkable. Take a look at projects like nwjs, where the maintainer has to go almost insane trying to keep up to date with upstream...and he basically didn't change anything else than the public headers to be able to embed chromiu

Read the rest

m more easily. I don't need WebGL to browse websites. If I want to visit a web experiment I can still use ungoogled chromium --user-data-dir=/tmp/... As for the alternative in the meantime: I'm using ungoogled chromium with my own Browser Extension [2] to block off all tracking and filtering/rewriting the actual content. [1] Still WIP. Would love to get more people on board: https://github.com/tholian-network/retrokit [2] https://github.com/cookiengineer/defiant

In Ask HN: Which browser should I migrate to, away from Firefox?

cookiengineer·Feb 15, 2022

I think that in order to increase privacy and - more importantly - reduce the attack surface of a Web Browser more efficiently, there will have to be two modes of web browsing. Regular browsing - in my opinion - should default to privacy and security first, whereas trust to web apps should be granted on a per-domain basis. This is basically what I'm doing in a crappy manner in Chromium and Firefox, where I have all my Browser Extensions in regular browsing mode with uBlock Origin, Cookie Autodelete and whatnot... and where I use Incognito Mode to use Web Apps. Additionally, I believe that a Web Browser that's decentralized has an almost infinite amount of advantages when it comes to bypassing censorship, increasing trust and the ledging aspect of (temporary) online resources. My idea of building a sane architecture of a Web Browser is tha

Read the rest

t the Browser itself is actually a locally running peer-to-peer web scraper service, and the "frontend or GUI" is a bundled webview that's pointing to localhost:someport. Web Apps can then be used by spawning a new webview instance that's sandboxed with its profile in a temporary folder, so it cannot infect/spread across the regular profile folder that's being used for the "regular private browsing" mode. This architecture allows all kinds of benefits, as everything can be filtered, cleaned, verified (, and shared with other peers) at the network level before it reaches the webview - whereas Browser Extensions currently cannot filter any HTTP responses because there's no API for that. AdBlockers currently are based on a disallow-list based concept, which means the advantage is always on the advertising side, and by default nothing is filtered; and scammers/blackhats have always the advantage. Once you add it to a filter list, lots of people's machines have been compromised already. But what if AdBlockers change instead to an allow-list based concept - meaning that the Browser maintains a list of resources that are allowed to load per-domain, and the default being just text and images? If you want to take a look at where it's at right now [1] [2], my Browser is open source; and I hope to fund development via a access fees for a peer-to-peer "Knowledge Tracker" that allows to share automations for the web with other peers, aka macros, reader-mode like extraction beacons, and other awesome treats (p2p search and recommendations are basically included in this concept). [1] https://github.com/tholian-network/stealth [2] https://github.com/tholian-network/retrokit

In Ask HN: How you would redesign a web browser?

cookiengineer·Feb 11, 2022

Did you try to breakout using pwnat to get a public port? In enterprise grade environments it usually works :D I think I'd also try to run a UDP tunnel or try to use an amplification redirect on a UDP relaying proxy to get an open port that you can send requests through. Sometimes public DNS resolvers can help to punch a hole through the NAT because their IPs are allowlisted to unbreak secure browsing modes. > re: stealth I forked webkit into retrokit [1] these days and am gradually removing all APIs that could be abused for tracking purposes ... with the idea to create a minimalistic webview that is embeddable in a browser and still is able to parse/lex/render modern HTML5 and CSS4. This way I can later bundle nodejs with the retrokit webview that just displays the Browser UI that's served locally. [1] https://github.com/tholian-network/

Read the rest

retrokit

In Nike.com's robots.txt

cookiengineer·Feb 7, 2022

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 perso

Read the rest

nally 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)

In No-JavaScript Fingerprinting

cookiengineer·Jan 23, 2022

> Not Safari, WebKit. Not WebKit, WebCore. WebCore's API client is broken and leaked IndexedDB transactions into the ObjectStore of the WebInspectorUI. This was kind of bound to happen, as WebCore's InjectedBundle [0] for cross-process communication exposes all kinds of APIs for debugging, which are all dependent on the JavaScriptCore VM's memory/heap and callstack. Things like HitTestResult in order to be able to select an element in the DOM via the WebInspectorUI, for example. InspectorInstrumentations are littered all over the codebase, in the UI Process, Web Process and GPU process. WebGL and Media Codecs could probably result in a similar persistent state across the sandboxes if abused correctly. Source: Forked WebKit into RetroKit, trying to get rid of everything security-relevant that a locally embedded WebView shouldn't need [1].

Read the rest

Still work in progress though. [0] https://github.com/WebKit/WebKit/tree/main/Source/WebKit/Web... [1] https://github.com/tholian-network/retrokit

In Safari and iOS users: Your browsing activity is being leaked in real time

cookiengineer·Jan 2, 2022

What kind of features of electron are you using in the UI? If it's only http/websockets and the UI, you could try webkit2gtk or other alternatives. It's actually quite easy to build a gjs or Qt wrapper on Linux. WebKit(Legacy) from webkitgtk also builds on Windows. I am currently in the process of making WebKit into a webview that only includes websockets as an API, so the long term goal is to have a minimalistic webview that doesnt have everything that a browser has. [1] Maybe it makes sense to combine development efforts? [1] https://github.com/tholian-network/retrokit

In Portmaster – Open-source network monitor and firewall

Showing the 15 most recent of 16 sources. Enable JavaScript to search and browse every indexed mention.