- From: Jochen Eisinger <eisinger@google.com>
- Date: Mon, 27 Mar 2017 18:14:29 +0000
- To: John Wilander <wilander@apple.com>
- Cc: "Mike O'Neill" <michael.oneill@baycloud.com>, Bil Corry <bil@corry.biz>, "public-webappsec@w3.org" <public-webappsec@w3.org>, public-tracking@w3.org
- Message-ID: <CALjhuicFjqGPcLU5k2JwgJX8J=6=PdWr+g7KE=G1eQ9vcTYv-Q@mail.gmail.com>
On Mon, Mar 27, 2017 at 8:11 PM John Wilander <wilander@apple.com> wrote: > Hi Jochen! > > Thanks for your comments .See my reply inline below. > > On Mar 27, 2017, at 1:44 AM, Jochen Eisinger <eisinger@google.com> wrote: > > Hey John, > > thanks for writing this up! > > When reading about the proposal to grant sites from a trust group script > access to each other, I wonder what your thoughts are on how to protect > against XSS bugs spreading from a single domain to an entire group of > origins? It seems that this would go in the opposite direction of > suborigins, i.e., instead of restricting access even more, it's opening up > access. > > > Sharing will be allowed if siteA.com claims to own siteB.com AND siteB.com claims > to be owned by siteA.com. XSS on siteB.com would then have access to > non-sameSite, non-httpOnly cookies from siteA.com so there are > implications to XSS. > However, fully shared scripting capabilities have not been part of my > thoughts. I’m mostly interested in sharing of state and simplified > cross-domain messaging. > With the capabilities to serialize / deserialize wasm binaries into indexed db, this essentially allows for cross domain script, no? I'm also not sure I understand how the cross domain messaging would be more simple than the current postMessage model, could you please elaborate on that? thank you! jochen > > I believe developers would be OK with the state sharing tradeoff, > especially since it’s opt-in. > > Regards, John > > best > -jochen > > On Sat, Mar 25, 2017 at 1:20 PM 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 > > > > 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 managed by Yahoo when the > parent site may be yahoo.com, oy youtube.com if the parent is 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. > > > > 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> 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 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). > > > > 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 would be considered same party as > 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> > 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 Monday, 27 March 2017 18:15:18 UTC