Current browser security models rely on users' trust of the origin domain6, which is serving the content to the client browser, and rely on requiring the origin domain to be the same for both executable content and the displayed document. In other words, the user trusts the domain that is the source of the page, and so executable content is only allowed from that source1.
Other than Man-in-the-middle attack, this model remains secure as long as the computer, which is serving for the trusted domain, remains secure and trustable. This works as a free-market mechanism, as domains can compete on their ability to remain secure and build trust among users. However, this does encourage centralization of trust (the antithesis of a freely efficient market), as security threats always do in society. Centralization and socialism ("to each according to his needs, from each according to his abilities") are synonymous. Centralization of trust (increasing mass) encourages corruption or at least non-optimal dispersal of decision power5, which is ultimately the antithesis of trust. In other words, trust's reliability declines with distance, time, and mass.
This dichotomy is the antithesis of trust, which is the psychology of fear that causes the centralization of trust.
The solution to this dichotomy, is the same as the solution to another gaping hole in the current security model. And the same solution will also mitigate phishing and other psychology-of-trust attacks.
Currently in all browsers, the 'src' attribute in content tags2, e.g. <img> and <script>, can access executable content from any domain, thus rendering the current browser security model impotent and void. This is unlikely to be changed (hallelujah!), as cross-domain content is fundamental to web interoperability, and the entire web advertising industry infrastructure depends on cross-domain scripting capability. Cross-domain scripting capability is essential to scaling of the next wave of massively interconnected, distributed Web 2.0 and Web 3.0 applications, without hourglass-like funneling through centralized proxies of huge server farms (hydropower centralized) to retard the exponential evolution of web interconnectedness5.
The conflation of users' private data with public content is the root flaw in the current security model, which drives the dichotomies above. Thus, the solution is that trust should be granular on the data type, not the source.
If the user associates his trust with some statistically unguessable (cryptographically secure) key instead of associating trust with a domain, and only enters private data when shown that key, then the key replaces the domain as the granularity of trust. It really is that simple3. The key could even be an image (e.g. of yourself, your dog, etc) such as Yahoo's Sign-in Seal4.
The only trustable web page is the one where all referents (resources) come from a trusted source. Security is fundamentally trust. Increasing granularity of trust, decreases security conflicts.
1 Read-only content accessed with a URI, writes data to the source, in the non-domain portion of the URI. Thus, any proposal to provide security for cross-domain executables by restricting untrusted executables to read-only cross-domain content access, would open a hole in the trusted domain security model.
2 Off-topic from security, note that such content is cached more reliably by more browsers than XMLHttpRequest, but has other Pros and Cons. Also, XMLHttpRequest is currently not cross-domain capable.
3 To display or acquire private data, modularly firewall the task into a sub-frame of the page which is loaded from a different domain, where the page in the sub-frame references no cross-domain content. Cross-domain content on the page containing the sub-frame, will not be able to access the content of the sub-frame, due to current browser Same Origin cross-frame policy. The use of Same Origin inter-frame firewall policy, does not degenerate the trust granularity, because the domain is only trusted if it shows the user the key. Then the current cross-domain limitation on XMLHttpRequest2, is no longer necessary.
4 Doesn't appear that Yahoo's Sign-in Seal and private data <form> are currently being firewalled in a sub-frame from a different domain3, so it is not currently implementing the solution described in this page.
5 Math of Theory of Mass-Entropy Equivalence states that knowledge increases as disorder (entropy) increases and mass breaks down into more N independent (and NxN - 2 / 2 interconnections between) entities. Although the physical internet is a Scale-free network topology, the virtual network of knowledge interconnections (e.g. URIs) need not be so limited.
6 Origin domain in this context means the hostname, port, and protocol.
Created: May 15, 2008
Last Updated: May 30, 2008