HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
tholian-network
stealth
JavaScript2020–2024
tholian-network / stealth

stealth

:rocket: Stealth - Secure, Peer-to-Peer, Private and Automateable Web Browser/Scraper/Proxy

7Distinct people
54Mentions
0Explicit recommenders
1.2KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

:rocket: Stealth - Secure, Peer-to-Peer, Private and Automateable Web Browser/Scraper/Proxy

GitHub

Where it is used

No documented product use has been verified yet.

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

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

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 7:24:48 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 year54 dated mentions

Observed mentions: 2020-04-20 04:03:44 UTC to 2024-10-24 11:33:00 UTC.

051015202020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 22 mentions; 1 submissions, 21 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 21 mentions; 0 submissions, 21 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2024

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.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC22121
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC21021
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC505
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC303
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC303

What Hacker News says

22 sources
> The underlying nexus is that our ideals on free speech do not take into account human wetware bandwidth. Damn, this is such a good metaphore, I had to think a lot about it. For my browser [1] I wanted to introduce a fact gathering and linking system, and build it in a way that bias of authors (and publishers) can be guessed when they release a new article. My theory is that Rationalism will never be anything that can exist, because it is the opposite of human nature (or say, the founding idea of our society). The underlying issue is that emotions cause a lot of people to get irrational due to them not being able to differ a potentially dangerous situation with a potentially (equally) good one. I think that most (if not all) of fake news websites were shared because of only a couple of reasons: 1) Humans like to get reinforced in their o
Read the rest
wn perception more than they like to get disagreed with. 2) Articles in these type of publishing mediums appeal to emotions rather than to facts, hence the reason for why they use pictures, videos and other recordings as "evidence" even when they had totally nothing to do with it. 3) Humans are lazy. This is by far the most important point. If it is easy to comply with an emotional statement, and hard to gather evidence to disprove it; the emotional statement will always win. 4) Humans confuse disagreement with punishment. As a kid you get taught that there are negative effects when you disagree with society, or your mum/dad or other authoritarian figures. Rather than to punish kids when they are wrong we should encourage the gathering of evidence, and let them form an argument for both sides. 5) Humans are beings that forget. That is why media for the masses reuses pictures of a situation that happened years ago as "proof" for something clickbaity. Most people won't remember it if it was a situation that had a boring outcome, but they certainly will remember it when it had a negative emotional effect on themselves. 6) Depression is a huge hole where nobody without external support can come out, due to how our thinking nature works. Similar to 5) our brain is wired to remember negative punishments more than positive reinforcements, and that is why we tend to get depressive more likely than we tend to get optimistic...which in turn plays in the cards of fake news because the bad obvious enemy could do some serious bad thing to us. But yeah, these are just my two cents. Due to my browser I thought a lot about this and came to the conclusion that irrational hate speech is worse an enemy than someone might think on first sight. [1] https://github.com/tholian-network/stealth
In Voat Is Shutting Down
I have three questions for you: 1) I am building a browser [1] for the semantic/static web, would I be allowed to integrate this as a search alternative to searx.me and wiby.me? 2) What's your policy on submitting URLs? Do you support opengraph descriptions? Do you support dublincore (which would be awesome)? Should browser users be allowed to submit things they couldn't find? 3) I couldn't find detailled API docs, only the opensearch description. Do you have a JSON API that would help reduce the load of your web servers? Also, what syntax do you support? [1] https://github.com/tholian-network/stealth
In Mojeek: Independent search engine with its own spider
I own a Pinephone with the latest revision board which was bought in the July 31st batch this year (and got shipped in September/November within the EU). I have to say that hardware-wise, the Pinephone got very _very_ far already. It's an amazing hacker's device, especially with the USB-C host. The only issue that persists is software. Phosh is pretty much useless because not a single app will work as a real mobile app, let alone act in a responsive manner with their underlying design philosophies. It all feels like Android 1.x, which was barely useable outside the context of shitty car navigation handhelds. The available cross-compiled versions of Browsers (e.g. Firefox or Chromium) are totally broken, as they are made for Desktop and do not even downscale their user interface, and are neither responsive anyhow. So for now, I am using my
Read the rest
own (prototypical) Browser Stealth [1] due to lack for alternatives because there at least the UI doesn't crash every few seconds when being used within a WebKit2GTK webview. I don't have many requirements for my phone, to be honest. I don't use social apps, and only communicate via telegram. But currently the amount of software that's available for phosh is still the one reminding me of a developer environment or say, an Android emulator image. I seriously thought about taking ownership in creating a few apps for it, like one for openstreetmaps, notes, text editor, which are the more important ones for me. But to be bluntly honest, I don't even know where to start with the whole GTK shitshow. It's absolutely impossible to develop an app without any working examples. There's no non-auto-transpiled-bindings-documentation, there's no libhandy examples that actually work, and there's certainly not any responsive GTK app examples that would show how to make a "real mobile" app. How do people develop apps for mobile GTK? Seriously, I cannot understand it. I want to, but there's no way anyone can keep the mood up digging through a _mobile phone's gdb output while the on screen keyboard crashed_ to figure out how the API works. I think what GTK really needs is something like Electron, but maybe based on WebKit2GTK and (maybe?) gjs. Something that allows bundling your assets to build an app that is offline-ready, and is easy to build with common methodologies of UI frameworks. Because currently I don't see the reason why libhandy exists. It tries to fix a problem, and doesn't fix the underlying cause. GTK boxes and their layouting (and reflow?) concept just isn't made for an adaptive/responsive UI, so you'll always end up with a totally broken UX by modern standards. (You're welcome to challenge me on this, but as long as "make a sidebar that can fade-in/fade-out with a swipe" takes more than a week to build, I think you're wrong.) [1] https://github.com/tholian-network/stealth
In Librem 5 Evergreen vs. Pinephone
When comparing my ideas for stealth [1] with this, I found that a lot of people assume that a local browsing data cache makes them vulnerable. But, I think that a browsing cache makes peer clients stronger, because they do not have to make so many (potentially trackable) requests to a web server anymore. Any request shared is another tracking prevented. When it comes to signalling from HTML content, I think the web is kind of broken. Sure, we have RSS (it was great!) and we have opensearchdescription, and dublin core as a metadata initiative. But what I think is missing is a way to extract the real content from the website. Imagine a real working and defined "reader mode" that's integrated as a standard, including all the metadata like topics, keywords etc. It would save so much computation time when thinking about all the SEO fraud that'
Read the rest
s happening these days. Of course, incentives are always clicks, traffic, and tracking. Therefore nobody will implement it until forced to by Google or Facebook. I decided to focus primarily on automation of extraction, because I think it is a necessary step to solve in order to reach a higher plane of knowledge automation. [1] https://github.com/tholian-network/stealth
In Bombadillo: a non-web browser
Do you know maybe whether there are similar adoption rates in HTTP/3? As someone that implemented http/1.1 almost feature complete [1], I think that the real problem on the web is the missing of a testsuite. There needs to be a testsuite for http that both clients and servers can test against, and that is not tied to internal codes of a web browser. I say this because even a simple spec like 206 with multiple range requests literally never is supported by any web server. Even Nginx, apache or google's own dns over https servers behave differently if the request headers expect multiple response bodies. Let alone the unpredictability of chunked encodings, which is another nightmare. I really think that there should be an official testsuite that is maintained to reflect the specifications, similar to the intention of the (meanwhile outdated)
Read the rest
acid tests. Adoption rates to new http versions will always stay low if you implement it for months exactly as the spec says, just to figure out that no real world webserver actually implements it in the same way. [1] https://github.com/tholian-network/stealth/blob/X0/stealth/s...
In Blink: Intent to Remove: HTTP/2 and gQUIC server push
I saw that you updated the readme to include that it is based on other browsers, great! The feature list still seems intact though, so if that is intended to represent the current state perhaps you can help me understand these points (And please forgive me if you just intended to update it later): --- > It uses trust-based Peers to share the local cache. Peers can receive, interchange, and synchronize their downloaded media What is a trusted peer? How is trust established? > It is peer-to-peer and always uses the most efficient way to share resources and to reduce bandwidth, which means downloaded websites are readable even when being completely offline. What P2P tech is used here? Again, how is trust handled for resources downloaded over P2P networks? > The Browser is completely free-of-DOM Is createElement, appendChild and similar other
Read the rest
methods used here not part of the DOM? https://github.com/tholian-network/stealth/blob/1efe80f8baf6... --- I'm saying that if you make extraordinary claims you will need extraordinary evidence. Or say that they are ambitions until you can produce that evidence, which is completely fine!
In Stealth – Secure, Peer-to-Peer, Private and Automateable Web Browser
Their claims around privacy seem pretty hand-wavy to me; I’d love to be wrong. As an example, their usage of DNS is simply DNS-over-HTTPS against the big public resolvers in a round-robin fashion: https://github.com/tholian-network/stealth/blob/X0/stealth/s... The code doesn’t strike me as concerning itself with protecting privacy so much as changing who will get to log your traffic. Interesting effort though; I’ll hope for more details from them in the future!
In Stealth – Secure, Peer-to-Peer, Private and Automateable Web Browser
> I think that's what issues and milestones are for. I tried to document as much as possible. I agree, but then those should not be mentioned in the readme as "Features". Are there any things mentioned in the readme in present tense that are not currently implemented? > Please don't confuse a Browser with a Browser Engine. I never claimed to replace WebKit, Blink and neither Gecko. In https://github.com/tholian-network/stealth/blob/X0/browser/b... you spawn chromium (or other browsers). Chromium is a browser. I'm not saying that you have to fork or implement a browser, I'm just saying that if you wrap an existing browser it's best to be upfront about it and not make it sound like you have implemented a browser. I wouldn't have objected if the readme said something like "It uses chromium/electron or other browsers under the hood" at the be
Read the rest
ginning. This is especially critical if you claim improved privacy or security. > For now, I, as a single person working on the project I'm not complaining about the quality or the scope of the work. I'm saying that what the readme presents as the current status of the project does not match reality.
In Stealth – Secure, Peer-to-Peer, Private and Automateable Web Browser
Woah this is actually very nice, very nice indeed. I'm currently building my own HTML5 parser for my browser stealth [1] and I aim to be spec-compliant with it, and this might come in very handy for testing against. What I kind of miss with SGML as a feature is something similar to XSLT stylesheets that can transform chunks of a website into another chunk. Currently I'm kind of reinventing the wheel here due to my optimizer having the idea to "upgrade" websites on the fly before they get to the client. If all websites were XHTML1.1 strict based, that part would have been so much easier. [1] https://github.com/tholian-network/stealth
In DOMPurify bypass: XSS via HTML namespace confusion
This is so true, the two dimensions allow such a nice simplification of what should be rendered even in UX terms. What I personally didn't like about it though are the tech specific parts (e.g. xhr and other both require script anyways, as not a single website will work with xhr disabled). So for my browser project [1] I decided to split it up into "text", "image", "audio", "video" and "other" which I hope will make more sense for most people. Back in February when the debate about the manifest and requests api started, I started my own semantic browser project which aims to filter out all UX-interfering CSS and HTML and probably won't allow JS anyhow. It tries to focus on the automation and caching parts that are broken in current web browsers, so that everything is peer to peer, and that other trusted peers can be used to share bandwidt
Read the rest
h, content, or metadata with each other and that each one has a 100% persistent local cache that only gets refreshed once the user tells the browser to. If there'll be a need to support webapps later, they will probably be sandboxed in a new window that represents a temporary cache located in /tmp/... in order to prevent abuse of local storage and cookies. I've learned to not trust any site these days, even my bank's website uses foreign overseas-located trackers, which is technically a GDPR violation. [1] https://github.com/tholian-network/stealth
In uMatrix has been archived
A little fact I wanted to add here: tables are unspecified when it comes to their display model. All display models have been changed to reflect the flow model (e.g. display: inline-block means display: inline flow-root behind the scenes). But the funny thing is: they forgot to specify display: table and everything in it. If you're interested in all the values that are only buried down somewhere in the specs, I'm building a CSS parser [1] that probably will never be completed. [1] https://github.com/tholian-network/stealth/blob/X0/stealth/s...
In Kosmonaut: web browser from scratch in Rust
Nyxt actually looks very nice. Very nice, indeed. I really like the navigational features, because they seem to be both memorable and predictable based on the layout that you're seeing (whereas others like vimb are totally unpredictable in their behaviour). When it comes to making the web usable again, with less cache busting being enforced on the client's browser, I guess we share similar goals. I'm currently trying to solve it via peer-to-peer services and the idea of trusted peers - that also function as caches in the local network and e.g. share download streams with each other once a huge file is being downloaded by a trusted peer. [1] Personally, though I've been using VIM for as long as I can code, I would not agree that we need another browser that's keyboard-navigated. For me, the understanding of websites and the semantic automa
Read the rest
tion aspect is far more important so my UI/UX ideas are different. I'm trying to automate by recording user interactions rather than automate by keyboard shortcuts. The underlying idea is that any non-programming user can automate their own actions on the web. [1] https://github.com/cookiengineer/stealth (currently a PWA with a local node.js process that does all the heavy work)
In How and why I attempt to use Links as main browser
Meanwhile, this is, oh so damn outdated. (I'm not kidding) Most people don't know that the flow model totally changed meanwhile, and something like "display: inline-block" actually means "display: inline flow-root", everything that came after flexbox kind of had an influence to the meanwhile borderline insane display model as a result. Everything related to inset, margin and padding has gotten an overhaul that is ready for ltr and rtl content where they switch x/y flow based on "direction: ltr (or) rtl" whereas e.g. "margin-inline" and "margin-block" are the newer properties for the updated margin. A lot of stuff has changed for the better, too. CSS transforms are now specified in a cleaner way, with a predictable way to render them (e.g. translate rotate will not be different than rotate translate). So all CSS transforms have gotten thei
Read the rest
r own properties like "rotate: 90deg" or "scale: 1.23". I learned a lot when I read through the actual CSS specifications, because I am implementing my own parser (for my Browser [1] project). Also, did you know that @media, @supports and @viewport queries can be nested in any order? The media queries 4 [2] spec is kind of insane from an implementor's view. [1] https://github.com/cookiengineer/stealth and https://github.com/cookiengineer/stealth/blob/X0/FEATURES.md [2] https://www.w3.org/TR/mediaqueries-4/
In Things I wish I’d known about CSS

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

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.