Re: Single Trust and Same-Origin Policy v2

OK, thanks John.

I'm afraid that we would be introducing a fourth SOP (cookies,
DOM/document.domain, XHR/CORS) on top of the plugin ones, but otherwise
this sounds like some developers might find it useful.

Do you have any applications that would be made possible thanks to this
that today are too cumbersome? Or what is the motivation for this?

On Fri, Mar 24, 2017, 8:54 PM John Wilander <wilander@apple.com> wrote:

> Hi Eduardo!
>
> On Mar 24, 2017, at 12:36 PM, "Eduardo' Vela\" <Nava>" <evn@google.com> <
> evn@google.com> wrote:
>
> Would YouTube.com, and Google.com be same origin? We use domains and
> subdomains for isolation, would that go away in your proposal?
>
> Two things:
>
> 1. This has to be under the owner’s control, i.e. opt-in. SOP v1 applies
> if you leave things as is. And the opt-in needs to be granular enough to
> cover subdomains and the powers they provide developers.
>
> 2. Domains from the same owner and opted-in would not become same-origin.
> That would create cookie collisions and what not. Instead they get access.
> Imagine an API like this:
> document.shared.cookies[“youtube.com”]
>    How we gate this is to be discussed but the sameSite attribute for
> cookies could be one way to limit crossOriginSameOwner access.
>
>    Regards, John
>
>
>
> On Fri, Mar 24, 2017, 8:27 PM John Wilander <wilander@apple.com> wrote:
>
> Hi WebAppSec!
>
> I’m long overdue sending you details on the discussion we started at the
> face-to-face meeting last spring. Here goes …
>
>
> *# Single Trust*
>
> Users have a few interface signals to decide if they trust a site. There’s
> the URL bar which may show the full URL, the origin, just the host, or the
> name of the organization for sites with EV certificates. The URL bar also
> conveys TLS status with padlocks, warnings, and colors. Recently, Chrome
> and Firefox started to warn about insecure password fields so that’s
> another great signal. Then there's the very subtle mixed passive content
> indicators. I’m sure there’s more.
>
> We argue that in addition to the above, websites should have the ability
> to tell users that only first party resources are involved in a web page.
> We call this Single Trust – pages where there’s just one entity the user
> has to trust. This makes a lot of sense on pages with password fields and
> credit card fields but I personally would also like the inbox and message
> form where I interact with my physician to be single trust. Pages where you
> submit confidential news tips should also be single trust. And single trust
> would be great for pages where I’m supposed to interact through a plugin
> such as a bridge to a smart card reader.
>
> Single trust can currently be achieved through a strict CSP but users have
> no way to tell that a site is under such a policy. Ideally, single trust
> should be possible for multiple domains belonging to the same organization
> which is not possible through CSP alone. This leads us to …
>
>
> *# Same-Origin Policy v2*
>
> Good TLS and the same-origin policy are the cornerstones of web security
> and for a single domain it works just fine. But we end up with tradeoffs
> since the SOP considers apple.com and icloud.com as different as apple.com and
> europa.eu. The most well-known tradeoff is third-party cookies but there
> are tradeoffs for third-party frames, Fetch, workers, and storage. If we
> apply strict rules on third parties we hamper cross-site ecosystems such as
> single sign-on and site integration. If we instead loosen up the rules we
> get cross-site security breakdown and/or third-party tracking.
>
> We would like to discuss how to technically implement a secure SOP v2 that
> takes domain control/ownership into account. This would allow:
>
>    - Seamless single sign-on across domains with one owner.
>    - Seamless integration across domains with one owner, such as
>    messaging between frames and access to storage.
>    - Much better transparency and rules around third-party resources.
>    - Support for cross-domain Single Trust as per the discussion above.
>
>
> Let me know what you think. Thanks!
>
>    Regards, John
>
>