W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2017

Re: Single Trust and Same-Origin Policy v2

From: Eduardo' Vela\ <evn@google.com>
Date: Fri, 24 Mar 2017 19:36:26 +0000
Message-ID: <CAFswPa-9GLcBvTUnSW6xCPZgOEenfMxc8CRCjDoxW=5EFwryOA@mail.gmail.com>
To: John Wilander <wilander@apple.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Would YouTube.com, and Google.com be same origin? We use domains and
subdomains for isolation, would that go away in your proposal?

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
>
Received on Friday, 24 March 2017 19:37:12 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:22 UTC