FWIW, I don't think Firefox is sending the header yet, so we'll just do the
right thing when we get to it.
On Thu, Jul 16, 2015 at 9:49 AM, Mike West <mkwst@google.com> wrote:
> 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.
>>>>
>>>
>>
>