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

On Mon, Jan 5, 2015 at 1:51 PM, Mark Watson <watsonm@netflix.com> wrote:

> Sure, but I was addressing the question of whether there was a way to allow
> mixed content without giving misleading indications to users. A site that is
> almost entirely HTTPS, but with HTTP used to retrieve some data resources,
> seems to be better than having the site entirely HTTP, no ? My suggestion is
> that the appropriate UX in that case is the same as an HTTP site, even
> though the security properties might be better.

But you seemed to propose deciding what UX should be appropriate based
on an affirmative user signal.

Additionally, with web apps, there often is no single entry point, and
we can't always be sure when to consider mixed content OK and when to
consider it not OK.

> My second paragraph was entirely a pre-emptive response to the point that
> *some users* do explicitly ask for security - by explicitly typing HTTPS -
> and so one should be careful not just to downgrade them without warning.

I understand. But, keep in mind that we don't get to use our human
minds, at run-time, to decide these things. We get to use our human
minds to write brittle code that has very limited information and
context and yet which must make a safe decision at run-time.

Much of the debate has conflated the 2 perspectives. E.g. "I know what
my site is about and I know what its security requirements, in
isolation, are!" Well, the browser does not and cannot "know" the
requirements or expectations people have.

So, that's why I'm always advocating that we quantize the security
guarantee upward. Unfortunately, we *must* quantize... and therefore,
it *must* be upward.

Received on Monday, 5 January 2015 22:25:24 UTC