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

On Fri, Mar 6, 2015 at 5:07 PM, Brad Hill <hillbrad@gmail.com> wrote:
>
>
> 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?
>

Suppose I fill out a form with a username and password, or a confidential
message. It POSTs to a third party website, who does a preliminary check,
307s to a plaintext connection, which 303s back to my site with a token
verifying the submission.

The majority of user agents will not make a peep about this (none that I
tested, even), and the user sees the padlock icon through the entire
process.

This poses the following questions:

Is this a violation of the user's trust as you describe?

Is this "Secure" (without qualification)? If so, is it "Secure" because,
and only because, we see the padlock icon? If not, why?

Does something need to be fixed here? If so, what?

Assuming "https to do anything http can do" were assumed to not be 'broken'
(i.e. ignoring your above-given criteria of secure), would this still be
'broken' for some other reason?

If this behavior isn't worth fixing, is "https should do anything http can
do" worth implementing? If not, is this for historical reasons, or would
this behavior disappear if reinvented from scratch?

If the behavior is worth fixing, how do you indicate the violation to the
user? Could this fix also be applied to "https can do anything http can do?"

Is e.g. GitHub's Camo [1], the proxying of insecure content over TLS, a
violation of the user's trust? Is there a way a user agent could detect
this insecure behavior?

Would you still call this kind of proxy "Secure" (full-stop) because of the
padlock? If so, would you be comfortable with hypermedia developers using
this as a solution, pretending to the user that their actions are
end-to-end secure? If not, what qualifications do we need to add to
"Secure"?

Austin Wright.

[1] https://help.github.com/articles/why-do-my-images-have-strange-urls/