4 ms·
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
by amenghra 9y ago
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.
- greglindahl 9y agoI 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 https://github.com/Synzvato/decentraleyes
- Scott_Helme_ 9y agoThere 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.
- sago 9y agoYou 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.
- deleted 9y ago[deleted]
- stordoff 9y agoCould 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.