5 ms·

Just wondering. Can "integrity" be used instead of url to provide better caching? Because it is based on hash, which should be more reliable than just url.

RL_Quine 6y ago
That would be a super-cookie though.
- lucb1e 6y ago
  How would specifying what content the library should have (to preserve integrity) lead to tracking?
  - im3w1l 6y ago
    Caching across sites at all means you can see if it loads quickly or slowly to make inferences. Non-obvious tradeoff imo.
    - XCSme 6y ago
      It's not about how fast it loads, it about whether it actually requests the file from the server or not. See my comment above, if you have "x.js" in your cache and it's your first time on this site, it means that you previously visited another site that contains "x.js".
      - im3w1l 6y ago
        In cache - high speed, fetch from server - low speed. Isn't that how you detect it?
        XCSme 6y ago
        The problem is not that you can detect it on the client,but you can also see it on the server. On the server you see that user requested the HTML for the page and other resources, but never requested X.js. You could keep a count of requests, per user per file.
  - shakna 6y ago
    A number of problems surface [0]. Starting with timing leaks. > The first difficulty of implementing cross-origin, content addressable caching on the Web platform is that it may leak information about the user’s past browsing. For example, site "A" could load a script with a given hash, then later when the user visits site "B", it could attempt to observe the time it takes to load that same resource and infer whether the user had previously been at "A". [0] https://hillbrad.github.io/sri-addressable-caching/sri-addressable-caching.html https://hillbrad.github.io/sri-addressable-caching/sri-addre...
lucb1e 6y ago
Might subresource integrity be what you are looking for? Not sure if you meant that, or if you are proposing such a system (which is a good idea!) without realizing that this already exists: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
- XCSme 6y ago
  He is proposing to use the integrity hash for caching purposes, not for security purposes. This has been discussed before and it is unlikely it will be implemented as it is almost impossible to eliminate finger-printing and privacy issues if this cache is implemented plus it might lead to security problems: https://github.com/w3c/webappsec-subresource-integrity/issues/22#issuecomment-637490030 https://github.com/w3c/webappsec-subresource-integrity/issue...
  - lucb1e 6y ago
    > for caching purposes, not for security purposes Whether it's for caching or security purposes, a hash of the contents is a hash of the contents. The link you shared is about tracking whether a given document is already cached. That's the same problem as with normal caching. At least the top N libraries could be downloaded with a browser update and be equal for everyone.
- deleted 6y ago
  [deleted]
XCSme 6y ago
Not sure if you are referring about domain-local cache, or a cache shared between domains: https://github.com/w3c/webappsec-subresource-integrity/issues/22 https://github.com/w3c/webappsec-subresource-integrity/issue...
- XCSme 6y ago
  A privacy issue example if a shared cache is implemented: jQuery v2 is installed and shared between sites A,B,C. If user goes to site B for the first time and the file is in cache (never requested from it), then it means the user has also visited A or C. If more files like this are shared, then, based on the requested files you can somewhat estimate which websites a user visited before.

RL_Quine 6y ago

That would be a super-cookie though.

lucb1e 6y ago
How would specifying what content the library should have (to preserve integrity) lead to tracking?
- im3w1l 6y ago
  Caching across sites at all means you can see if it loads quickly or slowly to make inferences. Non-obvious tradeoff imo.
  - XCSme 6y ago
    It's not about how fast it loads, it about whether it actually requests the file from the server or not. See my comment above, if you have "x.js" in your cache and it's your first time on this site, it means that you previously visited another site that contains "x.js".
    - im3w1l 6y ago
      In cache - high speed, fetch from server - low speed. Isn't that how you detect it?
      - XCSme 6y ago
        The problem is not that you can detect it on the client,but you can also see it on the server. On the server you see that user requested the HTML for the page and other resources, but never requested X.js. You could keep a count of requests, per user per file.
- shakna 6y ago
  A number of problems surface [0]. Starting with timing leaks. > The first difficulty of implementing cross-origin, content addressable caching on the Web platform is that it may leak information about the user’s past browsing. For example, site "A" could load a script with a given hash, then later when the user visits site "B", it could attempt to observe the time it takes to load that same resource and infer whether the user had previously been at "A". [0] https://hillbrad.github.io/sri-addressable-caching/sri-addressable-caching.html https://hillbrad.github.io/sri-addressable-caching/sri-addre...

lucb1e 6y ago

Might subresource integrity be what you are looking for? Not sure if you meant that, or if you are proposing such a system (which is a good idea!) without realizing that this already exists: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

XCSme 6y ago
He is proposing to use the integrity hash for caching purposes, not for security purposes. This has been discussed before and it is unlikely it will be implemented as it is almost impossible to eliminate finger-printing and privacy issues if this cache is implemented plus it might lead to security problems: https://github.com/w3c/webappsec-subresource-integrity/issues/22#issuecomment-637490030 https://github.com/w3c/webappsec-subresource-integrity/issue...
- lucb1e 6y ago
  > for caching purposes, not for security purposes Whether it's for caching or security purposes, a hash of the contents is a hash of the contents. The link you shared is about tracking whether a given document is already cached. That's the same problem as with normal caching. At least the top N libraries could be downloaded with a browser update and be equal for everyone.
deleted 6y ago
[deleted]

XCSme 6y ago

Not sure if you are referring about domain-local cache, or a cache shared between domains: https://github.com/w3c/webappsec-subresource-integrity/issues/22 https://github.com/w3c/webappsec-subresource-integrity/issue...

XCSme 6y ago
A privacy issue example if a shared cache is implemented: jQuery v2 is installed and shared between sites A,B,C. If user goes to site B for the first time and the file is in cache (never requested from it), then it means the user has also visited A or C. If more files like this are shared, then, based on the requested files you can somewhat estimate which websites a user visited before.