News for hackers. Stuff that matters.
Re:Please stop using CDNs for external JavaScript libraries by EE84M3i on Sunday October 11, 2020 @12:24PM (#24746878)
Yes, using timing
Re:Please stop using CDNs for external JavaScript libraries by evilduck on Sunday October 11, 2020 @12:45PM (#24747074)
Wouldn't the act of timing a download mean that I download and pollute my cache with new assets from the site trying find where else I've been? Does this only work for the first site that tries to fingerprint a browser in this way?
Re:Please stop using CDNs for external JavaScript libraries by curryst on Sunday October 11, 2020 @02:19PM (#24747843)
Is there a noCache option? Or can JS remove entries from the cache to reset it?

Someone below mentioned doing requests for a large image that requires authentication. Short response time means the user isn't logged in (they got a 403), long response time means they downloaded the image and are logged in.

Re:Please stop using CDNs for external JavaScript libraries by amelius on Sunday October 11, 2020 @12:35PM (#24746978)
Not if the javascript starts running only after all resources have loaded.
Re:Please stop using CDNs for external JavaScript libraries by darepublic on Sunday October 11, 2020 @12:45PM (#24747071)
No there could still be timing attacks after. Just dynamically request a cross domain asset
Re:Please stop using CDNs for external JavaScript libraries by amelius on Sunday October 11, 2020 @01:02PM (#24747234)
Then those requests should not be cached?
Re:Please stop using CDNs for external JavaScript libraries by tylerhou on Sunday October 11, 2020 @03:35PM (#24748411)

  const start = window.performance.now();
  const t = await fetch("https://example.com/asset_that_may_be_cached.jpg");
  const end = window.performance.now();
  if (end - start < 10/*ms*/) {
    console.log("cached");
  } else {
    console.log("not cached");
  }
Re:Please stop using CDNs for external JavaScript libraries by amelius on Sunday October 11, 2020 @03:59PM (#24748603)
In that case, the browser would always load the asset (it is not cached). So the rule would be that only stuff that is directly in the <head> may be cached (or stuff that is on the same domain).
Re:Please stop using CDNs for external JavaScript libraries by tylerhou on Sunday October 11, 2020 @04:16PM (#24748751)
To be clear, the context of the thread is "why do we need to partition the HTTP cache per domain." My example code works under the (soon-to-be-false) assumption that the cache is NOT partitioned (i.e. there is a global HTTP cache).

> In that case, the browser would always load the asset (it is not cached).

Agreed, if the cache is partitioned per domain AND the current domain has not requested the resource on a prior load. If the cache is global, then the asset will be loaded from cache if it is present: https://developer.mozilla.org/en-US/docs/Web/API/Request/cac...

> So the rule would be that only stuff that is directly in the <head> may be cached (or stuff that is on the same domain).

You could be more precise here: with a domain-partitioned cache, all resources regardless of domain loaded by any previous request on the same domain could be cached. So if I load HN twice and HN uses https://example.com/image.jpg on both pages, then the second request will use the cached asset.

Re:Please stop using CDNs for external JavaScript libraries by amelius on Sunday October 11, 2020 @06:16PM (#24749568)
> To be clear, the context of the thread is "why do we need to partition the HTTP cache per domain."

Ah right, the thread is becoming long :)

> So if I load HN twice and HN uses https://example.com/image.jpg on both pages, then the second request will use the cached asset.

Good point!