Re: Single Trust and Same-Origin Policy v2

Hi John,

Would a third-party service provider contracted by a first-party be a
first-party resource, or a third-party resource?  For example,
metrics.apple.com appears to a first-party resource for Apple, but points
to Adobe Marketing Cloud, which is a third-party service provider.  My
impression from your description is that only entities owned by the parent
company with resources embedded on the page would be considered "Single
Trust" (thus any Apple page that interacts with metrics.apple.com would not
qualify as Single Trust).

Does it only apply to the HTTP layer?  If I contract with a company to
create, host, and administer my website, is that Single Trust?  Do I have
to build the page/site myself?  Do I have to host it myself?  What is the
difference between paying someone to build and host it for me, and using a
SaaS solution (which is essentially paying someone for building and hosting
a solution for me)?  At some point, a third-party has to be involved
because not many companies operate as a Tier 1 network provider, so I'm
curious where the trust cutoff is at.

I can see where sites may use Single Trust to convey a stricter security
boundary to end users, but in practical terms, it may be less secure in
some instances.  For example, with credit card collection, many sites use
third-party payment providers to avoid handling credit card data directly.
If a merchant that currently uses a payment provider switches to using a
payment gateway, is the customer now more secure having the merchant handle
the credit card information?  The credit card data ends up at the payment
provider either way, but now the merchant is also handling it.

Another example is any security control provided via a SaaS model - do I
stop using CloudFlare to protect against DDoS so my page can be Single
Trust?  Do I stop using reCAPTCHA as a velocity control so my page can be
Single Trust?  Do I not embed anti-fraud controls into the page so it can
be Single Trust?  Those controls provide value for end users, yet the
Single Trust indicator would be off for those pages, making it appear
otherwise.


Thanks,

- Bil

On Fri, Mar 24, 2017 at 12:25 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
>