Hacker News Reader

Comment by amenghra | Hacker News Reader

The right answer is to specify a HMAC when serving js from third parties.

CSP/SRI already enables this.

Ideally you should be able to serve content from your own domain + specify the hash, and let browsers optimize things by re-using cached content from another domain. There’s no easy/standardized way of doing that today.

View on HN

I think you can already do a browser extension that intercepts loads and gets things with script integrity from a cache, another domain, ipfs, whatever.

Decentraleyes is an example of an existing codebase you could use: https://github.com/Synzvato/decentraleyes

There is/was discussion in the standards body of using the SRI hash for exactly this purpose. It sounds really promising but iirc there was a privacy kink to work out.

You could potentially tell whether someone has been to a third-party site.

Person goes to a porn site, get's file #A.

Spying site, offers file #A, but never delivers it.

If a person already has #A (i.e. doesn't request it), spy site knows they've been to porn site.

Could you limit it to widely used libraries? e.g. browser ships with the last N versions of jQuery etc., and avoids the request if it's a known hash. If it's widely used, it seems like the amount of information leaked would be low, and if the browser _always_ ships with it (rather than caching on first use), it would only identify the browser and not browsing history anyway.

As a bonus, developers could use it knowing that there is much less likely to be a performance hit from fetching it.

Reply on news.ycombinator.com