W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2014

Comments on Mixed Content

From: David Walp <David.Walp@microsoft.com>
Date: Wed, 10 Dec 2014 22:32:03 +0000
To: "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <BY2SR01MB6086E16191D1B3A196B6CDB9B620@BY2SR01MB608.namsdf01.sdf.exchangelabs.com>
Hi

Based on our detail reviews of the Mix Content draft, we have the following comments:

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.

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?

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?

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.

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

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

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.

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?

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.

Cheers,
_dave_
Received on Wednesday, 10 December 2014 22:35:44 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:08 UTC