zlacker

[parent] [thread] 13 comments
1. devwas+(OP)[view] [source] 2020-11-28 21:45:43
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.

replies(3): >>darkwa+A >>user63+H7 >>prezjo+hc1
2. darkwa+A[view] [source] 2020-11-28 21:51:57
>>devwas+(OP)
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
replies(1): >>deckar+I8
3. user63+H7[view] [source] 2020-11-28 23:01:48
>>devwas+(OP)
> 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

replies(1): >>LunaSe+F9
◧◩
4. deckar+I8[view] [source] [discussion] 2020-11-28 23:10:42
>>darkwa+A
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.

replies(2): >>wrboyc+99 >>chaps+gi
◧◩◪
5. wrboyc+99[view] [source] [discussion] 2020-11-28 23:15:07
>>deckar+I8
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?
replies(2): >>gruez+Sc >>nitrog+5g
◧◩
6. LunaSe+F9[view] [source] [discussion] 2020-11-28 23:20:16
>>user63+H7
So are DNS and HTTP caches.
replies(1): >>gruez+La
◧◩◪
7. gruez+La[view] [source] [discussion] 2020-11-28 23:31:59
>>LunaSe+F9
>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).

replies(1): >>eyelid+xn
◧◩◪◨
8. gruez+Sc[view] [source] [discussion] 2020-11-28 23:50:50
>>wrboyc+99
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#...

◧◩◪◨
9. nitrog+5g[view] [source] [discussion] 2020-11-29 00:25:46
>>wrboyc+99
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.
◧◩◪
10. chaps+gi[view] [source] [discussion] 2020-11-29 00:52:31
>>deckar+I8
Yep, `nmap -O` works pretty well!
◧◩◪◨
11. eyelid+xn[view] [source] [discussion] 2020-11-29 01:51:51
>>gruez+La
> 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.

replies(1): >>smiche+891
◧◩◪◨⬒
12. smiche+891[view] [source] [discussion] 2020-11-29 14:21:06
>>eyelid+xn
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.
replies(1): >>eyelid+SI1
13. prezjo+hc1[view] [source] 2020-11-29 14:58:17
>>devwas+(OP)
> your IP is a much better advertising identifier

Citation needed?

◧◩◪◨⬒⬓
14. eyelid+SI1[view] [source] [discussion] 2020-11-29 19:41:42
>>smiche+891
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.
[go to top]