W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2014

Re: Proposal: Marking HTTP As Non-Secure

From: Igor Bukanov <igor@mir2.org>
Date: Sun, 14 Dec 2014 20:26:44 +0100
Message-ID: <CADd11yUkuDXeNw1sKnNj0aAH9HtwKc95CnV=MEQO+bp=bcsMTA@mail.gmail.com>
To: Chris Palmer <palmer@google.com>
Cc: Eduardo Robles Elvira <edulix@agoravoting.com>, "dev-security@lists.mozilla.org" <dev-security@lists.mozilla.org>, blink-dev <blink-dev@chromium.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, security-dev <security-dev@chromium.org>
I would like to see some hypothetical encrypted http:// when a browser
present a page as if it was over https:// if everything of a secure origin
and as if it was served over plain http if not. That is, if a future
browser shows warnings for plain http, so it will show the same warnings
for encrypted http:// with insecure resources.

The point of such encrypted http:// is to guarantee that *enabling
encryption never degrades user experience* compared with the case of plain
http. This will allow for a particular installation to start serving
everything encrypted independently from the job of fixing the content. And
as the page still served as http://, the user training/expectations about
https:// sites no longer applies.

On 14 December 2014 at 20:08, Chris Palmer <palmer@google.com> wrote:
>
> On Sun, Dec 14, 2014 at 10:53 AM, Igor Bukanov <igor@mir2.org> wrote:
>
> I.e. just consider that currently a hosting provider has no option to
>> unconditionally encrypt pages they host for modern browsers as that may
>> break pages of the users. With encrypted http:// they get such option
>> delegating the job of fixing warnings about insecure context to the content
>> producers as it should.
>>
>
> I'm sorry; I still don't understand what you mean. Do you mean that you
> want browsers to treat some hypothetical encrypted HTTP protocol as if it
> were a secure origin, but still allow non-secure embedded content in these
> origins?
>
> I would argue strongly against that, and so far not even the
> "opportunistic encryption" advocates have argued for that.
>
Received on Monday, 15 December 2014 08:56:36 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:08 UTC