- From: Jeffrey Yasskin <jyasskin@google.com>
- Date: Mon, 5 Jan 2015 14:08:47 -0800
- To: Mark Watson <watsonm@netflix.com>
- Cc: Chris Palmer <palmer@google.com>, Tim Berners-Lee <timbl@w3.org>, Brad Hill <hillbrad@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CANh-dXnDH6cNbEaFkvqCS6UuvnjqHgesrtibx4+w_ZjOKW-1-Q@mail.gmail.com>
On Mon, Jan 5, 2015 at 1:51 PM, Mark Watson <watsonm@netflix.com> wrote: > > > On Mon, Jan 5, 2015 at 1:45 PM, Chris Palmer <palmer@google.com> wrote: > >> On Mon, Jan 5, 2015 at 1:32 PM, Mark Watson <watsonm@netflix.com> wrote: >> >> > How about if a page could declare, in the first HTML page that is >> > downloaded, that it intends to use mixed content. In this case the UX is >> > made identical to an http page, though under the covers HTTPS is used >> for >> > many of the resources. >> > >> > In the case where the user explicitly typed "https://..." or clicked >> on a >> > link that was explicitly visible as https, you might want to show an >> > explicit warning. But most of the time users are just typing the domain >> > name, getting redirected from the http:// version or clicking on search >> > engine results (where visible indication of https could be suppressed >> for >> > such sites). >> >> The burden is not on users to declare they want security. >> >> The burden is on site operators -- who at least nominally have the >> knowledge and the ability -- to provide at least the bare minimum. >> > > Sure, but I was addressing the question of whether there was a way to > allow mixed content without giving misleading indications to users. A site > that is almost entirely HTTPS, but with HTTP used to retrieve some data > resources, seems to be better than having the site entirely HTTP, no ? My > suggestion is that the appropriate UX in that case is the same as an HTTP > site, even though the security properties might be better. > That sounds plausible too. So two options on the table so far are: * Use the passive-mixed-content treatment, the locked yellow triangle on https://support.google.com/chrome/answer/6098869. * Use the http treatment: the non-lock document on https://support.google.com/chrome/answer/6098869, subject to future changes per [Marking HTTP As Non-Secure]. (I suppose the third option so far is "OMG Don't do this !!1!!1" :) There's another dimension here around whether "Powerful Features" could work on such pages, but I think that's a separate topic from the one Tim started. My second paragraph was entirely a pre-emptive response to the point that > *some users* do explicitly ask for security - by explicitly typing HTTPS - > and so one should be careful not just to downgrade them without warning. > > ...Mark > >
Received on Monday, 5 January 2015 22:09:39 UTC