Fingerprinting thread, postal edition.
Previous thread: >>55307092
ReCAPTCHA probably contains fingerprinting code:
https://archive.is/9K5gs
This means that the majority of 4chan users could be being fingerprinted, and Google might know about your shitposting habits.
To fix this you can get a pass (which allows you to be tracked by 4chan in a different way), or run 4chan with the no JavaScript CAPTCHA (use 4chan X to make 4chan without JS bearable).
Daily reminder to do all your Facebook / Youtube / LinkedIn / botnet shit in a completely separate browser to your Googling or buying shit.
It's currently the ONLY way to truly defend against fingerprint tracking.
Double points if you have each browser running in a different VM with a different OS.
Triple points if you have each browser's VM configured with a different VPN.
The Tor Browser Bundle is still susceptible to many fingerprinting attacks that can uncover your true OS and browser.
Spoofing your user-agent is counterproductive unless you use a different user-agent for every site, even if you rotate them every x HTTP requests.
Is fingerprint spoofing the future?
Or is it too difficult since there are so many tests, some difficult to spoof, and new tests being created constantly?
Is it really necessary that we spoof our whole fingerprint, wouldn't partial work, at least until the trackers caught on?
Do the Tor browser guys have the right idea with trying to give everybody the same fingerprint?
>>55328857
Wow, that's probably the first picture I ever saw when I first came to 4chan.
>>55308259
That's a terrible idea. It has to actually detect tracking to learn and block stuff, and it will only do so if you send a DNT header. There are forms of tracking that are undetectable on the client side, but that we have rational reason to be wary of. An additional list based blocker/trafficshaper that resists being detected by website software is a good idea.
>>55308381
The FoxGloves extension worked quite well before the developers were bribed to stop updating it.
>>55312772
NoScript has a unique ability to sanitize inline scripts. It is useful to run it in permissive mode along with uMatrix in blockbydefault mode for that function.
https://github.com/gorhill/uMatrix/issues/276#issuecomment-206000184
>That is pretty damning of NoScript's author
It's also good demonstration of how your browser handles such a case.
https://news.slashdot.org/story/16/06/29/2038257/googles-my-activity-reveals-how-much-it-knows-about-you
>Google's My Activity Reveals How Much It Knows About You
Somehow I doubt they're telling us everything.
I think this is just a limited hangout.
What I want to see is every website they've tracked me on, but this just shows obvious stuff like what youtube videos I've watched.
>>55328999
>NoScript has a unique ability to sanitize inline scripts.
What does this mean exactly?
>>55329726
Part of it's ant-XSS thing.
https://noscript.net/features#xss
It detects injections by scripts from one domain into content from another, and can do things like block it, block it at first but reload without blocking it, and strip out just bits that are likely naughty code in the hope that it still works. It can do this between all domains, only trusted domains, untrusted->trusted or vice versa, depending on how you configure it. And there are recommendations out there about how to set it up. This is something no other javascript blocker can currently do, and the main reason it's so slow. If you set it up to trust all by default and cascade permissions with anti-XSS turned on, it will do just that stuff, and let you manage other script/element blocking with uMatrix, which will still work fine. In principle, I suppose InjectionChecker could be also be reworked to detect and alter fingerprinting code to not fingerprint but still run in some cases, but it would take a huge amount of knowledge about javascript and fingerprinting, and a fair amount of time.
>>55309495
What if you overrode every single native JS function that returns a basic type to report slightly sane but mostly random values on a per tab basis depending on the origin domain of the script, and flat out disabled certain JS features, like most of the support for HTML5 drawing, audio and video objects, WebRTC, etc?
>>55314236
Is there a database of valid fingerprint profiles somewhere that a randomiser could be built on?
>>55330766
>overrode every single native JS function that returns a basic type to report slightly sane but mostly random values on a per tab basis depending on the origin domain of the script
I imagine that would break tons of websites.
I think they can only do it for canvases and such because the results are already a bit fuzzy and not pinpoint accurate
>>55330766
>Is there a database of valid fingerprint profiles somewhere that a randomiser could be built on?
I imagine most sites like Browserprint have privacy policies that prevent them from publicly releasing their databases.
They'd probably need to change that and then collect fingerprints for a year or so to get a usable database.
>>55331272
>I imagine that would break tons of websites.
Less than disabling javascript altogether. With the ability to override every such function, I could imagine an extension to manage when and which ones actually are based on the domain they run in, the toplevel domain, all according to current knowledge of their potential to expose entropy. Basically putting some equivalent of blocking/deleting cookies, which can also break sites, but for fingerprints back in people's hands as a last resort. Also, no single fingerprinting exploit presents a clear picture. They all offer bits of entropy. With enough of them, the overall picture becomes precisely accurate, especially when combined with IP. There are even algorithms to predict the natural drift in fingerprints as settings and hardware change, and can potentially track users across those changes between IPs.
>>55331312
I would expect one could be generated in much the same way a dependency tree could be generated. This version of firefox only supports these versions of Adobe Flash given a Windows 7 SP1 environment, and so on.
>>55330766
I haven't read the whole paper but there's a paper about this kind of stuff.
>PriVaricator: Deceiving Fingerprinters with Little White Lies
>http://research.microsoft.com/en-us/um/people/livshits/papers/pdf/www15.pdf
Seems like they randomised offsetHeight, plugins, and fonts.
I wonder if their extension is available to the public
>>55332339
Reading through this, they bring up a good point. Most sites only use a tiny subset of javascript and it's access to the DOM, HTML5 objects, etc at all. A well designed crawl could identify an inclusive subset of the javascript API covering, say, the Alexa top 1000. Disabling all but that subset by default and implementing randomization for member functions of the set with high entropy potential could be a lot less work for one developing a new blocking tool. It would also be interesting to see the distribution of the frequency of high entropy function/object use among sites according to traffic, say if the top 20 sites contained a greater usage percentage of currently recognized high entropy functions and objects than the remaining 980. Certainly a site using functions outside this set abundantly would warrant caution, and possibly review, even if it was a new code from a popular site.
>>55332765
In the interim, I suppose you could just block the domains of the entire Alexa top 1000, and make an extension that opens attempted navigation attempts to them to another browser, say an almost vanilla chrome installed in fresh win7 install VM. Almost being that it blocks anything not on the Alexa top 1000 with ABP or something.
