At the F2F meeting this week, we decided to do the simplest thing possible,
and reuse the existing directive name that's shipping in Chrome and Firefox
for the header:
https://github.com/w3c/webappsec/commit/eeac3922418bfa6cb254071c74ddd962ee418c80
I've made that change in Chrome, and I'm working on merging it back to the
upcoming Chrome 44 stable release.
-mike
--
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.)
On Thu, Jul 9, 2015 at 10:08 AM, Jonathan Kingston <jonathan@jooped.com>
wrote:
> The following is the shorter and perhaps more accurate:
> encrypt-insecure: 1
>
> I'd still like:
> Prefer: encrypt-insecure
>
> On 9 July 2015 at 07:39, Mike West <mkwst@google.com> wrote:
>
>> It feels like a distinction without meaning, especially given that we
>> know passive monitoring is happening on a wide scale. Calling unencrypted
>> transport affirmatively "insecure" seems fairly reasonable.
>>
>> -mike
>> On Jul 9, 2015 06:54, "Martin Thomson" <martin.thomson@gmail.com> wrote:
>>
>>> On 8 July 2015 at 21:44, Richard Barnes <rbarnes@mozilla.com> wrote:
>>> > If the web can live with "Referer", it can live with this. But it
>>> seems
>>> > roughly the same order of magnitude. It makes me "sic" :)
>>>
>>>
>>> Sounds about right. Find another perspective, like 'update-to-secure'
>>> if you want to avoid seeming insecure.
>>>
>>
>