Re: A somewhat lame Web Crypto PIN provisioning solution

On Tue, Apr 2, 2013 at 2:48 PM, Ryan Sleevi <sleevi@google.com> wrote:
> ....
>
> If an origin does not trust itself (for example, it expects to host
> both 'sensitive' and 'hostile' code on the same origin), then it
> should use the same technique that sites have been deploying for the
> past decade - separating security zones on the basis of origins.
> Google, for example, has done this quite successfully with
> accounts.google.com versus the rest of its domains, as have a number
> of other large sites. This is not limited to the Web Crypto API - this
> is a security approach fundamental to the web.
In practice, Google violates SOP from the user's perspective. From the
user's perspective, domain granularity (and perhaps subdomain) is what
one has to work with.

For example, walk over to a Windows machine and add "*.google.com" and
"*.gmail.com" to theTrusted Zone; and then try to login to Gmail.
Login will fail because Google routes authentication through YouTube.
For sake of argument, suppose login succeeds. Other Gmail operations
will fail because another domain - googleusercontent.com (or similar)
- is used.

But it might make a good use case: how to handle a certificate to be
used in a particular PKI mapped onto a domain. Make sure the case
includes operations from another domain (in violation of SOP).

Jeff

Received on Tuesday, 2 April 2013 21:17:02 UTC