- From: =JeffH <Jeff.Hodges@KingsMountain.com>
- Date: Mon, 02 Jun 2014 17:10:24 -0700
- To: Ryan Sleevi <rsleevi@chromium.org>
- CC: W3C Web App Security WG <public-webappsec@w3.org>
> Note that I am only arguing this for HSTS, which is a clear signal of
> opt-in by the server operator, and for which the primary purpose is to
> hide 'user' mistakes (forgetting the scheme in the URL bar) rather than
> 'author' mistakes.
Well, it of course depends upon the mindset of the 'server operator'. From
both my perspective as an HSTS author (and Adam B. & Colin in their original
ForceHTTPS paper), and my day job at PayPal (i.e., one of them 'server
operators'), we value the HSTS policy equally as a protection for both user
and developer 'mistakes'.
Note also that we explicitly didn't prioritize between those two (sub-)use
cases in the HSTS spec <https://tools.ietf.org/html/rfc6797#section-2.1>..
2.1. Use Cases
The high-level use case is a combination of:
o Web browser user wishes to interact with various web sites (some
arbitrary, some known) in a secure fashion.
o Web site deployer wishes to offer their site in an explicitly
secure fashion for their own, as well as their users', benefit.
HTH,
=JeffH
Received on Tuesday, 3 June 2014 00:10:58 UTC