stealth

nses especially not when chunked encoding can be a requested thing. Don't get me started on the ";q=x.y" value headers, they are buggy everywhere, too. For my browser project, I had to build a pcap (tcpdump) based test runner [2] that can setup temporary local networks with throttling and fragmentation behaviour so that I have reproducible tests that I can analyze later when they failed. Otherwise it would be a useless network protocol test that's implementation specific as all others. I think the web heavily needs a standard HTTP test suite, similar to the ACID tests back then...but for malicious and spec compliant HTTP payloads combined. [1] https://github.com/tholian-network/stealth [2] https://github.com/tholian-network/stealth/tree/X0/covert

P-NAT could also be censored when it comes to blocked websites, modified DNS responses etc). At this point it's a big experiment and I'm not sure whether I'm fundamentally wrong about this as I don't have any data to back it up. If you're curious, it's part of the Stealth Browser I'm building [1] and [2] [1] https://github.com/tholian-network/stealth [2] https://github.com/tholian-network/stealth-vendor

delivering network with a trustless cryptography based peer-to-peer end-to-end encrypted statistically-correct cache is certainly feasible. I believe that because that's exactly what I'm building for the last two years [1]. [1] https://github.com/tholian-network/stealth

ave domain name conflicts. I think there's also a huge misconception about what DNS-based service discovery is. In DNS-SD, there are questions to a service identifier with a PTR inside, and the response contains A,AAAA,SRV and TXT entries to describe everything you need to know to make a connection to the correct host, ip, port and version of the service. Airprint, airplay, airscan and others additionally use their service name as a prefix in regards to the IANA-registered service names [2] so printers, scanners and other Multicast-DNS compatible hardware never conflicts with the existing network. /ragecomment Personally, I would actually embrace the use of .local, because it allows you to build a self-discovery service that is unrelated to DHCP and unrelated to ARP mechanisms, and works peer-to-peer; as long as the IPs are in the same NAT or, with IPv6/UDP6, have at least one discoverable scope. In DNS-SD, you literally just have to be able to reach other IPs, and you have a working handshake mechanism to discover other devices without having to know their hostnames, IPs, or anything. It's pretty amazing once you realize its network automation potential. Source: Me, building a web browser that uses peer-to-peer TLS encryption on "username._stealth._tcp.tholian.network" and "username._stealth._tcp.tholian.local" [3] [1] https://www.ietf.org/rfc/rfc6763.txt [2] http://dns-sd.org/ServiceTypes.html [3] https://github.com/tholian-network/stealth

point they're just portrayed like TOR, as a tool for evil rather than good; because the politics will get involved when power shifts to quickly for them to compensate. DNS over TLS just gets its 853 port blocked by most ISPs already so it's useless as a tool to shift the means of power here, and only DNS over HTTPs actually makes a real difference because it's way harder to block HTTPS and tell customer's that their internet still works. Given the nature how the web works, how it's transported and how dynamically it's changing in its resources over time - I think it's more important to focus on the idea of statistical truth in the moment, when the specific end user was using it. Some moments afterwards the same URLs change anyways, so it's important to preserve the resource's timeline - but not back until the dark age. Most parts of the world don't have the bandwidth to download gigabytes and still have crappy 2G slow and even lower network speeds. So a blockchain for a single website isn't a good idea to begin with. As a user I also don't know how hashes work, but I know how URLs work. URLs are predictable, hashes are not. The real strength of a peer to peer system is not only ledging, it's also offloading of network traffic. Every cached download that's offloaded via a closeby peer's cache is another tracking prevented. Every request that looks and behaves like Chrome's rendering engine on Windows/MacOS is another user saved from network fingerprint identification. Privacy is not keeping things to yourself. Real Privacy is looking like everybody else. For my own Browser I've decided to push the boundaries a little by implementing those features with the primary goal of being able to make the web work when you're offline or just connected to trusted peers (that have the URLs already cached). [1] And I'm honest here, it still needs a lot of work. Not only is JS malicious, but HTML/CSS has to be assumed to be malicious as well due to all specifications making it possible to identify people just by using CSS and background images or by simply making the website unusable with tricks like overflow:hidden or opacity:0, so these malicious parts have to be filtered out as well. Also: You don't need custom network protocols there. You don't need to roll your own crypto. HTTP, WebSockets and TLS are already peer to peer. The only thing missing is a decentralized way of cross-signing certificates and the ideas behind TLS notary could make the real difference in peer to peer networks. [2] [1] https://github.com/tholian-network/stealth (highly alpha) [2] https://tlsnotary.org

th of peer-to-peer is not decentralization; it is federation and liberation. [1] https://tholian.network [2] https://github.com/tholian-network/stealth

that is able to emulate fingerprinting, and sticks them to specific domains and their originating uncached CDN requests so that if you have the same IP for the same website, they cannot correlate it to ptevious visits. The most effective way to not get tracked is to not visit the website. And I think that there's a huge potential in offloading traffic to peers that have the same URL already in their caches. Peer-to-peer Browser Caches would fix so many issues on their own, I don't understand why nobody is doing that. To the end user it doesn't matter where the assets come from, as long as the website is rendered in the same way afterwards. [1] https://github.com/tholian-network/stealth

for others. It has the idea to act as a web filter service + a webview to render its UI rather than being a render engine and document engine. [1] I hope that with this market niche there's a way to make this kind of effort sustainable for the future, because all other web browser fork projects I've seen so far are dying off due to no funding and too much work to maintain the codebase. It's just not feasible to compete in the everday user's browser market. Lots of companies have tried, and lots of companies have failed. [1] https://github.com/tholian-network/stealth Edit: Clarification of Chrome vs. libchromium

tes and behaviours. For my own Browser Stealth [1] I had to create a testsuite because I couldn't find anyone that's not related to known SSL attack vectors. Due to the peer-to-peer concept I decided to test network behaviours wherever possible. The network protocols themselves (when speaking of RFCs) are just not tested, and freely interpreted at will - even in older projects like apache, caddy, curl, libaria and others. When reading the curl codebase you'll soon realize that it is a huge collection of hacks he had to implement just to make things work when the servers were behaving incompliant to the specifications. [1] https://github.com/tholian-network/stealth