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

On 9 Jun 2014, at 21:21, Mike West <> wrote:
> Did you give consideration to the suggestion above that developers
> could simply be asked to accept a self-signed certificate presented by
> the device upon connection? It seems like that would properly put the
> burden of bypassing the existing PKI implementations upon the subset
> of users who want to develop applications on the web that are
> distributed to devices without installing any software.

As far as I’m aware, this option is not actually presented to the user
unless we route them to an actual page presenting that certificate;
otherwise the connection just errors without intervention. I haven’t
checked lately, though. As of the last time I checked, it does then
temporarily cache that acceptance as you say.

We could probably arrange for the user to be bounced to a page on
their device in the case of validation failure, but sticking them
through a screen designed to aggressively discourage them from
proceeding is far from ideal. Also problematically, the user would
probably be unable to distinguish an actual validation failure on
the site itself from its “standard” behaviour of throwing the same
warning in their face and not working if they don’t accept it.

> If it works the way I'm claiming it does (Joel? :) And perhaps someone
> from Mozilla can weigh in about their implementation...), it would
> seem to be a relatively low burden for that subset of users to bear,
> and would entail no change from status-quo for the rest of the web.

I agree that it’s a *low* burden for them - but it is (intentionally) a
very *discouraging* burden and probably not the sort of thing we want to
encourage dismissing out of hand. These people are not web developers
and are unlikely to understand why our presentation of this interstitial
is “okay” and other sites doing it unexpectedly still is not.

(Of course, this doesn’t stop other sites doing it, so maybe we just
don’t care…)

– Katharine

Received on Tuesday, 10 June 2014 06:06:07 UTC