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

On Mon, Jan 5, 2015 at 2:24 AM, Tim Berners-Lee <timbl@w3.org> wrote:

>
> On 2015-01 -02, at 16:14, Brad Hill <hillbrad@gmail.com> wrote:
>
> Tim,
>
> Thanks for chiming in.  If I may endeavor to clarify a couple of things:
>
>
>> I would like to introduce a requirement:
>>
>> *No script which works when served as http: should fail when instead
>> served from https:*
>>
>>
> There is a distinction here that the phrasing of this requirement misses -
> between the behavior of a secure document context and the location from
> which a script is served.
>
>
> You are right of course.    I guess the requirement needs to be rewritten
> more like:
>
> *No script which works when served as http: within an http: web page
>> should fail when instead served from https: within a https: web page*
>>
>
>
This requirement implies that an environment with an 'authenticated' TLS
State (https://fetch.spec.whatwg.org/#concept-response-tls-state and
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27190) could load new
scripts over HTTP and so expose user credentials to any network attacker.
For that reason, I think it's unrealistic.

However, the full strength of this requirement isn't necessary to support
the mashup case. I think all you really need is some way for an
'authenticated' environment 'E' to fetch() (XHR) data from unauthenticated
origins. Even a restriction that 'E' has a CSP that bans unsafe-eval would
let the mashups work.

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
<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?

Jeffrey