Google says it may have found a privacy-friendly substitute to cookies

• floc

  92 928 1.1 Makefile

  Discontinued This proposal has been replaced by the Topics API.

  

> Google would still retain the ability to uniquely identify individual users.

In the proposal, the non-clustered data does not leave the user's device: https://github.com/WICG/floc

(Disclosure: I work for Google, speaking only for myself)

• ip-blindness

  7 115 0.7

If you want to prevent fingerprinting, you need to look at where the identifying bits are coming from. (ex: https://coveryourtracks.eff.org/) The IP address provides enough bits to uniquely identify many users, and when combined with just a few more bits, to identify almost anyone.

TOR is one solution here, which you could potentially also describe as "adding forced MitM to every connection". The proposals in https://github.com/bslassey/ip-blindness/blob/master/near_pa... and https://github.com/bslassey/ip-blindness/blob/master/willful... have different tradeoffs than TOR, with the "TOR is painfully slow" problem being a big one.

If you have better ideas, though, I would be very interested in reading them!

• SurveyJS

  surveyjs.io sponsored

  Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.

  

• stealth

  26 990 0.0 JavaScript

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

  

> Would an extension that sets random headers be a solution to blurring identity?

Nope, because the way a Browser Engine loads assets is different in Chrome vs. Firefox vs. Edgium, too. "@supports" in CSS is additionally a very unblockable way to track users, too.

Usually traffic analysis for a client (with a specific ETag header) is enough to uniquely find out whether it's the exact same machine, hence that's what the header is made for.

The approach behind my browser tries to actively modify the contents of said HTML and CSS in order to force-cache everything and by laying off as much traffic as possible to surrounding peers. [1] But it's far from production-ready.

There's also a frightening amount of CSS features that can be used to track users very easily. @supports, @media, and a combination of and "srcset" attributes in a quick prototype was enough to track every client with 98.3% accuracy, and I decided to not release the fingerprint.css project due to concerns how it might be used in the wild.

Especially with unicode behaviour inside the CSS files themselves. CSS ident-tokens [2] are specified as "non-ASCII" which can be emojis, too. And those have varying support across all Browser versions. (Remember effective Power? Guess what...)

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

[2] https://www.w3.org/TR/css-syntax-3/#tokenization

Suggest a related project