Re: CfC: CORS to advance to Last Call

On Tue, Dec 20, 2011 at 6:26 PM, Thomas Roessler <tlr@w3.org> wrote:
> On 2011-12-20, at 16:44 +0100, Jonathan A Rees wrote:
>
>> If so then one could imagine that a user who came to believe
>> full CORS was too risky would be given the option, in a browser
>> configuration panel, to turn off full CORS while retaining the UMP
>> subset. Or that a browser provider interested in protecting users
>> might make the same decision categorically. (I know, it's a
>> stretch...)
>
> Copying the chairs of webappsec; not sure they're following the discussion on www-tag.
>
> Brad, Ekr -- thread starts here:
>        http://lists.w3.org/Archives/Public/www-tag/2011Dec/0091.html
>
>
> I wanted to make two high-level points:
>
> 1. The choice of security policy in the browser is an important choice, but it's not just the user's.  CORS and UMP hiding behind the very same API, and applications being unable to predict which is which, is a recipe for web applications breaking in inscrutable ways.  That'll lead to a very nasty mix of functionality and security breakages.
>
>
> 2. Some very smart people have been arguing back and forth about CORS v. UMP for a long time now.  (But note that the current version of CORS seems to have a lot of buy-in from the industry, and I haven't seen any interest in pushing UMP forward lately...)
>
> You don't seriously believe that exposing that choice in a browser setting even approximates something like a good idea, right?

Approximately 30% of what I write on www-tag is tongue in cheek to at
least some extent. I try to have fun with this standards business,
since otherwise it can become rather dismal.

The number of people who would understand such a control, and
therefore be able to use it correctly, is approximately zero. Of those
who would understand it, probably 100% would choose a different way to
safeguard themselves (if they felt one was needed), such as turning
off Javascript. So you are right, such a control would be pointless.

I don't think "industry is clamoring for it" is a very good criterion
for judging attempts to protect users' interests. For the most part
industry, like most people most of the time, only cares about
functionality, and security mostly just gets in the way of getting
things done. (Yes, that was flippant.)

Historically I suppose security holes are plugged as attacks
exploiting them mount. I'm just trying to put a positive spin on the
CORS/UMP situation by saying that the ground to which the community
would have to retreat if confused deputy attacks start being a problem
will already be there if there's a UMP option built in (as I think it
is), so deploying a defense would only require removing the
CORS-proper part, not the creation a whole new mechanism.

Jonathan

Received on Wednesday, 21 December 2011 01:06:53 UTC