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

Re: Proposal: Prefer secure origins for powerful new web platform features

From: Chris Palmer <palmer@google.com>
Date: Tue, 15 Jul 2014 10:57:51 -0700
Message-ID: <CAOuvq22ZuF156uJzgY_bvVOrQpuLRvGU6Zg74+fLun3ksQdnWw@mail.gmail.com>
To: Sigbjørn Vik <sigbjorn@opera.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, blink-dev <blink-dev@chromium.org>, security-dev <security-dev@chromium.org>, "dev-security@lists.mozilla.org" <dev-security@lists.mozilla.org>
On Mon, Jun 30, 2014 at 1:27 AM, Sigbjørn Vik <sigbjorn@opera.com> wrote:

>> The Chrome Security team and I propose that, for new and particularly
>> powerful web platform features, browser vendors tend to prefer to make
>> the the feature available only to secure origins by default.
>
> I assume you don't mean that powerful features should be available by
> default, but rather that the opt-in UI should only be available on
> secure web pages? And that for insecure web pages, the UI might be
> hidden/scary/temporary/etc.

Yes, that is how I imagine the policy would be best applied. I don't
imaging giving any HTTPS page full access to all powerful goodies with
no user interaction. :)

> I also assume that you are talking about secure web pages, and not
> secure origins. Web pages served from secure origins can be insecure by
> including insecure inlines, by triggering fraud/spoof checks, by
> breaking browser heuristics (e.g. pinning) by changing too much, through
> interference from insecure extensions, etc, and we presumably don't want
> to give these sites access.

Right.

>> "Secure origins" are origins that match at least one of the following
>> (scheme, host, port) patterns:
>>
>>     * (https, *, *)
>
> That is a required part of the definition, but not sufficient. In
> addition to using https, a secure origin should also limit itself to
> secure https algorithms, have a matching and validating certificate, and
> possibly more. The definition of "more" might also change over time, and
> vary between browsers, e.g. requiring CT would make any hard definitions
> unworkable. Browsers generally have a fairly good UI indicating secure
> vs non-secure web pages, deferring to this might be sufficient.

I agree. Ryan Sleevi and I have been gradually deprecating and then
removing support for the obviously-broken cipher suites, weak keys,
and so on. For now, I just want to pin down a bare minimum; ratcheting
up the definition of "secure transport" has been and will be on-going
work.

> Overall, making powerful features less accessible to insecure web pages
> sounds like a good idea. :)

Thanks! And thanks to everyone for your feedback.
Received on Tuesday, 15 July 2014 17:58:18 UTC

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