Re: Defining secure-enough origins.

Since an origin is just (uri-scheme, uri-host, uri-port)--effectively a
string--but insecurity and authentication in MIX change based on
whether "the user agent discovers only after performing a
TLS-handshake that the TLS-protection offered is either weak or
deprecated", I'm not sure it's appropriate to talk about authenticated
or insecure "origins". I think it's the _resource_ that becomes
insecure if it turns out to have been transferred over a TLS-deficient

The "authenticated environment" term is nice, because it's easy to get
to an environment from any IDL description.

On Fri, Aug 22, 2014 at 2:37 AM, Mike West <> wrote:
> Splitting this off from the other thread for clarity: given that there are
> APIs (ServiceWorker for example) that wish to restrict themselves to some
> "secure" subset of the web, we need to define some set of rules that UAs can
> agree upon (see [1], [2], and [3]). MIX seems like the right place to do
> that.
> I've put up a more formalized version of the rules at [4] as a strawman, and
> renamed the concept "authenticated origin/environment":
> There are two differences between the wiki page and the spec strawman:
> 1. Sandboxed documents use the origin of their location in order to
> determine authentication, rather than their actual origin. That is,
> '' would be considered "authenticated" even if thrown
> into a sandbox which would give it a unique origin. This is in line with
> bz's comments on [1] regarding "secure transport" vs "secure origin".
> 2. 'blob:' and 'filesystem:' URLs created in the context of an authenticated
> origin would themselves be considered authenticated.
> [1]:
> [2]:
> [3]:
> [4]:
> --
> Mike West <>
> Google+:, 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 Thursday, 28 August 2014 16:15:00 UTC