Fingerprintability #20
Replies: 2 comments
-
Thank you so much for the reply! |
Beta Was this translation helpful? Give feedback.
-
Fingerprinting based on HTTP 2, TLS characteristics alone cannot be reliable: Chrome maybe doing the no-op: |
Beta Was this translation helpful? Give feedback.
-
[ Mohammad M (Free Iran) @ CE 2024-03-31 23:36:06 UTC:
https://remark42.browserleaks.com/web/iframe.html?site_id=browserleaks&url=https://browserleaks.com/http2#remark42__comment-54bc1852-4497-4903-a63e-4c75a5438fad
Can someone please help me with this?
I've been trying to spoof TLS and HTTP 2 fingerprint.
However someone from a company who is doing anti-detect solution says:
“You shouldn't: as it's constant for a browser, or I guess it's constant for a certain version of a browser.
And it's independent from the client machine.”
I need to ensure that using multi-account on a web site undetected.
Can a company identify a client uniquely using Akamai fingerprint?
Or does it represent a browser brand and version only?
If I have different realistic fingerprint (using collected real fingerprints) of other factors (WebGL, ClientRect, fonts, ...) for each of my accounts:
Will they be able to see 2 of my accounts belong to same person based on Akamai fingerprint?
Thanks. ]
----
First off:
|*| Akamai is derived from HTTP 2 characteristics
|*| JA3 is of TLS
; these are not web technologies selves. ("auditing" technologies, perhaps)
It's not constant, but tends to vary unpredictably:
Browser vendors may introduce, inadvertently or not, unpredictable changes on them: as long as no visible breakage observed.
Access pattern related side-channels is the culprit: some are incorrigible technically. (mostly user fault)
Extreme invert. Excess amok.
Too much unpredictability becomes predictability.
Beta Was this translation helpful? Give feedback.
All reactions