Hi! Just to be clear, what we saw in the wild was not HSTS fingerprinting but rather using HSTS as a deliberate stateful tracking vector. Maybe if sites were probing the dynamic HSTS cache in general could it be called fingerprinting but I try to reserve that term for stateless tracking. Regards, John > On Oct 1, 2019, at 6:51 AM, Mike West <mkwst@google.com> wrote: > > > Ping! > > If this group doesn't feel any particular ownership, I'm happy to try to define some web browsery behavior in W3C/WHATWG. If y'all would prefer an RFC6797bis, great! > > -mike > > >> On Wed, Sep 18, 2019 at 3:10 AM Mike West <mkwst@google.com> wrote: >> A year or two ago, +John Wilander and others at Apple proposed some changes to HSTS in https://webkit.org/blog/8146/protecting-against-hsts-abuse/ that went some way towards mitigating the abuses documented in Section 14.9 of RFC6797. Given some shifts in the way we're thinking about some other concepts, I've written up a short proposal at https://github.com/mikewest/strict-navigation-security that builds upon and simplifies Apple's proposal. We discussed it briefly at yesterday's webappsec meeting, and there seems to be interest in doing something in this space. >> >> +Mark Nottingham and +Jeff Hodges suggested that I loop this group into that conversation, as the original websec group has disbanded. Is it a topic this group would like to pick up? If not, would y'all be comfortable with us defining some web browser behavior/Fetch integration in webappsec that constrains the existing RFC? >> >> Thanks! >> >> -mike
Received on Tuesday, 1 October 2019 15:34:55 UTC