Hacker News Reader

Comment by MattIPv4 | Hacker News Reader

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.)

View on HN

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/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)

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?

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.

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/

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.

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

Wouldn't it also be useful when the browser retrieves resources from a local disk cache?

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), Firefox (depending on settings from 2018 and widely deployed in 2020, https://developer.mozilla.org/en-US/docs/Web/Privacy/State_P...) and Chrome (from 2020, https://developer.chrome.com/blog/http-cache-partitioning/) now separate caches.

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.

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.

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.

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.

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.

Reply on news.ycombinator.com