Re: Comments on Mixed Content

Thanks for your feedback, David! It sounds like we're getting closer!

On Wed, Jan 14, 2015 at 12:03 AM, David Walp <David.Walp@microsoft.com>
wrote:

> > 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.
>
> Given that not all browser are able to distinguish between Intranet and
> Internet, unless we hear otherwise we will assume this specification is
> specific to the Internet environment.  OK?
>

Based on Chris' comments and my own, I would have expected the opposite
conclusion. :)

It's not clear to me what advantage we gain by allowing intranet resources
to be less secure than internet resources. Did neither of our arguments
appeal to you?


> > 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).
>
> Because it is difficult (at least for us ) to understand what a plugin is
> doing, we have to rely on the plugin to do the right thing.  Our proposed
> tact would be users are responsible for the plugins installed and user
> agents should not be considered out of compliance because of user installed
> plugins. Sound OK?
>

I'd suggest that the spec should create requirements for plugin behavior,
just as the CSP spec does. It's likely that we won't be able to hit 100%
conformance, but we should be very clear about the direction we're pushing
towards.

Regarding the user agent's conformance, I'd suggest that it would be (for
example) Adobe's responsibility to provide a Flash plugin that meets the
spec's requirements, and we wouldn't ding IE for not meeting the
requirement.


> > I think the intent is fairly straightforward, but I'm happy to consider
> suggestions for a phrasing that would be less confusing.
>
> How about instead of "instead return a synthetically generated network
> error response" the wording "instead be treated as if a network or security
> error is returned."?
>

Sure. I'll look at the Fetch spec again and copy/paste whatever the current
wording for network error is.


> > On Thursday, December 11, 2014 4:09 AM, Anne van Kesteren
> annevankesteren@gmail.com
> >
> > WebSocket is its own stack. XMLHttpRequest however builds on the same
> stuff <img>, <script>, background-image, <link rel=icon>, sendBeacon(),
> etc. build on, Fetch. > They should have consistent handling of this stuff
> and it should be in the network layer. We also don't want that each new API
> we introduce that builds on Fetch, e.g.
> > fetch(), has to consider this and special case Mixed Content behavior.
> > That's just very bad layering.
>
> We think we are consistent between Websockets & XHR in our engine under
> development.  And we think our behavior is the same as Chrome.  Neither
> should throw an exception.
>

Ok. Then we'll need to ask the websocket folks to change their spec to stop
throwing; I'm fine with that as a solution for the same reasons that Anne
convinced me to be fine with not throwing for XHR.

Chrome's implementation might not match the spec here; I'll need to write
some tests to verify our behavior.


> > 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.
>
> As a.com was loaded over a secure connection, the framed data URL
> inherited the secure context of its parent and hence loading from evil.com
> is blocked.  Make sense?
>

It's not clear that we're disagreeing about the conclusions here. :) Do you
still think the wording needs to be changed?

-mike


--
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.)