- From: Sigbjørn Vik <sigbjorn@opera.com>
- Date: Mon, 30 Jun 2014 10:27:07 +0200
- To: Chris Palmer <palmer@google.com>, "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
On 28-Jun-14 00:55, 'Chris Palmer' via Security-dev wrote: > * Proposal > > 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. 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. > "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. Overall, making powerful features less accessible to insecure web pages sounds like a good idea. :) -- Sigbjørn Vik Opera Software
Received on Monday, 30 June 2014 08:27:40 UTC