floc VS stealth

Draft: https://github.com/WICG/floc

"The browser uses machine learning algorithms to develop a cohort based on the sites that an individual visits. The algorithms might be based on the URLs of the visited sites, on the content of those pages, or other factors. The central idea is that these input features to the algorithm, including the web history, are kept local on the browser and are not uploaded elsewhere — the browser only exposes the generated cohort." Source: https://github.com/WICG/floc

Google (or other third-party tracking) is also not effected by VPN. These groups use cookie syncing to assign you a unique ID and then collect this ID again as you browse the internet. That buyerID can then be cross-referenced (even with other buyerIDs) to generate all sorts of different demographic/psychographic information and used to fingerprint your online life for audience targeting. Google actually is in the works to take this a step forward with the FloC experiment. FloC (Federated League of Cohorts) actually deprecates the Set-Cookie header in favor of in-browser history scanning. Basically, in a year or two they plan to incorporate Chrome into their adtech stack and have it report your history/behavior to Google (regardless of whether you save history or not). Here is some good info on that: https://github.com/WICG/floc

Instead they propose new standards, like HTML Imports or FLoC, and the W3C decides as a whole whether or not they become official standards.

With cross-site cookies, adnetwork.com has full information about what sites you've visited (among sites that incorporate their cookies). This isn't good either! But generally speaking, an individual site using adnetwork.com for advertising won't have or want access to that vector of your interests; many site operators don't even have visibility into what ads win real-time bidding, just that they're receiving money for providing their inventory. Certainly there are players that can provide demographic targeting metadata to site operators, but to my knowledge they are less widely known and certainly not cheap, and I imagine (or hope) any players with wide enough cookie reach would be discouraged from maintaining a database that could associate metadata with PII.

With FLoC, though, the idea was that the browser would provide document.interestCohort() and the individual site's JS could react accordingly: https://github.com/WICG/floc . This means that any site, regardless of its contracts with ad networks, could immediately identify your cohort and associate it with your activity. Web developers working in good faith would be encouraged to have user.cohort or user.topic fields from day one "just so you have it" - imagine all the ways someone could use this in bad faith. Inevitably this data would leak (or be intentionally leaked) and could trivially become a target list for doxxing closeted people. It's a dangerous, dangerous proposal.

You can't find any info about this because there isn't really any. Josh Karlin, who is the maintainer of the FLoC working document, said at an event that it might make sense to swap to topics. It's essentially just reducing the entropy of the cohorts and giving them a more comprehensible (and probably less useful) taxonomy. That's all the info there is.

https://github.com/WICG/floc explains the overall goals.

It's pretty complicated and my understanding could be wrong and definitely not an expert. All the stupid CIA-style names that keep changing don't help. Turtledove, fledge, sparrow lol.

But from what I think I know that's kind of right technically, but kind of not in terms of actual real privacy.

Yes, the actual browsing data, e.g. for the basic floc cohorts only what amazon product page you visited, is no longer 'sent' to ad networks (that's a pretty big oversimplification of how ad networks track you but for brevity). That data is parsed in your browser to generate a cohort ID for you.

But this cohort ID is exposed to the world document.interestCohort() and is what's used for targeting and tracking.

To me it seems that the cohorts are so small "thousands of people" + IP or UA it's basically the same as a semi-long lasting uuid.

Here's an image from google's site.

https://web-dev.imgix.net/image/80mq7dk16vVEg8BBhsVe42n6zn82...

It also seems like Chrome/google might be still defaulting browser settings to give themselves even more data just like they currently do?

https://github.com/WICG/floc#qualifying-users-for-whom-a-coh...

BUT when you layer on the other proposals (Fledge/Turtledove/Dovekey or whatever) - which I don't understand that much maybe someone else can explain - it seems like it basically collect this page/product level data and makes it available to DSP etc for tracking/ad serving (again if not technically 1:1 basically in consequence given the sizes of these groups).

Like one of the proposals talks about a 'trusted' key/value server which doesn't seem that different from what already happens? The original proposal wanted to move the entire ad bid/target/serve process into the browser.

Two years ago I decided to built my own web browser, with the underlying idea to use the internet more efficiently (and to force cache everything).

Took a while to find the architecture, but it's still an unfinished ambitious project. You can probably spend forever working on HTML and CSS fixes alone...

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

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...

Most of the things you mentioned are implemented in the "Browser" that I've built. It's using multicast DNS to discover neighboring running instances and it has an offline cache first mentality, which means that e.g. download streams are shared among local peers.

Global peer discovery is solved via mapping of identifiers via the reserved TLD, and via mutual TLS for identification and verification. So peers are basically pinned client certificates in your local settings.

Works for most cases, had to implement a couple of breakout tunnel protocols though, so that peer discovery works failsafe when known IPs/ASNs are blocked.

Relaying and scattering traffic works automatically, so that no correlation of IPs to scraped websites can be done by an MITM. Tunnel protocols are all generically implemented, DNS exfiltration, HTTPS smuggling, ICMP tunnels, and pwnat work already pretty failsafe.

Lots of work to be done though, and had to focus on couple other things first before I can get back to the project.

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

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.

I think that in order to increase privacy and - more importantly - reduce the attack surface of a Web Browser more inefficiently, 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, 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.

In the future 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.

Currently, my idea of building a sane architecture of a Web Browser is that 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 - 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

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)

Currently my primary motivation factor is my own Browser Stealth that I'm building; and due to lack of alternatives.

I'm building a peer to peer Browser network that relies on trust ratios/factor in order to find out the seed/leech ratio of sharing content, producing content etc.

The problem I'm currently trying to solve is that I had the idea to have a vendor profile that contains the necessary information for IP ranges (ASN, organization, region, country, ISP/NAT etc) so that the discovery service for that doesn't have to do this.

It's like the basic idea of an offline "map of the internet" that should be an approximation of who does what in which amount of data (e.g. data center IPs aren't trustworthy or same ISP-NATed IP could be censored the same when it comes to blocked websites 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

> Does anyone here have a feasible way to solve this?

Current solutions like TOR, I2P, VPNs and/or mobile proxy services are just a matter of time and legality until they come obsolete.

TOR and I2P are worth a shit if everybody knows it was a TOR exit node, and cloudflare shows you tracking captchas anyways.

Same for VPNs and mobile proxies, most are known due to their static IP ranges. Note that most mobile proxy services actually use malware installed on smartphones, so technically you're helping the blackhats by using them, and technically if the federal agencies find out you are probably in some lawsuits filed as an anonymous party that helped them DDoS a victim party.

I am convinced that the only way to solve this is by simply not downloading the website from its origin. The origin tracks you, so don't talk to them. Talk to your peers and receive a ledged copy of it instead.

The only problem is that this contradicts all that came after Web 2.0, because every website _wants_ unique identities for every person visiting them; including ETag-based tracking mechanisms of CDNs.

I think it's not possible with supporting Web Browser APIs the same way in JavaScript (as of now, due to fetch and XHR and how WebSockets are abused for HDCP/DRM to prevent caching), but I think that a static website 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