A few days ago, intrigued by a comment by pes10k, I sought to propose suborigins as a privacy feature to privacycg. But the idea did not gain the needed momentum—it failed to get buy-in from site owners or web browsers (for it is hard to implement and the current situation is not as bad as I thought it was)—so I abandoned it. I am pasting the last draft of the idea below for posterity’s sake.
But, first, I would like to thank everyone who helped me through this process, it was an incredible learning experience and I come out having a much more rooted understanding of how web privacy standards work and how the web works in general. :D
Building on a comment by pes10k on the first-party sets TAG review, I would like to propose looking into Suborigins (currently a webappsec draft) as an alternative to first-party sets-type ideas, in the long run.
Setting the Scene
Right now, cross-origin attacks (like XSS) cause web applications to split functionality over multiple host names and leverage security mechanisms like the same-origin policy to effectively sandbox sub-functionalities. This has the unintended privacy implication of people trusting multiple entities, breaking a user expectation John Wilander has termed “Single Trust” where the user only expects to trust the first-party. The first-party sets proposal and the Same-Origin Policy v2 idea aim to redress this issue by redefining the notion of a first-party to match our intuition (for instance,
icloud.com should be treated as the same entity.) Suborigins proposes an alternate world where, rather than relax the notion of first party, we allow for a finer-grained view of origins, in particular allow for
example.com/usercontent/ to be treated as different origins in the context of security policies like the same-origin policy, so web applications can consolidate themselves to fewer origins, and work on webAPIs (like the storage access API) to facilitate cross-origin communication when needed. This allows for a visible broadening of the privacy boundary while keeping the security boundaries contained. From a privacy design perspective, I feel it is easier to relax ideas like suborigins (to achieve the required functionality) than constrain ideas like first-party sets (to achieve the required privacy).
In addition, as Devdatta Akhawe’s LocoMocoSec talk points out, suborigins also leads to better SEO and phishing resistance (where the user can expect to only trust this one domain, reducing confusion.)
- Upholds the current privacy protections on the web.
- Does not break user expectations about first-parties.
- Does not require any additional trust infrastructure.
- As krgovind pointed out in reponse to pes10k’s comment that initiated this post, suborigins cannot replace first-party sets-type ideas in the short run, for it requires a lot of work from site owners to leverage this paradigm if they currently use multiple origins in their web applications.
- As dveditz pointed out on #security:mozilla.org, site owners may want to keep separate domains for marketing reasons, like keep
google.comseparate. (Like pes10k in the thread, I think this is a feature and not a bug where if you want to keep
google.comseparate, you cannot get consentless data sharing.)
- As dveditz also pointed out on #security:mozilla.org, if sites upgrade to suborigins (from multiple domains) before browsers do, then users are suseptible to security (and privacy) attacks.
- The suborigins spec is not complete, there still seem to be a lot of open questions and TODOs that need to be fixed by creating and experimenting with real-world implementations.
- Implementing suborigins might be hard. See, also, the comments by dveditz on how one might implement this in Firefox.