3 ms·
> a copy has to be downloaded for each website, so each first website load is slowed down. The major browsers (FF, Chrome, Safari) all fragment cache by the do
by jefftk 7y ago
> a copy has to be downloaded for each website, so each first website load is slowed down.
The major browsers (FF, Chrome, Safari) all fragment cache by the domain in the URL bar now, for privacy reasons, so this doesn't apply anymore.
> the browser could cache the object across websites and download from a source that the requesting website controls
You can't do this without reintroducing the same privacy issues that cache fragmentation was introduced to prevent.
- jefftk 7y agoSorry, checking, FF and Chrome don't do it yet, but they will soon: https://www.chromestatus.com/feature/5730772021411840 https://www.chromestatus.com/feature/5730772021411840 , https://bugzilla.mozilla.org/show_bug.cgi?id=1536058 https://bugzilla.mozilla.org/show_bug.cgi?id=1536058
- lixtra 7y agoThanks for the cache partition description. This will make projects like cdnjs less beneficial. The proposed hash:// scheme at least would leave it to the attacked site which resources to expose to such an attack. Performance vs security trade offs seem to be popping up everywhere recently.
- jefftk 7y agoA "share cache if hashes match" approach was considered with https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres... but not included in the initial version. There's been talk (https://hillbrad.github.io/sri-addressable-caching/sri-addressable-caching.html https://hillbrad.github.io/sri-addressable-caching/sri-addre... , https://github.com/w3c/webappsec-subresource-integrity/issues/22 https://github.com/w3c/webappsec-subresource-integrity/issue...) about allowing sites to opt in, but then you're opening up a new way of tracking users across sites.