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

Re: Proposal: Marking HTTP As Non-Secure

From: Chris Palmer <palmer@google.com>
Date: Sun, 14 Dec 2014 10:40:56 -0800
Message-ID: <CAOuvq23kriUHWS26ZH8chEm497kNCwZORxi1O5b+GwMB=1j4MA@mail.gmail.com>
To: Igor Bukanov <igor@mir2.org>
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>
On Sun, Dec 14, 2014 at 10:34 AM, Igor Bukanov <igor@mir2.org> wrote:

If serving context over HTTPS generates broken pages, the insensitive of
> enabling encryption is very low.
>

That's the definition of a collective action problem, yes.

I think that the incentives will change, and are changing, and people are
becoming more aware of the problems of non-secure transport. There is an
on-going culture shift, and more and more publishers are going to offer
HTTPS. For example,
http://open.blogs.nytimes.com/author/eitan-konigsburg/?_r=0.

As it was already mentioned, a solution to that is to allow to serve
> encrypted pages over HTTP so pages that refer to unencrypted elements would
> not break pages but just produces warnings. Such encrypted http:// also
> allows to generate less warnings for a page where all context is available
> over self-signed and key-pinned certificate as that solution is strictly
> more secure then a plain HTTP.
>

But, again, consider the definition of the origin. If it is possible for
securely-transported code to run in the same context as non-securely
transported code, the securely-transported code is effectively non-secure.
Received on Sunday, 14 December 2014 18:41:24 UTC

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