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

Tim,

  I'd like to return to this, as the group would like to move Mixed-Content
to Candidate Recommendation and want to be sure you feel your concerns have
been substantively addressed.

  Unfortunately, I don't think we've arrived at a solution for your concern
we can add to the spec.  My read of the conversation so far is that we:

*  Don't have techniques to allow inclusion of arbitrary data to be loaded
insecurely into secure contexts without catastrophically damaging the
actual security guarantees users expect from an https resource.  Data is
special, but many examples demonstrate the danger to users of insecure
data, even if treated with proper care to separate it from code. (which
separation is also not mandatory or even typical on the Web platform)

*  Don't have a way to clearly communicate to users who often struggle to
understand a binary secure/insecure distinction a fuzzy state of "maybe
secure if there are no network attackers"

I think it would be more productive to focus on outreach, removing the
obstacles to upgrading to https ( I asked on the LDP mailing list about
this, with no replies yet:
https://lists.w3.org/Archives/Public/public-ldp/2015Jan/0002.html ) and
perhaps on better algorithms in user agents for optimistic upgrade.

That broader discussion is happening over in the TAG currently with their
draft finding on Transitioning the Web to HTTPS.

Are you satisfied that your concerns have been reasonably addressed?  Do
you feel there was an alternate path forward from this thread that I failed
to extract?

Thank you,

Brad Hill
Co-chair, WebAppSec


On Mon Jan 05 2015 at 4:31:30 AM Tim Berners-Lee <timbl@w3.org> wrote:

>
> On 2015-01 -05, at 06:45, Anne van Kesteren <annevk@annevk.nl> wrote:
>
> > On Mon, Jan 5, 2015 at 12:26 PM, Tim Berners-Lee <timbl@w3.org> wrote:
> >> They are not.  Data is special
> >
> > Right. I think you could make your point more clear if rather than
> > talking about scripts (which could themselves create <script> elements
> > and such) you instead focused on the use case you care about, loading
> > some data from another origin.
>
> Indeed .  The example is loading legacy http: data from a secure web app.
>
>
> >
> > There's already a problem with that today, it requires the other
> > origin to use CORS.
>
> CORS does not work with a secure app and a http: data site.
> The wildcard CORS is blocked.
>
> Or you have to put your script on a http: page for it to work.
>
> Hence my suggestion is is broken to have something work from a http page
> but not from an https one.
>
> > If it does not have that you need to use a proxy
>
> This means that the actual application center of mass is moved onto the
> server.
> This makes yet another silo.
> This makes all the user's activity available to the person who runs the
> proxy.
> This makes the user's activity available to anyone who subpoenas or cracks
> the proxy.
>
> > (or indeed a native app).
>
> Yes.
>
> > If you want to authenticate your application it requires the other
> > origin to support TLS (in addition to CORS). Again, you can use a
> > proxy to circumvent this (or indeed a native app).
> >
> > Not having these restrictions in place enables all kinds of attacks
> > and classic bugs ;-)
> >
> >
> > --
> > https://annevankesteren.nl/
> >
>
>