Defining secure-enough origins.

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":
https://w3c.github.io/webappsec/specs/mixedcontent/#authenticated-origin

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, '
https://example.com/' 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.

WDYT?

[1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25972
[2]: https://github.com/slightlyoff/ServiceWorker/issues/385
[3]: https://github.com/w3c/webappsec/issues/41
[4]:
http://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features

--
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 Friday, 22 August 2014 09:38:13 UTC