9 ms·

Loading common libraries from a CDN will no longer bring any shared cache benefits, at least in most major browsers. Here's Chrome's intent to ship: https://chr

Loading common libraries from a CDN will no longer bring any shared cache benefits, at least in most major browsers. Here's Chrome's intent to ship: https://chromestatus.com/feature/5730772021411840 https://chromestatus.com/feature/5730772021411840 Safari already does this, and I think Firefox will, or is already, as well.

edent 6y ago
Oh, that's interesting. I guess it makes sense from a security and privacy perspective.
dndvr 6y ago
Will this cause performance issues for sites that use static cookieless domains for js, images etc Google themselves do this with gstatic.net and ytimg.com etc
- babuskov 6y ago
  > Will this cause performance issues for sites that use static cookieless domains for js, images 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.
  - pferde 6y ago
    Couldn't the same thing be achieved by routing e.g. google.com/static/ to a separate simple webserver, instead of using another domain? Or use a subdomain, e.g. static.google.com. The current way seems like needless DNS spam to me...
    - dndvr 6y ago
      Even if Google used a separate highly optimised webserver for google.com/static/jquery.js, users who are logged in would be sending their auth cookies when requesting the library. 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
dheera 6y ago
I wonder if an nginx plugin could be made to auto-cache CDN javascript/css files and edit the HTML on the fly to serve them from locally.
- oefrha 6y ago
  You’re probably thinking about a caching proxy like squid cache.
- daveFNbuck 6y ago
  You can set up a path that does a cached proxy to the CDN and just edit the HTML yourself. It's a bit annoying to get the cache settings to work properly, but editing the HTML is easy.
- ex_amazon_sde 6y ago
  https://decentraleyes.org/ https://decentraleyes.org/
GordonS 6y ago
I'm not sure I understand the threat here. Say I visit SiteA which references jQuery from CDNJS, then later visit SiteB which references exactly the same jQuery from CDNJS - what's the problem?
- dathinab 6y ago
  It can be used to track users across domains to some degree.
  - mmcwilliams 6y ago
    Not to be dense but wasn't that always the purpose of running a CDN service for common scripts and libraries?
    - daveFNbuck 6y ago
      The script wouldn't have to be from a CDN to track people using the browser cache. I could infer whether you've visited a site that doesn't use CDNs or trackers by asking you to load something from that site and inferring whether you have that resource cached by the time it took you to load it.
      - mmcwilliams 6y ago
        This is true, but if you're running a CDN you have access to cross-domain user information just based on the headers, no?
        daveoc64 6y ago
        The CDN is not the place you have to worried about. 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).
arendtio 6y ago
Does someone know why they don't split the cookie storage equally by the top origin? 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?
- fastest963 6y ago
  This is being worked on https://github.com/privacycg/storage-partitioning https://github.com/privacycg/storage-partitioning.
- tgsovlerkhgsel 6y ago
  One of the problems is that it breaks use cases like logging into stackoverflow.com and then visiting serverfault.com, or (if you do it by top-level origin) even en.wikipedia.org and then visiting de.wikipedia.org. [1] 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.
  - singron 6y ago
    It's possible to get around this with a redirect staple. E.g. if Google wants you to be logged in on youtube.com and google.com simultaneously: 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).
jakub_g 6y ago
For info, this shipped in Chrome 86 just last week: https://developers.google.com/web/updates/2020/10/http-cache-partitioning https://developers.google.com/web/updates/2020/10/http-cache...
rebelde 6y ago
Wouldn't a better, but partial, solution be for browsers to preload the top x common libraries? All other libraries would probably have to follow this new rule.
- codegladiator 6y ago
  Please no, don't create such barriers.
  - admax88q 6y ago
    Every other language runtime has a standard library, it's always been a shortcoming of the web IMO
- ValueNull 6y ago
  Isn’t this essentially what Decentraleyes does? https://decentraleyes.org/ https://decentraleyes.org/
  - Forbo 6y ago
    I've been using LocalCDN, it seems to be more acatively maintained and has a better selection of libraries. https://www.localcdn.org/ https://www.localcdn.org/
- lkschubert8 6y ago
  At that point wouldn't it make more sense to just have the browsers include that functionality?
  - Polylactic_acid 6y ago
    As soon as you add something to JS you have to support it forever. Its better to let sites pick what they need and scrap what they no longer need. JS has already added most of the useful stuff from jQuery. If browsers included a built in version of React it would pretty much lock in the design as it is now without room to remove and replace bad ideas.
thorum 6y ago
On the other hand, the URL for a common library hosted on cdnjs (or one of the other big JavaScript CDNs) and included on many different websites is much more likely to already be cached on edge servers close to your users than if you host the file yourself.
- arghwhat 6y ago
  The time to connect to the CDN hostname will negate any benefit, especially if push can be used.
- Matthias247 6y ago
  You can mitigate this by getting your website itself on a CDN. If this is cached, then it's assets (incl javascript), would be too. 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.
  - GeneralTspoon 6y ago
    > 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).
    - Matthias247 6y ago
      I agree on the security side if you use that attribute. However: > 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.
deepstack 6y ago
Good! The whole idea for doing js on CDN is suppose to make it easier for entry level front dev to be able to start coding. I think that is great for a school exercise, should never be used in business or production sites. 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.

edent 6y ago

Oh, that's interesting. I guess it makes sense from a security and privacy perspective.

dndvr 6y ago

Will this cause performance issues for sites that use static cookieless domains for js, images etc Google themselves do this with gstatic.net and ytimg.com etc

babuskov 6y ago
> Will this cause performance issues for sites that use static cookieless domains for js, images 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.
- pferde 6y ago
  Couldn't the same thing be achieved by routing e.g. google.com/static/ to a separate simple webserver, instead of using another domain? Or use a subdomain, e.g. static.google.com. The current way seems like needless DNS spam to me...
  - dndvr 6y ago
    Even if Google used a separate highly optimised webserver for google.com/static/jquery.js, users who are logged in would be sending their auth cookies when requesting the library. 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

dheera 6y ago

I wonder if an nginx plugin could be made to auto-cache CDN javascript/css files and edit the HTML on the fly to serve them from locally.

oefrha 6y ago
You’re probably thinking about a caching proxy like squid cache.
daveFNbuck 6y ago
You can set up a path that does a cached proxy to the CDN and just edit the HTML yourself. It's a bit annoying to get the cache settings to work properly, but editing the HTML is easy.
ex_amazon_sde 6y ago
https://decentraleyes.org/ https://decentraleyes.org/

GordonS 6y ago

I'm not sure I understand the threat here. Say I visit SiteA which references jQuery from CDNJS, then later visit SiteB which references exactly the same jQuery from CDNJS - what's the problem?

dathinab 6y ago
It can be used to track users across domains to some degree.
- mmcwilliams 6y ago
  Not to be dense but wasn't that always the purpose of running a CDN service for common scripts and libraries?
  - daveFNbuck 6y ago
    The script wouldn't have to be from a CDN to track people using the browser cache. I could infer whether you've visited a site that doesn't use CDNs or trackers by asking you to load something from that site and inferring whether you have that resource cached by the time it took you to load it.
    - mmcwilliams 6y ago
      This is true, but if you're running a CDN you have access to cross-domain user information just based on the headers, no?
      - daveoc64 6y ago
        The CDN is not the place you have to worried about. 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).

arendtio 6y ago

Does someone know why they don't split the cookie storage equally by the top origin? 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?

fastest963 6y ago
This is being worked on https://github.com/privacycg/storage-partitioning https://github.com/privacycg/storage-partitioning.
tgsovlerkhgsel 6y ago
One of the problems is that it breaks use cases like logging into stackoverflow.com and then visiting serverfault.com, or (if you do it by top-level origin) even en.wikipedia.org and then visiting de.wikipedia.org. [1] 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.
- singron 6y ago
  It's possible to get around this with a redirect staple. E.g. if Google wants you to be logged in on youtube.com and google.com simultaneously: 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).

jakub_g 6y ago

For info, this shipped in Chrome 86 just last week: https://developers.google.com/web/updates/2020/10/http-cache-partitioning https://developers.google.com/web/updates/2020/10/http-cache...

rebelde 6y ago

Wouldn't a better, but partial, solution be for browsers to preload the top x common libraries? All other libraries would probably have to follow this new rule.

codegladiator 6y ago
Please no, don't create such barriers.
- admax88q 6y ago
  Every other language runtime has a standard library, it's always been a shortcoming of the web IMO
ValueNull 6y ago
Isn’t this essentially what Decentraleyes does? https://decentraleyes.org/ https://decentraleyes.org/
- Forbo 6y ago
  I've been using LocalCDN, it seems to be more acatively maintained and has a better selection of libraries. https://www.localcdn.org/ https://www.localcdn.org/
lkschubert8 6y ago
At that point wouldn't it make more sense to just have the browsers include that functionality?
- Polylactic_acid 6y ago
  As soon as you add something to JS you have to support it forever. Its better to let sites pick what they need and scrap what they no longer need. JS has already added most of the useful stuff from jQuery. If browsers included a built in version of React it would pretty much lock in the design as it is now without room to remove and replace bad ideas.

thorum 6y ago

On the other hand, the URL for a common library hosted on cdnjs (or one of the other big JavaScript CDNs) and included on many different websites is much more likely to already be cached on edge servers close to your users than if you host the file yourself.

arghwhat 6y ago
The time to connect to the CDN hostname will negate any benefit, especially if push can be used.
Matthias247 6y ago
You can mitigate this by getting your website itself on a CDN. If this is cached, then it's assets (incl javascript), would be too. 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.
- GeneralTspoon 6y ago
  > 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).
  - Matthias247 6y ago
    I agree on the security side if you use that attribute. However: > 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.

deepstack 6y ago

Good! The whole idea for doing js on CDN is suppose to make it easier for entry level front dev to be able to start coding. I think that is great for a school exercise, should never be used in business or production sites. 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.