W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2015

Re: [upgrade] return=secure-representation

From: Mike West <mkwst@google.com>
Date: Mon, 16 Mar 2015 09:22:15 +0100
Message-ID: <CAKXHy=eKQ-CjpRLC-VFHMmXJTJYT9dVzis8oHAFpqDtxWDPw4g@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Mark Nottingham <mnotting@akamai.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
On Mar 16, 2015 08:29, "Anne van Kesteren" <annevk@annevk.nl> wrote:

> On Mon, Mar 16, 2015 at 7:12 AM, Daniel Kahn Gillmor
> <dkg@fifthhorseman.net> wrote:
> > I think the semantics are likely to include some sense of "it's safe to
> > send me HSTS" as well, not just "redirect me", unless we are willing to
> > consider some flavor of the HSTS2 suggestion.

As I've mentioned in some other threads, I think the link to HSTS is
aspirational. I believe that servers requiring this mechanism are going to
be unwilling to lock themselves into HTTPS right away.

I'd prefer to ship something that solves the problem we know we have, and
build upon it to solve related problems once we have some implementation
experience and feedback from developers.

> Yeah, in light of WebSocket Prefer: hsts might make more sense.

The goal of the signal is to inform servers that require
`upgrade-insecure-requests` as a stepping stone that the mechanism totally
works for this particular user. Ideally, the server would then redirect the
user to a reasonable location, and send the upgrade directive. WebSocket
requests made from _that_ page would be transparently upgraded client-side
(per https://w3c.github.io/webappsec/specs/upgrade/#websockets-integration).

Given that context, `Prefer: https` makes sense to me, and seems to cover
the cases we care about.

Received on Monday, 16 March 2015 08:23:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:47 UTC