(Replying to PARENT post)
> Is this really a significant privacy issue? Server can deduce which items (I use word "item" to refer to a resource cache entry) are missing from client cache just by monitoring follow-up requests by the client.
Conceivably, a server could generate random null resources which are cached by the client and can then be used, as the GP indicates, to identify it — yet another supercookie.
👤zeveb🕑9y🔼0🗨️0
(Replying to PARENT post)
Some variant of your suggested approach is currently under standardization: https://datatracker.ietf.org/doc/draft-kazuho-h2-cache-diges...
👤worenga🕑9y🔼0🗨️0
(Replying to PARENT post)
Is this really a significant privacy issue? Server can deduce which items (I use word "item" to refer to a resource cache entry) are missing from client cache just by monitoring follow-up requests by the client. Of course this way server can't know anything about the items client has but are not present on the page.
Maybe some cryptography can be used here, so that client can tell the server items it has, but in such a way that server can't know anything more than what it strictly needs.
Client could for example hash each item signature with salt and send this information to the server, salt + a list of hashed items. This would prevent direct lookups, but of course the server could still compute same value (hash of signature + salt) for all items in a database.
Maybe it's somehow possible to have even stronger privacy guarantees while still allowing server to compute which items have a high probability to be needed by the client based on some information client included in the request?
Another idea: client could send a bloom filter [1] of the related items it already has plus random hashing data to compute it. Server would use client provided hashing parameters to compute bloom filter bit index for each item and push it if the bit wasn't set. Of course this would sometimes cause server not to push needed data. Frequency when this happens would depend on the bloom filter size the client chooses versus number of potential items.
Because the client chooses bloom filter hashing parameters, this would mask the set of items the client possesses. This makes the data about already cached items almost useless for fingerprinting purposes, while still keeping some of the server push performance gain. Client can pick the tradeoff between performance and privacy with bloom filter size.
[1]: https://en.wikipedia.org/wiki/Bloom_filter