On Apr 22, 2010, at 10:27 AM, Mark S. Miller wrote:
On Wed, Apr 21, 2010 at 11:47 PM, Maciej Stachowiak <m...@apple.com>
wrote:
That being said, I'm totally open to a name that conveys the same
meaning with less perceived ambiguity. I just don't think "Uniform"
is it. It doesn't get across the main idea very well at all. We need
a phrase that says "the browser won't automatically add any
credentials, identifying information or ambient authority".
I think you need to consider the larger anticipated rhetorical
context.
As an API designer, I'm interested in optimizing for programmers
reading and writing the code, not purveyors of rhetoric. I'm not sure
if the statement below is a quote of some existing or proposed spec
text, but certainly the tone is not appropriate to put in a technical
specification.
- Maciej
Something like:
"Browser security is crap. It is based on a bad theory badly
executed. The Same Origin Policy led to a proliferation of ACL
mechanisms in the browser -- four at last count. These endless ACL
epicycles have not yet been adequate to protect us from CSRF and
Clickjacking, so some see the solution in elaborating the SOP with
yet another ACL epicycle, the Origin header.
Fortunately, the original web architecture contains the seeds of its
own success -- the concept for Uniformity, as embraced by the URL
and URI. Extended from designators to the messages sent to those
designators, we get the Uniform Messaging Policy as a simple, clean,
sound, and understandable alternative to the failed Same Origin
Policy.
Messages sent to using the XMLHttpRequest constructor are still
governed by the Same Origin Policy. To escape the madness and use
the Uniform Messaging Policy, use the UniformRequest constructor
instead."
