- From: Rob Sayre <sayrer@gmail.com>
- Date: Fri, 20 Sep 2019 14:56:11 -0700
- To: David Benjamin <davidben@chromium.org>
- Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
- Message-ID: <CAChr6Szi2AJTxY1N94q-Q681Q39=TKRgVNd2QzcMduei6W7QBg@mail.gmail.com>
On Fri, Sep 20, 2019 at 2:41 PM David Benjamin <davidben@chromium.org> wrote: > > URLs served over http are marked insecure these days, regardless of how > many labels there are: > https://security.googleblog.com/2018/02/a-secure-web-is-here-to-stay.html > > https://www.blog.google/products/chrome/milestone-chrome-security-marking-http-not-secure/ > > That is a little stronger than I thought it was, but nothing close to the warnings one sees for certificate errors or SafeBrowsing warnings. I just checked Firefox, Chrome, and Safari. Firefox used a little red. :) The UI for insecure email in GMail is stronger. (totally-red lock) > 2) Allow domains to opt-in to HSTS out-of-band, like in software updates >> for an OS. This idea seems intriguing, because it would seem to improve >> security as participants join, unlike a TLS trusted-root store. >> > > The HSTS spec suggests doing this as a the pre-load list and indeed > browsers ship just that. > https://tools.ietf.org/html/rfc6797#section-12.3 > https://hstspreload.org > They do--I've seen the static list built into Chrome. It seems like the list should be global, because the lists didn't seem to match on some important sites. Browsers did record the HSTS data after one visit, but clearing browsing data seemed to reverse this in some cases. Also, if we consider apps that do not present an address bar, an OS-provided list would seem beneficial. thanks, Rob
Received on Friday, 20 September 2019 21:56:45 UTC