On Thu, Sep 18, 2014 at 8:23 PM, Chris Palmer <[email protected]> wrote:
> Please keep in mind that the origin is the security boundary on the
> web, and is defined as being (scheme, host, port).

And optional additional data:
https://html.spec.whatwg.org/multipage/browsers.html#origin


> Assuming we don't expand the definition of the origin, unless we
> implement mixed-everything blocking — mixed EV & non-EV, mixed TLS 1.2
> & 1.1, mixed AES-128 & AES-256, mixed pinned keys & non-pinned, et c.
> — then I don't think we should make any increased promise to the user.
> After all, the promise wouldn't be true.

I'm not sure I follow. If there's mixed content you no longer get a
lock at all in Firefox. Obviously we should not revert that.

There's a few options here:

* We pose additional requirements on EV UI. E.g. you have a EV
certificate, but you are not deploying HSTS, then we might not deem
that good enough and therefore give you the same UI as TLS domains
without EV.

* In Firefox we could offer a green lock of sorts for sites deploying
TLS and doing so in a good way. E.g. with TLS 1.2, good cipher, etc.


> Let's keep our eye on the ball *currently in play*: Getting all
> origins up to the minimum standard of nominally-secure transport. Once
> we achieve that, then we can consider splitting finer hairs.

Given the time it takes to get changes through, it seems fine to start
discussing them.


> The hair I'd much rather split, by the way, is making each
> cryptographic identity a separate origin. Ponder for a moment how
> enjoyably impossible that will be...

What are the issues?


(There's also an idea floating around about checking certificates
first when doing a same-origin check, potentially allowing distinct
origins that share a certificate through alternate names, to be
same-origin. However, with CORS it might not really be needed
anymore.)


-- 
https://annevankesteren.nl/
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to