[MIX]: "Assumed"/"Proven" Terminology. (Re: [MIX]: Expand scope beyond TLS/non-TLS)

Thanks Jeffrey and Zack (and sorry about the misspelling; I'll pay more
attention from now on). Forking this piece off to keep the other thread
focused on the private/public distinction.

On Fri, Jun 6, 2014 at 3:43 AM, Zack Weinberg <zackw@cmu.edu> wrote:

> > It seems like there are two mutually exclusive states: secure and
> > insecure. The states are based on security model, threat models and
> > cryptographic analysis. There's not much room for debate. You can't
> > get half pregnant...
>
> Right, as far as I can tell the distinction in the spec between
> "assumed insecure" and "proven insecure" is just about *how the UA
> knows* that an origin is insecure.  "Assumed insecure" means the UA
> knows /a priori/ it's insecure (http:// scheme); "proven insecure"
> means it *could have* been secure, but empirically it isn't (https://,
> but the server insists on using RC4 or some other weak cryptosystem).
>

Your interpretation is exactly what I was trying to express. We need one
check that we can do before making a network connection ("Is it HTTP? Skip
it."), and one check we can do after the TLS-handshake ("You want to use
DH_anon? Really?").

The terminology I started with was "a priori insecure" and "a posteriori
insecure"[1]. I assumed that was too Kantian for a spec, but since you also
landed on that distinction, I'm going to run with something like it. :)

After
https://github.com/w3c/webappsec/commit/7ba230e320366114468235192903cb740070e239,
origins are either "a priori insecure
<https://w3c.github.io/webappsec/specs/mixedcontent/#a-priori-insecure-origin>",
"potentially secure
<https://w3c.github.io/webappsec/specs/mixedcontent/#potentially-secure-origin>",
or "insecure
<https://w3c.github.io/webappsec/specs/mixedcontent/#insecure-origin>"
(where "a priori insecure" is a subset of "insecure"). WDYT?

-mike

[1]:
https://github.com/w3c/webappsec/commit/6e9bbfa45ee21498fceccf4b52f8558886b20ed1