Re: UMP / CORS: Implementor Interest

On Thu, Apr 22, 2010 at 11:00 AM, Maciej Stachowiak <mjs@apple.com> wrote:

>
> On Apr 22, 2010, at 10:27 AM, Mark S. Miller wrote:
>
> On Wed, Apr 21, 2010 at 11:47 PM, Maciej Stachowiak <mjs@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.
>

I was not suggesting those paragraphs be put in any spec text, or indeed in
any document from the w3c. I completely agree that the tone is
inappropriate. My point is that such text is likely representative of the
discussions that we should expect developers to have (and btw, of points I
will be making in such discussions), so the concept of Uniformity may not
remain as foreign as you are currently assuming.

No matter what term we choose, its meaning will need to be explained to
developers by multiple channels, many of them unofficial and outside the
jurisdiction of the w3c. Outside the w3c, many developers to not consider
yet more of the same business as usual to be an acceptable approach to web
security. They would welcome a simple, sound and understandable alternative.

Within the w3c, by choosing the right terms, we help seed these external
discussions so that the path to saner practices can be more rapidly
appreciated.


>
>  - 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."
>
>
>


-- 
    Cheers,
    --MarkM