Re: Isolate-Me explainer

> On Sep 19, 2016, at 2:38 PM, Artur Janc <aaj@google.com> wrote:
> 
> On Mon, Sep 19, 2016 at 10:55 PM, John Wilander <wilander@apple.com <mailto:wilander@apple.com>> wrote:
> 
>> On Sep 16, 2016, at 8:15 AM, Emily Stark (Dunn) <estark@google.com <mailto:estark@google.com>> wrote:
>> 
>> Hi webappsec! Mike, Joel, and I have been discussing an idea for a developer facing opt-in to allow highly security- or privacy-sensitive sites to be isolated from other origins on the web.
>> 
>> We wrote up the idea here to explain what we're thinking about, why we think it's important, and the major open questions: https://mikewest.github.io/isolation/explainer.html <https://mikewest.github.io/isolation/explainer.html>
>> 
>> Please read and comment/criticize/etc. Thoughts welcome, either here in this thread or as GitHub issues. Especially interested to hear from Mozilla folks as it relates to and is heavily inspired by containers.
> 
> Interesting! This is more or less what we proposed under the name single trust at the face-to-face. I have been asking Mike to bring into Secure Contexts v2. :)
> 
> We believe this would not only be good for site security but could also allow more powerful APIs which is why we thought Secure Contexts is a good fit. You could envision security sensitive features such as auto-fill/auto-login to only be available in single trust.
> 
> Hey John,
> 
> Note that, at least currently, some of the main goals of the proposal deal with preventing the exploitation of common classes of Web vulnerabilities (XSS, CSRF, cross-origin data leaks). These are orthogonal to the issue of single trust, because you can have a "single trust" application that is logically completely self-contained, but on the current web attackers can interact with it by force by navigating to arbitrary endpoints, sending messages (postMessage), setting arbitrary cookies (e.g. with an XSS on an other subdomain or by an HTTP MitM), etc.
> 
> The security gain of Emily's isolation proposal lies in protecting an application from unwanted interactions from the outside, rather than enforcing restrictions on components that the application itself wishes to load. In practice, attacks on webapps generally don't come from such trusted components, and for places where this is a concern there are already other solutions such as SRI or sandbox frames. Because of this, the most promising aspect of the recent isolation proposals (including Mozilla's Containers) is the ability to prevent unrelated, external sites from affecting the state of the protected application -- and personally, I have high hopes for this kind of approach.

That makes it more clear. Thanks!

Then our proposal of single trust stands as is, clearly geared toward “If you want this privileged thing you cannot pull in arbitrary sub resources because the user puts his/her trust in you and you only.” Seems to go well along with site isolation too.

I’d love for all authentication pages to be single trust. Dream scenario being the password input type is only available for single trust pages. :)

   Regards, John

> 
> Cheers,
> -Artur
>  
> Or the ability to talk to localhost as has been discussed here at length.
> 
> The reason we have discussed this as single trust is the academic research done in mixed trust. Browsers only show a green bar/padlock for the top frame domain where in reality there could be a hundred other organizations the user is implicitly trusting through sub resource and sub frame loads and redirects. Hence, mixed trust.
> 
> This naturally leads us to one of the other proposals we brought up at the face to face – associated domains. Under §4. Isolation Policy you bring up the fact that sensitive sites still might want to interact with or include third party content. But such content may not really be from a third party but from a different domain owned by the same organization – an associated domain. The host is simply a poor differentiator of first and third party. If we could come up with a safe way to declare ownership and/or control we could allow associated domains to cooperate while being isolated from the rest of the world.
> 
>    Regards, John

Received on Monday, 19 September 2016 22:05:09 UTC