https://developers.google.com/web/updates/2020/10/http-cache...
There are, of course, other vectors to consider, but I can't think of any that could be abused by third parties. If anything, isolating caches would make it easier for the CDN themselves to carry out the attack you mentioned, as they would be receiving all the requests in one batch.
I'd be able to tell if you visited Fox news recently, correct?
But three specific files can already be pretty unique. I chart.js with two specific plugins in my toy project, and I'm willing to bet that no one else on the world uses the exact same set and version configuration.
I suppose with HTTP2 some of the benefits of serving JS through CDNs are gone anyway, so I guess it's time to stop using them.
If Site A loads a specific JavaScript file for users with an administrator account, Site B can check to see if the JavaScript file is in your cache, and infer that you must have an administrator account if the file is there.
The attack can happen with different types of resources (such as images).
Furthermore a CDN can't track you as simple as you might think, it often would require thinks which need explicitly opt-in agreements on a per website basis to be legal.
Furthermore due to technical limitations you can only get that permission from the user after the CDN was already used.
CDNs can still track aggregated information to some degree but they can't legally act like a tracker cookie.
If you don't use any of those sites, you're considered higher risk/fraudulent user/bot.
Here's an example of a very short and easy way to see if someone is probably gay: https://pastebin.com/raw/CFaTet0K
On chrome, I consistently get 1-5 back after it's been cached, and 100+ on a clean visit. On Firefox with resistFingerprinting, I get 0 always.
> Here's an example of a very short and easy way to see if someone is probably gay
Ok, but now the resource is in my cache, so from now on they will think I'm gay?
This resource is just generic, so probably not, but if you actually visited grindr's site without adblocking heavily, they load googletagmanager and a significant number of other tracking services, which will almost certainly associate your advertising profile and identifiers as 'gay'
I also can't believe they send/sell your information to 3 pages worth of third party monetization providers/adtech companies for something that is this critically sensitive.
[1] - https://www.webdigi.co.uk/demos/how-to-detect-visitors-logge...
Plus the trend now is to use webpack and have all of your deps bundled in and served from the same server.
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.
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");
}> 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.
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!
And by going that route you make sure that all pieces of your website have the same availability guarantees, the same performance profile, and the same security guarantees that the content was not manipulated by a 3rd party.
You can already guarantee the security of the file by using the integrity attribute on the <script> tag. And the performance of your CDN is probably worse than the Google CDN (not to mention that you lose out on the shared cache).
> And the performance of your CDN is probably worse than the Google CDN
What means probably? Other CDNs (Akamai, CloudFront, Cloudflare, etc) are also fast.
And by pushing one piece of your website on a different CDN you force your users browser to create an additional HTTPS connection which takes additional round-trips, instead of being able to leverage one connection for all assets. This alone might as well outweigh the performance differences between CDNs.
Also the "shared cache" benefit might go away, if I read the other answers in this topic correctly.
I mean, wouldn't that take care of a whole class of attack vectors and make cross-origin requests possible without having to worry about CSRF?
While privacy sensitive users may consider this a feature in case of e.g. google.com and youtube.com, the average user is more likely to consider it an annoyance, and worse, it is likely to break some obscure portal somewhere that is never going to be updated, so if one browser does it and another doesn't, the solution will be a hastily hacked note "this doesn't work in X, use Y instead" added to the portal. And no browser vendor wants to be X.
[1] The workaround of using the public suffix list for such purposes is being discouraged by the public suffix list maintainers themselves IIRC, so the "right" thing to do would be breaking Wikipedia.
Edit: If done naively on an origin basis right now, it would break the Internet. You couldn't use _any_ site/app that has login/account management on a separate host name. You couldn't log into your Google account with such a browser anymore (because accounts.google.com != mail.google.com). Countless web sites that require logins would fail, both company-internal portals and public sites.
1) User logs in at google.com/login and sets google.com cookies. 2) Server generates a nonce and redirects to youtube.com/login?auth=$NONCE 3) youtube.com checks the $NONCE and sets youtube.com cookies 4) youtube.com redirects back to google.com.
Firefox's container tabs can maintain isolation despite this since even this redirect will stay within a container. However there is a usability penalty since the user has to open links for sites in the right container (and automatically opening certain sites in certain containers will enable cross-container stapling again).
webapps.stackexchange.com/questions/30254/why-does-gmail-login-go-through-youtube-com
Google themselves do this with gstatic.net and ytimg.com etc
> Google themselves do this with gstatic.net and ytimg.com etc
Most probably not. The point of cookieless domains is that you can use a very simple web server to serve content (no need to handle user sessions, files are pre-compresses and cached, etc.) and it lowers incoming bandwidth a lot. If you have a lot of requests (images, css, js) the cookie information adds up quickly.
Opening video thumbnails from ytimg.com will still be cached for youtube.com as before. The only thing that will change is for embedded videos on 3rd party websites as those won't be able to use caches ytimg.com thumbails from elsewhere.
The current way seems like needless DNS spam to me...
Given that generally people have slower upload than download, shaving off a few bytes from requests is worth it.
I also recall that browsers [used to (?)] limit concurrent requests per domain which this helps work around
And on a side note, very unhappy about how the entry to be a developer has lower significantly over the last 10 years or so.