- From: Chris Palmer <palmer@google.com>
- Date: Tue, 15 Jul 2014 10:57:51 -0700
- 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