@Mike West <mike@mikewest.org> any thoughts on Frederik's question? On Fri, Oct 26, 2018 at 3:41 AM Frederik Braun <fbraun@mozilla.com> wrote: > > > Am 25.10.18 um 16:57 schrieb Caleb Queern: > > Just want to confirm my understanding... if one were worried about > > the risk of user tracking via TLS session resumption as described in > > the Hamburg paper, that risk would be mitigated in browsers that > > support the Clear-Site-Data header by sending the header: > > > > Clear-Site-Data: "cache" > > > > ...correct? > > > > Looking at > < > https://mikewest.github.io/webappsec/specs/clear-site-data/#cache-parameter > >, > it says > > > The cache parameter indicates that the server wishes to remove > > locally cached data associated with the origin of a particular > > response’s url. This includes the network cache, of course, but will > > also remove data from various other caches which a user agent > > implements (prerendered pages, script caches, shader caches, etc.). > This reads to me as a "probably not". > I would have assumed that this is purely about cached *content*. > So should it include all kinds of things a browser could have cached for > this origin? Issue 5 in the spec[1] agrees that this is a bit nebulous > and Chrome appears to remove some of those things > > What are other people reading into this? > Should "cache" include TLS session information? > If not, should there be some sort of security-state flag for the > Clear-Site-Data header which removes existing security state (e.g.,TLS > session tickets, HPKP/HSTS values set through headers (assuming browser > support)? > > > > > > [1] > https://mikewest.github.io/webappsec/specs/clear-site-data/#issue-d40aa458 > > -- Caleb 571-228-8011Received on Thursday, 1 November 2018 07:22:27 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:55:05 UTC