Re: Single Trust and Same-Origin Policy v2

Hi Mike and public-tracking!

Thanks for sharing this interesting resource from TPWG. Comments inline below.

> On Mar 25, 2017, at 5:17 AM, Mike O'Neill <michael.oneill@baycloud.com> wrote:
> 
> Hi John,
>  
> The TPWG (Do Not Track group) discussed something which may be useful for this. We have defined a JSON resource at a well-known location (the Tracking Status Resource at ./well-known/dnt) which contains a couple of relevant properties, the “controller” array and the “same-party” array. See https://www.w3.org/TR/tracking-dnt/#status-resource <https://www.w3.org/TR/tracking-dnt/#status-resource>
>  
> The “same-party” property is an array of subresource domain names, each one owned by the same company that manages the parent site. The “controller” property is an array of urls identifying the companies that may be jointly responsible for the site, or more exactly responsible for any personal data collected by the site. This corresponds to the European legal concept of the “Data Controller”, and the property is an array because there can be “Joint” Data Controllers.
>  
> The “same-party” array allow a site to declare the subresource “third-party” domains that may be there but are also managed by it, so if a user agent implements tracking protection procedures, they could be relaxed for these subresources if the user has consented to being tracked by the parent site. An obvious example is yimg.com <http://yimg.com/> managed by Yahoo when the parent site may be yahoo.com <http://yahoo.com/>, oy youtube.com <http://youtube.com/> if the parent is google.com <http://google.com/>.
>  
> We have also discussed in the past cross-referencing procedures where sites would mutually refer to each other using the same-party array, so for example when user consent is given for a domain (using the DNT Consent API)  it can be automatically assigned to same-parties manged by the same controller.

If we are to connect security functionality to these ownership/collaboration statements they have to be cross-referenced. Otherwise oneSite.com <http://onesite.com/> can be compromised, made to claim it owns otherSite.com <http://othersite.com/>, and suddenly otherSite.com <http://othersite.com/> is compromised. Sharing should only allowed if 1) otherSite.com <http://othersite.com/> says it’s owned by oneSite.com <http://onesite.com/> AND 2) oneSite.com <http://onesite.com/> says it owns otherSite.com <http://othersite.com/>. Also, it’s important that a domain can only have one owner. Maybe you’re proposing something similar?

I’m not only interested in this from a tracking or user consent perspective. It seems you will have to have EU legislation to push adoption. Do you agree? Or do you foresee developers deploying and maintaining these files for some other reason?

JSON files in well-known locations are popular these days. But I have entertained the thought of using an extension to X.509 domain certificates to state domain relationships. It would make this kind of multi-domain sharing exclusive to https sites and make it harder for attackers to set up malicious sharing relationships.
   I know certificate information is not really in the web layer but we have something similar today with Subject Alternative Names. One caveat is that you may have multiple certificates and they may end up saying conflicting things.

The SOP v2 I envision helps developers share resources across multiple domains they own. We are aware of examples where sites tell their users to “Allow All” cookies just because they haven’t figured out a way to make single sign-on work with the default cookie policy. That’s bad for the sites and their users. And we constantly see chained HTTP redirects just to set up cookies over domains with the same owner.

   Regards, John

>  
> There may be others in the TPWG interested in the topic so I have copied to the list.
>  
> Mike
>  
>  
>  
>  
> From: wilander@apple.com [mailto:wilander@apple.com] 
> Sent: 25 March 2017 00:20
> To: Bil Corry <bil@corry.biz>
> Cc: public-webappsec@w3.org
> Subject: Re: Single Trust and Same-Origin Policy v2
>  
> Hi Bil!
>  
> Thanks for your comments. Please see inline below.
>  
>> On Mar 24, 2017, at 3:00 PM, Bil Corry <bil@corry.biz <mailto:bil@corry.biz>> wrote:
>>  
>> 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 <http://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 <http://metrics.apple.com/> would not qualify as Single Trust).
>  
> The notion of a party only goes as deep as domain name in this proposal. Which IP address it resolves to is another layer of first and third parties, and out of scope. From a user standpoint, the single trust is in the organization that takes responsibility for requests and responses.
>  
> To be concrete – metrics.example.com <http://metrics.example.com/> would be considered same party as example.com <http://example.com/>, independent of where the domain owner has decided to route the traffic.
> 
> 
>> 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.
>  
> The cutoff is at domain name ownership. The single trust I’m talking about is at the web layer.
> 
> 
>> 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.
>  
> In this case the trustworthy way of doing it is to navigate fully to the payment provider where the user can see who he/she is interacting with, then back. Note that the site owner can site owners can decide not to opt in which means users may decide not to user their services or browsers may not autofill card info.
> 
> 
>> 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.
>  
> This is a potential issue. Yes, my healthcare provider will have to skip third-party DDoS protection the messaging page for if it wants to convey Single Trust.
>  
> I do believe web pages can work without third-party dependencies but let’s keep drilling into these specific security functions that may be harder to achieve with Single Trust. Could they be loaded from the first party?
>  
>    Regards, John
>  
>  
>> On Fri, Mar 24, 2017 at 12:25 PM, John Wilander <wilander@apple.com <mailto: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 <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.
>>> 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