RE: Comments on Mixed Content

Agree  we are getting closer.

Thanks,
_dave_

> From: Mike West [mailto:mkwst@google.com] 
> Sent: Tuesday, January 13, 2015 10:51 PM
> To: David Walp
> Cc: Anne van Kesteren; Chris Palmer; public-webappsec@w3.org
> Subject: 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?

We understand your arguments.  We already live with these issues every day.  Being able to handle the intranet different from the internet is important to a number of customers.   Provided we not consider out of compliance for how we handle the intranet, we are fine with the spec as it is.
 
>>> 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.
 
Sounds like we are in agreement.

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

Thank you!
 
> 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?

We think more explicit here would be helpful.

Received on Thursday, 15 January 2015 00:28:45 UTC