Re: Single Trust and Same-Origin Policy v2

Hi Mike W!

> On Mar 27, 2017, at 2:49 AM, Mike West <mkwst@google.com> wrote:
> 
> Hey John! Thanks for continuing the conversation!

I know I’ve promised you many times to get this on the list. Sorry for the delay.

> 
> On Fri, Mar 24, 2017 at 8:25 PM, John Wilander <wilander@apple.com <mailto:wilander@apple.com>> wrote:
> # 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.
> 
> As a quick note here (with the caveat that I am _not_ a UX expert), Felt, et al. published "Rethinking Connection Security Indicators <https://www.usenix.org/system/files/conference/soups2016/soups2016-paper-porter-felt.pdf>" at SOUPS last year, and it's a really great read on the topic of security UI. One of their conclusion is that users do not perceive the lack of a "secure" icon as a warning. Accordingly, Chrome is moving to reduce the number of indicators we show to users, and to focus more on indicators of insecurity rather than security. Chrome's current UI is a stepping-stone on the way to dropping the "green lock" indication of security for HTTPS in favor of a "red triangle with an exclamation point" indication of non-security for HTTP at some point in the future. That's a long way of saying that adding new indicators is an uphill struggle that needs solid justification.

I am aware of this research and think it’s great. There is a challenge here for sure.

One way to use Single Trust and avoid new UI is to restrict sensitive APIs or browser functions to single trust pages. That way the user doesn’t have to know anything or make security decisions. Examples of what these restrictions could be: Autofill, Credential Management, file upload, integration with fingerprint readers or other device-specific tokens, and stickiness of granted permissions such as camera access.

> While I can imagine that single-trustness might have some value for a site's developer, I'm not clear about the value it would provide to the site's users. Can you help me understand the decisions you think this would enable?

User trust is an enabler, just like most of security. I believe the web is struggling in the trust space. Single trust, especially with some backing of liability (more on that below), can enable more trustworthy things to be done on the web.
   Today there are various pushes to silo things out of the general web. It happens through native apps or WebViews in native apps. To some extent you see the mistrust in the use of private browsing or incognito mode. On the web there’s this constant worry that “I can’t have this conversation or transaction be between me and this one organization I trust."

> 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.
> 
> Do you imagine single-trust as something users would be exposed to once in a blue moon, when a trust decision really matters (the "confidential news tips" case), or do you want to encourage it to be a pervasive expectation for most sites a user visits?

If there’s a user signal tied to it I assume it would be seldom. But it could be recognizable – “My healthcare provider’s site should look this way.” I know from my work at the bank that recognizing the site is a strong trust signal with users, and it’s the thing that’s exploited in for instance tab napping.

If we just restrict APIs and functions to single trust pages, the user won’t know how often it happens.

>  
> 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 …
> 
> As Bil noted below, the DNS-level carveout means that "belonging to the same organization" can't be a strong guarantee. The name belongs to the organization, but the service being named may well be outsourced. You suggest below that "From a user standpoint, the single trust is in the organization that takes responsibility for requests and responses.", but can you talk a little bit about the ways in which the status quo fails to offer the same guarantee? Isn't an organization that relies on third-party ads "tak[ing] responsibility" for those requests by adding the ad calls and forming a contractual relationship with the provider?
> 
> If single trust gives real advantage to developers, I worry that it will simply devolve into delegating a set of subdomains to a third-party (`ads.example.com <http://ads.example.com/>`, `provider1.ads.example.com <http://provider1.ads.example.com/>`, `provider2.ads.example.com <http://provider2.ads.example.com/>`, and so on). Given revenue concerns, the slope doesn't seem that slippery. :)

This will probably be the case. What I mean by responsibility is liability. Today, third-party requests are bounced through highly dynamic redirect chains. Yes, the site could deploy CSP and get in control of where things are loaded from and that would convey some kind of intent or liability. But every request going to a domain owned by the same entity is much stronger. Example Inc. can’t get away from badness happening from requests made to ads.example.com <http://ads.example.com/>.

Note, I have not gone to Law School so please read the above as layman thoughts. :)

> 
> # 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 <http://apple.com/> and icloud.com <http://icloud.com/> as different as apple.com <http://apple.com/> and europa.eu <http://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.
> Both Google (Smart Lock for Passwords <https://developers.google.com/identity/smartlock-passwords/android/associate-apps-and-sites>) and Apple (Shared Web Credentials <https://developer.apple.com/reference/security/shared_web_credentials>) are shipping ~similar solutions to this problem for the specific case of password managers. Developers are asked to put a file somewhere on their domain that lists a set of origins and apps that are associated with each other, and stored credentials are made available in various ways across those associations.

This has crossed my mind. We should compare!

> Though both end up using their respective app stores as a root of trust, it would be interesting to compare the `assetlinks.json` and `apple-app-site-association` file contents to see if there's a cowpath waiting to be paved here. It's probably also worth looking at past efforts like DBOUND <https://datatracker.ietf.org/wg/dbound/charter/> to see if we can learn anything from their struggles to get something like this defined and shipping.

Yes.
> Seamless integration across domains with one owner, such as messaging between frames and access to storage.
> This worries me a bit. As Eduardo noted earlier, Google uses subdomains explicitly to break the integration between applications living on/under `google.com <http://google.com/>`. I think it's pretty unlikely that Google would opt-into a system that gave `accounts.google.com <http://accounts.google.com/>` script access to `youtube.com <http://youtube.com/>` (and would be even more unlikely to adopt the inverse), for instance.

I never intended script access as in execution in e.g. YouTube’s context. The access I meant was access to state and simplified messaging.

> Do you have some concrete use-cases you'd like to enable here that are difficult in the status quo via `postMessage()`, etc? You suggest that we could make this "much more elegant", but I don't understand how. :)

The cumbersome checking of who to send to and who sent a certain message can be simplified for messages across co-owned domains. The developer wouldn’t have to check them the same way, unless he/she wants to.

> Much better transparency and rules around third-party resources.
> What does this encompass?

Today youtube.com <http://youtube.com/> is considered a third-party on a google.com <http://google.com/> site. That’s simply not true. We’re inflating the third-party numbers and users have no way of learning how many real third-parties are involved in a page load.
   Also, we’re subjecting resources to unnecessary third-party treatment. You probably know about WebKit’s partitioning of third-party localStorage, sessionStorage, IndexedDB, etc. That should not be needed if the two domains have the same owner.

   Regards, John


> 
> Thanks again!
> 
> -mike