Re: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]

>> You do realise that with XDR, 'resource host' has no means to
>> authenticate the user using (relatively secure) HTTP digest
>> authentication?
>
> I both realize and support XDR's decision to not transmit the user's HTTP 
> auth credentials. These credentials are semantically equivalent to the use 
> of cookies described and attacked in the references cited above.

These attacks have been proven to not be the fault of cookies. Therefore it 
makes sense that auth credentials would also not create such attack vectors.

>
> As an aside, HTTP digest authentication is no more secure than 
> transmission of a plaintext password. The space of user passwords is so 
> small that a brute force attack against a password hash is feasible.

What does this have to do with the HTTP digest authentication? The digest 
authentication provides a secure of way transmitting passwords. You protect 
against brute force attack with attempt limitations, not password 
encryption. If you don't use such measures it doesn't matter you how you 
encrypt your passwords, you will still be prone.

>
>> In order to acquire the desired functionality (for which it needs the
>> user's credentials), with XDR the resource host will most
>> likely end up
>> passing the authentication information along in the GET query string
>> (bad), probably requiring the user to fill in his credentials on the
>> origin site (bad), and sending the user's password plain over
>> the wire
>> (bad).
>
> Since general understanding of application security is so muddled and 
> incomplete, I have no doubt that many developers will choose to have their 
> users give their credentials to third-party sites.

What a depressing outlook for the future. Developers are stupid, so we will 
make sure they can't use real security measures because they are more 
complex. The reality is developers been pushing the limits of what they can 
do securely on the web. Web developers are more than capable of using real 
measures like OAuth to authorization, if they are given adequate mechanism 
for doing so.

>> breaking of REST by disallowing PUT and DELETE and setting the
>> Content-Type and Accept-* headers, while favouring SOAP
>
> I characterize the web-apps that I develop as being RESTful, and don't see 
> any compelling value proposition in the various SOAP related 
> specifications. The XDR proposal adequately supports all of the 
> programming patterns that I find useful in a RESTful web browser 
> application.

Yeah, it seems quite trendy to call your web services RESTful even if you 
never use PUT and DELETE. True read/write RESTful services on the web are 
heavily dependent on PUT and DELETE.

> The XDR proposal does not introduce any new limitations that we must abide 
> by in creating web applications, and so cannot be said to break anything.

It certainly doesn't break anything existing, but it does attempt to take 
allow cross-site communication, such comunication will have fundamental 
semantics broken which could have enabled powerful interoperability.

> That the XDR proposal enables cross-domain requests with minimal 
> complexity and in a way which is unlikely to cause IT administrators to 
> disable the feature, is, in my opinion, reason enough to be enthusiastic. 
> The XDR proposal seems like something that could be a stable platform on 
> which to start building new kinds of applications.

I actually really appreciate the effort to make things more simpler. 
However, I do not understand how creating a new API, and creating a new set 
of headers is going to make things simpler. The code necessary to deal with 
the new APIs is certainly going to impose a burden on developers. If 
simplicity is really goal of IE, why not work with W3C on simplifying the 
current proposal? Most of the differences are completely orthogonal to 
simplicity like header names, and the JS API. One could easily just subset 
the W3C/CS proposal to the level of simplicity of XDR.


Kris

Received on Monday, 14 April 2008 15:36:46 UTC