- From: Mike West <mkwst@google.com>
- Date: Tue, 25 Nov 2014 09:16:11 +0100
- To: Brian Smith <brian@briansmith.org>
- Cc: Jake Archibald <jakearchibald@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAKXHy=dt_9_cWaHcUCZTNw1B2Hhw+95ToWytrYhNLFE9Gdjf_w@mail.gmail.com>
On Mon, Nov 24, 2014 at 11:26 PM, Brian Smith <brian@briansmith.org> wrote: > Are you saying that literally zero implementations implement this part > of the document now? > I'm saying that Sleevi and I on the hook for this implementation before Chrome 41 branches. :) 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. > Of course Chrome can do whatever it likes; as can Firefox, IE, Opera, and etc. Pointing out a particular class of thing that browsers can do, noting that they're encouraged to do so, and noting further that it's better if they return a network error rather than supporting the connection all seem like reasonable things to put into a spec. 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. Browsers certainly block certain kinds of TLS. SSL 3.0, for instance. And terrible cipher suites that we all know are bad. Listing all the bad crypto that browsers don't support would take a while. -- Mike West <mkwst@google.com> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Tuesday, 25 November 2014 08:17:02 UTC