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

Re: [blink-dev] Re: Proposal: Marking HTTP As Non-Secure

From: Andy Wingo <wingo@igalia.com>
Date: Tue, 16 Dec 2014 10:14:39 +0100
To: Ryan Sleevi <rsleevi@chromium.org>
Cc: Igor Bukanov <igor@mir2.org>, Daniel Veditz <dveditz@mozilla.com>, Michal Zalewski <lcamtuf@google.com>, Peter Bowen <pzbowen@gmail.com>, Chris Palmer <palmer@google.com>, 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>
Message-ID: <87mw6oc5xc.fsf@igalia.com>
On Tue 16 Dec 2014 06:35, Ryan Sleevi <rsleevi@chromium.org> writes:

> scheme-relative URLs are awesome, and we should encourage them (over
> explicit http://-schemed URLs)

Isn't it an antipattern to make a resource available over HTTP if it is
available over HTTPS?  In all cases you could just use HTTPS; no need to
provide an insecure option.

The one case that I know of when scheme-relative URLs are useful is when
HTTPS is not universally accessible, e.g. when the server only supports
TLSv1.2 and so is not reachable from old Android phones, among other
UAs.  In that case scheme-relative URLs allow you to serve the same
content over HTTPS to browsers that speak TLSv1.2 but also have it
available insecurely to older browsers.

If there is mention of scheme-relative URLs in a "Marking HTTP as
Non-Secure" set of guidelines for authors and site operators, it should
be to avoid them in favor of explicitly using the HTTPS scheme.

Received on Tuesday, 16 December 2014 22:47:01 UTC

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