Re: [MIX] Initial feedback on Mixed Content

On Mon, Nov 24, 2014 at 1:16 AM, Mike West <mkwst@google.com> wrote:
> Thanks again! Here's a little additional commentary.
>
>>  21, 2014 at 11:48 PM, Brian Smith <brian@briansmith.org> wrote:
>>>
>>> Note that I'm not sure any browser other than Chrome implements the
>>> logic for "deprecated TLS-protection."
>
> I think Mozilla's SHA-1 deprecation flow will end up looking similar to
> Chrome's. I don't know if that team in particular wants to start treating
> SHA-1-protected resources as mixed content, but Chrome certainly plans to.

Are you saying that literally zero implementations implement this part
of the document now?

> It's not clear that we can define it in a way that's not immediately
> outdated, hence the open-ended definition. See
> http://www.w3.org/TR/2010/REC-wsc-ui-20100812/#typesoftls for examples of
> how that goes wrong over time.

The document can be updated as necessary (in WHATWG at least, and
probably W3C). Making things intentionally vague and under-specified
seems like a worse alternative than that.

> I think it's always the case that we will need mechanisms for deprecating
> cipher suites, signing algorithms, etc. I'm open to suggestions around
> phrasing that requirement in a less vendor-specific way, but I'm reluctant
> to remove it from the spec, as I do think it's a pretty reasonable concept
> to enshrine in spec text.

Chrome already may do this kind of blocking, even if the text is
removed from the specification. And, to be clear, I think it is good
for all browsers to try such things.

My comment was basically "this doesn't actually specify anything
normatively, and there's not enough implementation experience, and so
it should be removed." If there at least two browsers implement the
blocking of some particular kinds of deprecated TLS thing as mixed
content, then given a non-empty list of such things, I would be happy
to donate my time to writing the normative text for them. The question
is about what to do when that list is empty; i.e. when there's no
agreement. I think parts of specs for which there's no agreement
should be removed.

See also http://www.w3.org/TR/html-design-principles/#well-defined-behavior
and "Success Criteria" in the webappsec charter:
http://www.w3.org/2013/07/webappsec-charter.html. I think it is
important to stick to guidelines in order to ensure good results.

Cheers,
Brian

Received on Monday, 24 November 2014 22:26:59 UTC