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

Re: UPGRADE: Feature detection?

From: Mike West <mkwst@google.com>
Date: Fri, 13 Feb 2015 14:11:51 +0100
Message-ID: <CAKXHy=eWvn6OHOAc=Neqts_Go1m5YNVOVVb0Q0OxB1U+80WN5Q@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Peter Eckersley <pde@eff.org>, Eric Mill <eric@konklone.com>, Jacob S Hoffman-Andrews <jsha@eff.org>
On Thu, Feb 12, 2015 at 5:26 PM, Julian Reschke <julian.reschke@gmx.de>
> Nitpicking on the field name; how about:
>        Prefer: encrypted
> (that at least avoids a new header field name, and already has a
> well-defined syntax and extensibility model).

Hey, look at that. It's exactly what I was looking for. :)

I've added https://w3c.github.io/webappsec/specs/upgrade/#feature-detect,
which defines a `return=secure-representation` preference. I'd like to
avoid the topic of whether or not OE would meet the level of "encrypted",
and piggybacking on the existing `return` preference seems reasonable.

To Anne's point, I've suggested that user agents should only send the
header when requesting insecure resources. That is, we'd allow easy feature
detection for upgrades, but we wouldn't provide the same clarity around
downgrades. Does that seem like a reasonable compromise?


Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany,
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Friday, 13 February 2015 13:12:39 UTC

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