4 ms·

If I were an online advertiser or a company selling to online advertisers, I would be happy with these findings. If I were a user concerned with privacy and tr

If I were an online advertiser or a company selling to online advertisers, I would be happy with these findings. If I were a user concerned with privacy and tracking I might wonder why the authors of the HTTP/2 standard did not make any efforts to address this type of fingerprinting.

deleted 9y ago
[deleted]
txdv 9y ago
If you look at all the interested groups contributing to http/2, maybe you will get your answer.
jhgg 9y ago
Because doing so is not something that the authors of the HTTP/2 standard need to do. This fingerprinting is just sniffing settings negotiated between the client/server, and comparing them to a known list of preset settings for a given browser. I think allowing these settings to vary is a generally good idea, as the best values for these settings aren't really able to be determined ahead of time, without trying a bunch of different configurations out and collecting real world data. Whenever there is a variation of configuration options between implementations, fingerprinting will be possible. These configuration options are fundamental to how http/2 works. Differing vendors may arrive at differing configurations based on what they believe to be the "best" set of options to use. If I was an online advertiser, or a company selling to online advertisers, these findings would be mostly irrelevant to me (outside of anti-spam/abuse), as for the 99.99999% use case, the user agent string is probably correct. It's worth mentioning that there is not enough entropy in these fingerprints to be used as a "super cookie" but rather to just determine whether or not a user-agent string is probably spoofed, by comparing the settings negotiated by the client to settings that the given user agent is known to negotiate. This is a smart approach to determining whether or not a user agent is spoofed, which has its uses in anti-spam/abuse, but a fairly sophisticated adversary could also just have their client send the same settings, and packet sequences as the user agent it is trying to spoof.

deleted 9y ago

[deleted]

txdv 9y ago

If you look at all the interested groups contributing to http/2, maybe you will get your answer.

jhgg 9y ago

Because doing so is not something that the authors of the HTTP/2 standard need to do. This fingerprinting is just sniffing settings negotiated between the client/server, and comparing them to a known list of preset settings for a given browser. I think allowing these settings to vary is a generally good idea, as the best values for these settings aren't really able to be determined ahead of time, without trying a bunch of different configurations out and collecting real world data. Whenever there is a variation of configuration options between implementations, fingerprinting will be possible. These configuration options are fundamental to how http/2 works. Differing vendors may arrive at differing configurations based on what they believe to be the "best" set of options to use. If I was an online advertiser, or a company selling to online advertisers, these findings would be mostly irrelevant to me (outside of anti-spam/abuse), as for the 99.99999% use case, the user agent string is probably correct. It's worth mentioning that there is not enough entropy in these fingerprints to be used as a "super cookie" but rather to just determine whether or not a user-agent string is probably spoofed, by comparing the settings negotiated by the client to settings that the given user agent is known to negotiate. This is a smart approach to determining whether or not a user agent is spoofed, which has its uses in anti-spam/abuse, but a fairly sophisticated adversary could also just have their client send the same settings, and packet sequences as the user agent it is trying to spoof.