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

[MIX] Comments on draft Mixed Content spec

From: Tanvi Vyas <tanvi@mozilla.com>
Date: Tue, 03 Jun 2014 22:09:58 -0700
Message-ID: <538EAA26.7070706@mozilla.com>
To: Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Hi Mike,

Thank you very much for putting this spec together!  I went through it 
and have a few comments.

2.1 - localhost is included in the definition of assumed secure origin.  
In Firefox's implementation of the MCB, we block localhost.  We have had 
a number of requests to allow it, but Dan has responded with some good 
arguments to continue blocking it:
https://bugzilla.mozilla.org/show_bug.cgi?id=844556#c58
https://bugzilla.mozilla.org/show_bug.cgi?id=873349#c30

3.1 - Sandboxed iframes
There is some discussion here about whether sandboxed iframed should be 
considered optionally blockable passive content or active content - 
https://bugzilla.mozilla.org/show_bug.cgi?id=903211.  We may need to 
block other allow-* values in addition to allow-top-level-navigation.

Issue 2 & 3- Regarding form submissions, it is difficult to detect 
whether the target of a form is secure until the submit button is 
actually hit.  The form action may be a call to a javascript function.  
Without parsing through the function, the browser does not know whether 
or not the intended destination is secure.  Determining whether an 
insecure form is present and including UI to indicate this to the user 
(i.e. no green lock) seems impossible.  Perhaps someone has an idea on 
how we can do this?
For Issue 2, Firefox presents a warning to the user before the data is 
actually submitted 
(http://people.mozilla.org/~tvyas/https_post_http_with_js.png). This 
warning has been around for many many years, so we may well be able to 
get away with it without much of a web-compatability issue. We can look 
into the percentage of pages that hit this warning as a followup.

4.3 - " Note: It is /strongly recommended/ that users take advantage of 
such an option if provided."
I'm not sure if we want to strongly recommend that users disable 
optionally blockable mixed passive content.  As stated elsewhere in the 
spec, that means that ~43% of secure pages will not function properly.

5.1 - Algorithm.  As Anne has mentioned, the algorithm included in the 
spec doesn't match the examples provided, but you are already planning 
to modify this.

7 - the word "defined" is repeated.

~Tanvi
Received on Wednesday, 4 June 2014 05:10:29 UTC

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