Re: Comments on Mixed Content

Thanks for the feedback, David! I'll address the individual points inline.

On Wed, Dec 10, 2014 at 2:32 PM, David Walp <David.Walp@microsoft.com>
wrote:

>  1) Section 2.2, TLS-protected & Weakly TLS-protected (and throughout the
> spec).
>
>  There appears to be an assumption the only environment is the internet
> and that intranet environments are not addressed.   We think this would be
> addressed by adding wording in section 2.2 that stated User agents are free
> to interpret protection with in a trusted environment.
>

I share Chris' skepticism of such wording. The NSA's infamous "SSL added
and removed here" slide should make it quite clear that intranets are a)
targets, and b) not as secure as we'd all like them to be.

Additionally, intranets are free to use insecure transport if they choose
to. `http://intranet/` would not trigger mixed content warnings (and would
also be clearly insecure). If an intranet chooses to use secure transport,
we should not reduce their expectations of security based simply upon
hostname or IP address.


>  2) Section 3.2, "Plugin data" in bulleted list.
>
>  Our assumption is blocking (or not blocking) of the plugin data is the
> responsibility of the plugin.   Correct?
>

That likely depends on the implementation. In Chrome, the PPAPI version of
Flash sends at least most of its traffic through Chrome's network stack,
which means we can make some progress in terms of blocking mixed requests
without relying on the plugin to do so for us.

It's entirely possible that other implementations will need to rely on the
plugin itself to do blocking (as Chrome and other UAs do with Flash and
Incognito mode today).


>  3) Section 3.2, "cspreport" in sentence starting with "These resource
> types map to the following Fetch request contexts:".
>
>  Our concern is that using cspreport is a valid method to find mix
> content.  Is there another specified method to find mix content?
>

CSP is a great way to discover mixed content! However, this document
requires that your CSP endpoint must be secure if the page generating
reports is secure. This seems like a reasonable restriction to ensure the
privacy properties of HTTPS are kept intact.

 4) Section 4.1,  twice there is the text "return a synthetically generated
> network error response".
>
>  The statement " return a synthetically generated network error response"
> doesn’t reflect the goal of the requirement to us.  We think the statement
> is related to the need to return network error to script on the web page
> because of mixed content.  Please can we get some clarification about the
> requirement behind this text.
>

First, note that section 4 has been more or less dropped entirely in the
latest editor's draft, in response to some of Brian Smith's feedback from a
week or three ago.

Second, that phrase is pointing to Fetch's concept of a "network error"
(see https://fetch.spec.whatwg.org/#concept-network-error). The goal is to
ensure that the Fetch process doesn't return (or request!) actual data from
the network, but instead pretends that a network error occurred, and deal
with the request just as though someone had yanked out your ethernet cable
during the request. See step #4 of https://fetch.spec.whatwg.org/#fetching
for details of how this works.

I think the intent is fairly straightforward, but I'm happy to consider
suggestions for a phrasing that would be less confusing.

 5) Section 4.1, list items #1 and #3.
>
>  Why is there an inconsistency in the error handing mechanism between #1
> (XHR) and #3 (Websockets)?
>

WebSockets currently throw if the secure flag is false but the calling
origin is secure (see step #2 of
http://www.w3.org/TR/2012/CR-websockets-20120920/#the-websocket-interface.

Anne (CC'd) convinced me that changing XHR to do the same would be a bad
idea from a compatibility perspective. However, given that WebSockets is
already throwing, and has been for years, it seems reasonable to simply
update it's language to match this specification and current concepts (note
that "entry script" no longer exists).


>  6) Section 5.1, Example 4.
>
>  We would like to understand the rationale behind this example.  Given
> a.com is already unsecure, how is user to understand the iframe with b.com
> is different (aka secure).
>

I agree with you that the end-user can't be expected to understand or
distinguish between portions of a page which are framed or native. I don't
believe that user expectations are the only expectations we need to care
about.

In particular, it seems unwise to allow a site's security properties to be
changed based on the context in which it is loaded. If I serve a site over
HTTPS, that ought to give me certain expectations for behavior, and allow
me to assume certain limitations.

Consider, for example, a page on `b.com` which mistakenly attempts to load
script from an insecure source. That script should be blocked, for `b.com`'s
protection, regardless of the page's ancestry.

 7) Section 5.1, Example 5 - "even though the framed data URL was not".
>
>  We believe the text "even though the framed data URL was not" is
> incomplete.  Our opinion is that data URL should be treated the same as the
> web page that contains the data URL.
>

`data:` URLs usually aren't delivered over a secure connection. Typically,
they're (probably) synthesized by JavaScript and injected into a page. This
could potentially even happen from a child frame (`window.parent.frames`)
or from an ancillary browsing context (`window.opener.frames`).

In this case, there's no meaningful distinction: we treat the frame as
secure if one or more of its ancestors is secure, and as insecure otherwise.

How would you suggest that we change the phrasing of this example, assuming
you agree with the conclusion that the insecure request to `
http://evil.com/` ought to be blocked?

 8) Sections 5.2  &  7 - What about legacy - XHR?.
>
>  Sections 5.3 & 7 both address Fetch implementations but there are not
> similar sections for XHR.  Given the current wide adoption of XHR, why are
> similar sections about XHR not needed?
>

Fetch defines the mechanisms that XHR uses in order to go out to the
network, grab data, and return it to the client. In other words, XHR is
layered on top of Fetch, so altering Fetch to support mixed content checks
implicitly alters XHR as well.

 9)  Section 5.2.
>
>  We believe that examples at the end of section 5.2 (like section 5.1)
> would be very useful and add clarity.
>

Noted. I'll add an example or two here and in section 5.3.

Thanks again, this is helpful!

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)