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

>
> Well, of the two things which suggest a way out
>
>
>> Well, the first thing is to fix browsers so if they find an ostensibly
>> secure origin loading insecure data, they just downgrade the origin to
>> being deemed insecure rather than blocking it.  Change the UI so that the
>> it doesn't get the green happy certified look to it.
>>
>> Second thing is to roll out HTTP to HTTP/TLS over port 80 using
>> connection upgrade.
>>
>
> the upgrade spec address the second, medium term bit, but leaves the first
> bit to be addressed by changed I am hoping for in MIX.
>
> Is there a reason why that can not be done?
>

Yes.

With regard to the distinction between Blockable and Optionally-Blockable
Content, that portion of the spec is just documenting the existing way that
major user agents have behaved for several years now, not prescribing new
or more strict behavior.  Changing insecure XMLHttpRequest data in a secure
context from blocked to unblocked would be a security _regression_ which no
UA implementer has expressed any interest in making.  Even if we added this
language, it would need to be listed as 'at risk' in the CR draft and I am
quite confident it wouldn't achieve the WG's chartered requirement of two
independent, interoperable implementations to ever advance to
Recommendation.

The reasons why it has been blocked, and why UAs want to continue to block
it, have been articulated up-thread.  A lot of it boils down to what
guarantees are UAs are actually going to make to users.  When the yellow
triangle shows up, things might be mostly OK, or things might have gone
catastrophically wrong: the browser doesn't know and can't communicate
intelligently to the user about it.  Blocking certain kinds of content is
an attempt to make the catastrophic case less likely, but even images can
be bad, e.g. if graphical "save" and "delete" buttons are swapped.

That's bad enough, but it's even worse when it happens asynchronously,
after page load, in response to an XHR.  You loaded up your web email,
checked that the lock was green, then sent some very private
communications.  Afterwards, you notice that where there once was a green
lock, now there is a yellow triangle.  What happened?  You made a trust
decision and now it's been invalidated.  Did your personal data leak? Is it
safe to continue interacting with the applicatIon?

UAs feel that they have a very limited amount of information they can
meaningfully convey to the user on this topic.  "Secure" is useful to
convey.  "Secure, for now, contingently, but maybe insecure at any moment
without your consent and in ways you can't understand" is a much less
useful replacement for "Secure", and arguably not useful at all.

-Brad