5 ms·

Wait, so the traditional "use the JavaScript CDN as a cross-site cache" method does not work anymore? How did I not know that!

simonw 5y ago
It was a huge privacy hole: malicious pages could measure how long it took for URLs to load and use that to tell which other sites you had visited in the past.
- colordrops 5y ago
  Weren't the shared libraries used on countless sites though? How would this work?
  - TOMDM 5y ago
    Because you'd make your own library used exclusively for tracking, or check to see if another site specific set of resources had been loaded.
  - modeless 5y ago
    Yes but each site uses a lot of libraries too. The set of libraries and specific versions of those libraries used by a site is a pretty good fingerprint.
    - colordrops 5y ago
      Still doesn't make sense - there is only a single set of libraries - the ones cached by a user's browser, and since each library in that set is used by thousands of sites, there's no way to know which site it was cached for. For each version, there are certainly thousands of sites using it. Since I'm still not getting it, perhaps you could explain how a particular set of libraries is fingerprinted?
      - dmurray 5y ago
        The New York Times uses libraries (versions) A,B,C, and D. Wikileaks uses A,B,D and F. I see that you have A,B,D and F cached - that allows me to rule out the NYT and predict with some degree of confidence that you visited Wikileaks. You can make up theoretical models for how many popular libraries there are, or how many sites, and say this should or shouldn't be possible. I haven't seen any such models, but advertisers were definitely using this technique in the wild so the models that say it's impossible are all wrong. Adding noise to a small sample of requests doesn't buy you that much entropy - the signal is a little noisy anyway.
        colordrops 5y ago
        This would work if you only visited like 5 sites. If you visit thousands, and more like tens of thousands when you consider 3rd party embedded content, you can't figure out which sites a user visits, but rather only which ones they don't.
        EwanToo 5y ago
        It worked pretty effectively. Think about the 10,000s of JavaScript libraries out there, and the 100s of versions of each.
        madacol 5y ago
        number of libraries * number of versions ~= bits of information to classify you A good intuition is that although there's low certainty which site you have visited, there's high certainty which sites you HAVE NOT visited I think is easier to see how you can fingerprint someone based on the set of sites they HAVE NOT visited Edit: I'm not so sure anymore, I think that requires to test looots of libraries, it's not practical unless you are a really nasty ad company that tests hundreds of libraries in the background really sucking up your bandwidth
        madacol 5y ago
        I got a better idea Imagine ad companies choose libraries that are roughly used by 50% of users, if they test you with 10 of those, they learn ~10bits of entropy to classify you, i.e. which of the 1024 classifications you belong
- doctoboggan 5y ago
  It seems like there could be some sort of cross origin cache header that could be set? That way by default you couldn't store in a global cache but server operators would be able to mark certain resources that could be.
  - modeless 5y ago
    Server operators would just set that header on everything. There's no downside for them. The privacy issue only impacts users and it would still exist even if only a subset of libraries were shared.
  - zdw 5y ago
    One proposed solution is checksums on CDN provided javascript: https://w3c.github.io/webappsec-subresource-integrity/ https://w3c.github.io/webappsec-subresource-integrity/
- eigenvalue 5y ago
  Surprised the clients couldn’t just randomly add a small random delay on N percent of requests to nullify the side-channel info leakage.
  - dagenix 5y ago
    It's my understanding that that type of countermeasure can be defeated with some statistical analysis.
    - gizmo686 5y ago
      Normally they could be, but it might actually work in this case. To do a statistical analysis, you need to be able to make many measurements. However, you only get one measurement per resource as a subsequent attempts will be cached regardless.
      - dagenix 5y ago
        This is very much not my area of expertise, but there are a few things that I think could be challenging. Let's assume that a cached resource loads in ~0.1 seconds and an uncached one loads in ~1.0 second: * Any random delay of up to less than 0.9 seconds is completely pointless since we would know that any resource that loads in 0.5 seconds has to be cached - the 0.4 seconds spent waiting is useless. * A random delay of up to a second creates ambiguous cases: is 1.1 a cached + maximally delayed response or an uncached but only slightly delayed response? But, with a random delay, we're still going to have pretty different peaks in the expected latency graphs for cached and uncached resources - uncached ones would peak around 0.5 seconds and cached ones would peak around 1.5 seconds. * A random delay much more than a second would start causing the peaks on our expected latency graphs to be closer together - at a 10 second delay, we'll have a peak in the graph around 5 seconds for cached resources and 6 seconds for cached ones. I'm a bit fuzzy on how many resources we'd have to load to get a statistically significant finger print. I suspect its not all that many - but I could be wrong. However, we're also talking about a pretty significant delay by this point. We also have the issue of how to handle AJAX requests. You only get one shot to measure the initial load. But, after that you can make an AJAX request to re-load that same resource with caching disabled and measure that. I'm not a statistician, but, I suspect that that information will be pretty helpful in figuring out what was cached vs not cached. Of course, we could add in some random delays here too - but since we can measure this an unlimited number of times, I suspect this would be even easier to defeat. So, my suspicion is, that these type of random delays are possible to defeat if you have a better grasp of statistics than I do. But, we could also assume that that is not the case and that they can't be defeated - what does that get us? We've had to add all these random delays in to block the side channel which is going to hurt latency - the very thing we're trying to improve with caching. I also suspect there is a ton of complexity to consider if you want to avoid having all of the same random delays on repeated visits.
- markdown 5y ago
  How is that any privacy hole at all? Millions of websites use vue (as an example) from the same CDN. There's no way to know which site it was cached from. What a terrible thing they've done, making the internet slower for everyone on earth for no good reason.
  - ______-_-______ 5y ago
    By "they" do you mean advertisers? If so, I agree
  - dagenix 5y ago
    Its pretty bold of you to assume that you know more about this problem than every browser developer. Websites don't just "use Vue". They use some particular version of Vue along with particular versions of other libraries. My understanding is that once you put all of that together, this can create some significant privacy leaks.
- wolpoli 5y ago
  We could solve the privacy issue by implementing an installable plugin system into the browser. Let's call it NPAPI!
- jefftk 5y ago
  It was even worse than that: https://sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html https://sirdarckcat.blogspot.com/2019/03/http-cache-cross-si...
teddyh 5y ago
It was discussed here at the time: https://news.ycombinator.com/item?id=24894135 https://news.ycombinator.com/item?id=24894135

simonw 5y ago

It was a huge privacy hole: malicious pages could measure how long it took for URLs to load and use that to tell which other sites you had visited in the past.

colordrops 5y ago
Weren't the shared libraries used on countless sites though? How would this work?
- TOMDM 5y ago
  Because you'd make your own library used exclusively for tracking, or check to see if another site specific set of resources had been loaded.
- modeless 5y ago
  Yes but each site uses a lot of libraries too. The set of libraries and specific versions of those libraries used by a site is a pretty good fingerprint.
  - colordrops 5y ago
    Still doesn't make sense - there is only a single set of libraries - the ones cached by a user's browser, and since each library in that set is used by thousands of sites, there's no way to know which site it was cached for. For each version, there are certainly thousands of sites using it. Since I'm still not getting it, perhaps you could explain how a particular set of libraries is fingerprinted?
    - dmurray 5y ago
      The New York Times uses libraries (versions) A,B,C, and D. Wikileaks uses A,B,D and F. I see that you have A,B,D and F cached - that allows me to rule out the NYT and predict with some degree of confidence that you visited Wikileaks. You can make up theoretical models for how many popular libraries there are, or how many sites, and say this should or shouldn't be possible. I haven't seen any such models, but advertisers were definitely using this technique in the wild so the models that say it's impossible are all wrong. Adding noise to a small sample of requests doesn't buy you that much entropy - the signal is a little noisy anyway.
      - colordrops 5y ago
        This would work if you only visited like 5 sites. If you visit thousands, and more like tens of thousands when you consider 3rd party embedded content, you can't figure out which sites a user visits, but rather only which ones they don't.
        EwanToo 5y ago
        It worked pretty effectively. Think about the 10,000s of JavaScript libraries out there, and the 100s of versions of each.
        madacol 5y ago
        number of libraries * number of versions ~= bits of information to classify you A good intuition is that although there's low certainty which site you have visited, there's high certainty which sites you HAVE NOT visited I think is easier to see how you can fingerprint someone based on the set of sites they HAVE NOT visited Edit: I'm not so sure anymore, I think that requires to test looots of libraries, it's not practical unless you are a really nasty ad company that tests hundreds of libraries in the background really sucking up your bandwidth
        madacol 5y ago
        I got a better idea Imagine ad companies choose libraries that are roughly used by 50% of users, if they test you with 10 of those, they learn ~10bits of entropy to classify you, i.e. which of the 1024 classifications you belong
doctoboggan 5y ago
It seems like there could be some sort of cross origin cache header that could be set? That way by default you couldn't store in a global cache but server operators would be able to mark certain resources that could be.
- modeless 5y ago
  Server operators would just set that header on everything. There's no downside for them. The privacy issue only impacts users and it would still exist even if only a subset of libraries were shared.
- zdw 5y ago
  One proposed solution is checksums on CDN provided javascript: https://w3c.github.io/webappsec-subresource-integrity/ https://w3c.github.io/webappsec-subresource-integrity/
eigenvalue 5y ago
Surprised the clients couldn’t just randomly add a small random delay on N percent of requests to nullify the side-channel info leakage.
- dagenix 5y ago
  It's my understanding that that type of countermeasure can be defeated with some statistical analysis.
  - gizmo686 5y ago
    Normally they could be, but it might actually work in this case. To do a statistical analysis, you need to be able to make many measurements. However, you only get one measurement per resource as a subsequent attempts will be cached regardless.
    - dagenix 5y ago
      This is very much not my area of expertise, but there are a few things that I think could be challenging. Let's assume that a cached resource loads in ~0.1 seconds and an uncached one loads in ~1.0 second: * Any random delay of up to less than 0.9 seconds is completely pointless since we would know that any resource that loads in 0.5 seconds has to be cached - the 0.4 seconds spent waiting is useless. * A random delay of up to a second creates ambiguous cases: is 1.1 a cached + maximally delayed response or an uncached but only slightly delayed response? But, with a random delay, we're still going to have pretty different peaks in the expected latency graphs for cached and uncached resources - uncached ones would peak around 0.5 seconds and cached ones would peak around 1.5 seconds. * A random delay much more than a second would start causing the peaks on our expected latency graphs to be closer together - at a 10 second delay, we'll have a peak in the graph around 5 seconds for cached resources and 6 seconds for cached ones. I'm a bit fuzzy on how many resources we'd have to load to get a statistically significant finger print. I suspect its not all that many - but I could be wrong. However, we're also talking about a pretty significant delay by this point. We also have the issue of how to handle AJAX requests. You only get one shot to measure the initial load. But, after that you can make an AJAX request to re-load that same resource with caching disabled and measure that. I'm not a statistician, but, I suspect that that information will be pretty helpful in figuring out what was cached vs not cached. Of course, we could add in some random delays here too - but since we can measure this an unlimited number of times, I suspect this would be even easier to defeat. So, my suspicion is, that these type of random delays are possible to defeat if you have a better grasp of statistics than I do. But, we could also assume that that is not the case and that they can't be defeated - what does that get us? We've had to add all these random delays in to block the side channel which is going to hurt latency - the very thing we're trying to improve with caching. I also suspect there is a ton of complexity to consider if you want to avoid having all of the same random delays on repeated visits.
markdown 5y ago
How is that any privacy hole at all? Millions of websites use vue (as an example) from the same CDN. There's no way to know which site it was cached from. What a terrible thing they've done, making the internet slower for everyone on earth for no good reason.
- ______-_-______ 5y ago
  By "they" do you mean advertisers? If so, I agree
- dagenix 5y ago
  Its pretty bold of you to assume that you know more about this problem than every browser developer. Websites don't just "use Vue". They use some particular version of Vue along with particular versions of other libraries. My understanding is that once you put all of that together, this can create some significant privacy leaks.
wolpoli 5y ago
We could solve the privacy issue by implementing an installable plugin system into the browser. Let's call it NPAPI!
jefftk 5y ago
It was even worse than that: https://sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html https://sirdarckcat.blogspot.com/2019/03/http-cache-cross-si...

teddyh 5y ago

It was discussed here at the time: https://news.ycombinator.com/item?id=24894135 https://news.ycombinator.com/item?id=24894135