4 ms·

Two of the things that this article calls out are security & privacy. It's worth keeping in mind that you can and should be using SRI when loading remote resour

Two of the things that this article calls out are security & privacy. It's worth keeping in mind that you can and should be using SRI when loading remote resources like this, which will go a long way to protect you. And, you can set attributes like referrerpolicy to ensure that privacy is maintained as much as possible. (cdnjs, that I maintain and is referenced in the article, does both of these by default if you copy a script/link tag from our site.)

lelandfe 4y ago
For the curious, SRI = SubResource Integrity. It’s a hash of the file, and browsers will not use the file if there’s a mismatch: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres... (ps, I dislike the name; you don’t encounter the term “subresource” anywhere else in webdev. It’s a “subresource” of the HTML document resource, eyeroll)
- nerdponx 4y ago
  If we're baking file hashes into the HTML... is there any work out there that goes the extra mile and uses IPFS as your CDN?
  - viraptor 4y ago
    Depends what you mean by that precisely. But you can load things from cloudflare's ipfs gateway without doing anything special otherwise. Directly from ipfs - not without extensions.
    - nybble41 4y ago
      You could include js-ipfs[0] and fetch all your resources from IPFS without going through a gateway. However, this approach would make the site fully dependent on JavaScript. A PWA with a Service Worker could perhaps implement its own client-side "gateway", translating public gateway URLs into direct IPFS access. Without the Service Worker (or without JS) it would fall back to using the gateway. [0] https://js.ipfs.io/ https://js.ipfs.io/
    - nerdponx 4y ago
      Does an HTTP gateway actually allow you to make peer-to-peer IPFS connections, or does the actual content end up being routed through the gateway? And if so, wouldn't that be equivalent to a traditional CDN from the perspective of a client? It sounds like we'd need to have browsers implement IPFS protocol support directly for this to be a feasible alternative to centralized CDNs.
k__ 4y ago
SRI might prevent you from getting malicious code, but these privacy enhancing methods feel like smoke and mirrors to me.
- nerdponx 4y ago
  Wouldn't it also be useful when the browser retrieves resources from a local disk cache?
  - zinekeller 4y ago
    Nope, no longer. Some large advertising companies like Taboola have abused caches to store unique identifiers. I won't be shocked if Google and Facebook have also used this, so Safari (from 2013, https://bugs.webkit.org/show_bug.cgi?id=110269 https://bugs.webkit.org/show_bug.cgi?id=110269), Firefox (depending on settings from 2018 and widely deployed in 2020, https://developer.mozilla.org/en-US/docs/Web/Privacy/State_Partitioning https://developer.mozilla.org/en-US/docs/Web/Privacy/State_P...) and Chrome (from 2020, https://developer.chrome.com/blog/http-cache-partitioning/ https://developer.chrome.com/blog/http-cache-partitioning/) now separate caches.
    - nybble41 4y ago
      With SRI you can't store unique identifiers in the cache since the cached content has to match the hash in the URI. The only real privacy leak would be potentially determining whether certain data was already cached.
      - zinekeller 4y ago
        While you're correct, it's too little too late. You should assume that everyone effectively don't have a web cache. It's like the effect of Spectre and Meltdown: JS timers are no longer accurate to compensate for them.
AtNightWeCode 4y ago
Yes, and I don't get the argument against it. The links always include the version in the URL and files are expected to be immutable.
- prophesi 4y ago
  The article brought up some good points. If SRI fails, it simply won't load and thus break your site, which isn't a great outcome. And in organizations, the likely hotfix will be to remove SRI. Not to mention you have to keep track of the hash, which could cause breakage when a newer version is used and the devs don't keep that in mind.
  - AtNightWeCode 4y ago
    To not run code that somebody else may have changed is the whole point. And it does not fail if you test it first. We are talking about billions of requests every day that is served by external CDN providers.

lelandfe 4y ago

For the curious, SRI = SubResource Integrity. It’s a hash of the file, and browsers will not use the file if there’s a mismatch: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres... (ps, I dislike the name; you don’t encounter the term “subresource” anywhere else in webdev. It’s a “subresource” of the HTML document resource, eyeroll)

nerdponx 4y ago
If we're baking file hashes into the HTML... is there any work out there that goes the extra mile and uses IPFS as your CDN?
- viraptor 4y ago
  Depends what you mean by that precisely. But you can load things from cloudflare's ipfs gateway without doing anything special otherwise. Directly from ipfs - not without extensions.
  - nybble41 4y ago
    You could include js-ipfs[0] and fetch all your resources from IPFS without going through a gateway. However, this approach would make the site fully dependent on JavaScript. A PWA with a Service Worker could perhaps implement its own client-side "gateway", translating public gateway URLs into direct IPFS access. Without the Service Worker (or without JS) it would fall back to using the gateway. [0] https://js.ipfs.io/ https://js.ipfs.io/
  - nerdponx 4y ago
    Does an HTTP gateway actually allow you to make peer-to-peer IPFS connections, or does the actual content end up being routed through the gateway? And if so, wouldn't that be equivalent to a traditional CDN from the perspective of a client? It sounds like we'd need to have browsers implement IPFS protocol support directly for this to be a feasible alternative to centralized CDNs.

k__ 4y ago

SRI might prevent you from getting malicious code, but these privacy enhancing methods feel like smoke and mirrors to me.

nerdponx 4y ago
Wouldn't it also be useful when the browser retrieves resources from a local disk cache?
- zinekeller 4y ago
  Nope, no longer. Some large advertising companies like Taboola have abused caches to store unique identifiers. I won't be shocked if Google and Facebook have also used this, so Safari (from 2013, https://bugs.webkit.org/show_bug.cgi?id=110269 https://bugs.webkit.org/show_bug.cgi?id=110269), Firefox (depending on settings from 2018 and widely deployed in 2020, https://developer.mozilla.org/en-US/docs/Web/Privacy/State_Partitioning https://developer.mozilla.org/en-US/docs/Web/Privacy/State_P...) and Chrome (from 2020, https://developer.chrome.com/blog/http-cache-partitioning/ https://developer.chrome.com/blog/http-cache-partitioning/) now separate caches.
  - nybble41 4y ago
    With SRI you can't store unique identifiers in the cache since the cached content has to match the hash in the URI. The only real privacy leak would be potentially determining whether certain data was already cached.
    - zinekeller 4y ago
      While you're correct, it's too little too late. You should assume that everyone effectively don't have a web cache. It's like the effect of Spectre and Meltdown: JS timers are no longer accurate to compensate for them.

AtNightWeCode 4y ago

Yes, and I don't get the argument against it. The links always include the version in the URL and files are expected to be immutable.

prophesi 4y ago
The article brought up some good points. If SRI fails, it simply won't load and thus break your site, which isn't a great outcome. And in organizations, the likely hotfix will be to remove SRI. Not to mention you have to keep track of the hash, which could cause breakage when a newer version is used and the devs don't keep that in mind.
- AtNightWeCode 4y ago
  To not run code that somebody else may have changed is the whole point. And it does not fail if you test it first. We are talking about billions of requests every day that is served by external CDN providers.