Re: [MIX] Require HTTPS scripts to be able to anything HTTP scripts can do.

On Mon, Jan 5, 2015 at 11:52 AM, Chris Palmer <palmer@google.com> wrote:

> On Mon, Jan 5, 2015 at 10:24 AM, Jeffrey Yasskin <jyasskin@google.com>
> wrote:
>
> > To get the discussion on the same page, I'd like to make the strawman
> > proposal:
> >
> > The fetch() API should provide some flag that explicitly skips the
> > mixed-content checks (https://fetch.spec.whatwg.org/#concept-fetch).
> > Possibly this flag should only work when the environment's CSP is
> > "sufficiently" restrictive. The Response object should expose its
> associated
> > TLS state.
> >
> > The concerns about tampering with pure data that Daniel, Martin, and
> other
> > have expressed are real, so I'm not sure I support my strawman, but I
> think
> > it's at least plausible.
> >
> > My biggest question about this is "how do we communicate it to users?"
> HTTPS
> > and the green lock icon currently mean that the connection is
> authenticated,
> > has integrity, and is confidential. A fetch() that skips mixed-content is
> > definitely not confidential, and probably doesn't have authentication or
> > integrity. Is the current passive-mixed-content indicator enough for
> this?
>
> We must start with the story about how we'll communicate it to users.
> Without that, we go off the rails immediately.
>
> And, I don't think we can really afford to add more nuance and
> distinctions in the already-too-complicated security UX in browsers.
>
>
​How about if a page could declare, in the first HTML page that is
downloaded, that it intends to use mixed content. In this case the UX is
made identical to an http page, though under the covers HTTPS is used for
many of the resources.

In the case where the user explicitly typed "https://..." or clicked on a
link that was explicitly visible as https, you might want to show an
explicit warning. But most of the time users are just typing the domain
name, getting redirected from the http:// version or clicking on search
engine results (where visible indication of https could be suppressed for
such sites).

...Mark

Received on Monday, 5 January 2015 21:32:58 UTC