Every discussion of the security architecture of the web platform should begin with the notion of an origin. An origin is the basic unit of isolation in the web platform. Every object in the browser is associated with an origin, which defines its security context. When a script running in one origin tries to access an object, the browser checks whether the script's origin has access to the object's origin.
So what is an origin? Simply put, an origin is the scheme, host, and port of the URL associated with the object. (Hence the name of this blog.) For example, if you're viewing an article on New York Times in your browser, that article (and all of its associated objects) are in the http://www.nytimes.com origin. This blog exists in the http://www.schemehostport.com origin, which means there is a security boundary between this blog and the New York Times. Of course, there are many subtleties to that security boundary, which we'll get to in due course.
Many folks have written about the browser's origin-based security model, which is often referred to as the same-origin policy because, in the usual case, the browser allows one object to access another if the two objects are in "the same" origin.
If you'd like to learn more about the same-origin policy, one popular reference is Jesse Ruderman's wiki page, but, despite origin's central role in web security, there isn't a specification explaining how the same-origin policy works! To fix that, I've been working with the IETF's websec working group to write a specification of the web origin concept. There are still a handful of issues to address, but hopefully finish working through the IETF process soon.