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

Re: [MIX]: Expand scope beyond TLS/non-TLS (Re: "Mixed Content" draft up for review.)

From: Zack Weinberg <zackw@cmu.edu>
Date: Thu, 5 Jun 2014 20:29:28 -0400
Message-ID: <CAKCAbMh-Of27LJTy0SFBkZZ+RuzjsetXMX=ouXnpFwzgeLhxMA@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Brian Smith <brian@briansmith.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Thu, Jun 5, 2014 at 8:48 AM, Mike West <mkwst@google.com> wrote:
> https://github.com/w3c/webappsec/commit/d635094f4e6f6a27fd565f63c9570858de27172b
> is a first pass at making this change. The draft at
> http://w3c.github.io/webappsec/specs/mixedcontent/ has been updated
> accordingly; it's probably easier to read there. :)

This addresses my initial concerns, but on reread, I have a couple more.

This is largely editorial, but the wording regarding "assumed
insecure", "assumed secure", and "proven insecure" could be better:
right now it makes it sound like the UA has to make a network request
before it can move something from "assumed insecure" to "proven
insecure".  Only by reading the entire spec carefully, and the
definition of "TLS-protected" in WSC-UI, does it become clear that
"proven insecure" is a state transition from "assumed *secure*" -- we
thought this was going to be secure, but then the cipher is weak or
something so it isn't.  I think the problem is with "assumed" and
"proven"; maybe "insecure by definition", "assumed to be secure", and
"discovered to be insecure" would be clearer.

On a more substantive note, I'm aware of one scenario where being able
to refer from a public to a private origin is desirable: suppose you
have a network-attached home device (which, in the US anyway, will be
on a private-use IP address behind NAT, accessible from a browser on
the same NAT, but not by the public Internet), the vendor's website
might like to offer a configuration interface to that device.  I know
one developer in particular who has been very frustrated with
Firefox's existing restrictions on that sort of thing; I could invite
her to explain further if it would be helpful.  Some sort of opt-in
mechanism from the device side (reuse Access-Control-Allow-Origin,
perhaps?) might thread the gap between "can't be done" and "drive-by
pharming: game on!"  (Obviously doesn't have to be in level 1 of the
spec.)

zw

p.s. Please spell the short form of my name with a 'k'.
Received on Friday, 6 June 2014 00:29:53 UTC

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