zlacker

This website does not track you. Correction -> This website does not track you via JS. You have no idea what's logged on the backend.

>>s1k3s+(OP)
There are also ways to track you on the front end without JS but I think "This website will not… track you" is just a promise from the not something that followed from the lack of JS anyways.

>>s1k3s+(OP)
Ye olde days of tracking just used invisible .gifs and every click was a different webpage so they just tracked which ones were requested to gain interaction metrics.

JS doesn't have any magic to it, location information is opt-in, but your IP is a much better advertising identifier.

>>devwas+x2
IP behind NAT or CGNAT is not that useful, but many mobile browsers (especially cheap Androids) leak so many trackable details through headers that makes easier to uniquely identify devices/users

>>s1k3s+(OP)
It logs requests to the site, which is far less invasive than the fine detail of browser fingerprinting and tracking that JS allows: JS can see your mouse pointer's position, how long you spent on each area of the page, which parts of the text you selected, and many many other things.

Things like this are seriously creepy: https://www.crazyegg.com/blog/mouse-recorder/

>>devwas+x2
> JS doesn't have any magic to it

Canvas fingerprinting, WebGL fingerprinting, GPU, fonts etc etc etc.

Please, stop arguing, JS is a nightmare for privacy. Period

>>darkwa+73
back in the '90s I was into connecting to IRC servers using spoofed IP addresses. The way it worked is you told the software what OS you were connecting to (or it would figure it out itself, I can't recall). Each OS had a unique way of generating TCP sequence numbers, which allowed the software to guess which number would come next.

Nowadays OSes have protection for this sort of thing. But I'd imagine you could still fingerprint an OS like that. Combine that with TLS, HTTP, etc. specifics and you could narrow it down quite a bit I bet.

>>deckar+fb
How are you going from guessing TCP sequences to spoofing IP addresses on TCP connections? Did you breeze over a step or am I missing something obvious?

>>user63+ea
So are DNS and HTTP caches.

>>LunaSe+cc
>DNS

most people don't run their own resolvers, so at best you're fingerprinting DNS server of the ISP.

>http caches

can be easily cleared, or mitigated entirely by extensions or browser (eg. multi account containers).

>>userbi+m5
You can implement similar mouse recording via requests for :hover psuedoelements in CSS. Also, I’m not sure you need JS to get fine fingerprinting and tracking in 2020— https://wiki.mozilla.org/Fingerprinting

>>wrboyc+Gb
TCP packets contain sequence numbers that must correspond to the ones sent by the other side. This is an issue if you're spoofing packets because you don't receive packets (containing the sequence numbers) from the other side (they will go to the spoofed address, rather than yours). Without the other side's sequence numbers, your replies will be considered invalid, which means you can't complete the handshake[1] to establish a connection. However, if you can successfully guess the sequence numbers, you can complete the handshake and also write arbitrary data to the stream. You still won't be able to receive data, but for simple protocols like irc, it can still be useful eg. connecting to a server and then sending spam to an user/channel.

[1] https://en.wikipedia.org/wiki/Transmission_Control_Protocol#...

>>userbi+m5
There are many companies with similar products: Inspectlet, Lucky Orange, probably more. This is a cat that will be quite difficult to put back in the bag.

>>wrboyc+Gb
The mitigations for spoofing sequence numbers might be different for each OS, and that would allow the OS to be fingerprinted. See nmap's OS fingerprinting, for example.

>>userbi+m5
Heatmaps have legitimate, non-tracking, purposes.

eg: hotjar.com sessioncam.com

Legitimate tools for measuring effectiveness of pages with little in the way of nefarious tracking afaics. Also very useful for replaying user errors/problems.

>>deckar+fb
Yep, `nmap -O` works pretty well!

>>zamada+N1
It could also be a canary in case the site gets bought out, and the new owner wants to implement invasive tracking. If a site has "will not track you" when you visit it, but the next visit it is removed...

>>gruez+id
> most people don't run their own resolvers, so at best you're fingerprinting DNS server of the ISP.

That’s not how it’s tracked commonly. Similar to HTTP caches, you can fingerprint visitors by how quickly a domain request resolves for them. Sure, all of this can be mitigated. But you have to even know what to mitigate. And given the most fanatical privacy folks aren’t aware of basic timing fingerprints is a good indicator that no one is mitigating it nearly as well as they might think.

>>s1k3s+(OP)
To be fair, it might be illegal for them to keep logs. Probably just timestamp, source IP and requested resource.

>>eyelid+4q
If js were removed from the web tomorrow, the people currently working on tracking protection against js could instead focus on these other mechanisms. Because privacy is an arms race, reducing attack surface is not pointless even if the same tracking can be achieved by other means.

>>devwas+x2
> your IP is a much better advertising identifier

Citation needed?

>>smiche+Fb1
I don’t think JS (or some other runtime) could plausibly be removed from the web on any time scale. People have a (reasonable) expectation that they can do app-like things on a network, and that surface area will find its way to manifest one way or another. At least having it on the web has somewhat of a limiting effect on the entrenchment of the biggest (and worst) privacy offenders, because the barrier to entry is lower than building a wide array of native apps.