Re: Chromium's support for CORS and UMP

Dirk Pranke wrote:
> Hi all,
> 
> A couple weeks back there was a question as to implementor support for
> UMP and CORS, and that ended up launching a longish thread on the
> chromium-dev mailing list [1].
> 
> Tyler Close has asked me to summarize the conclusions of that thread
> here, so ...
> 
> 1) CORS is already implemented and shipping in WebKit, so Chromium
> supports CORS and will continue to do so for the foreseeable future.
> 
> 2) We (the Chromium team) are curious as to what CORS is being used
> for - we don't have a lot of real-world examples, and so we may end up
> instrumenting the dev channels of Chromium to see if we can actually
> figure this out [2].

Been covering this today on www-tag; the short version is that the shift 
to sem-web, linked data, opengraph, rdfa, microformats, opendata means 
that increasingly we need JS access to public resources - yet don't have 
it, so I think the users of the aforementioned techs are all going to 
have to jump in to CORS (very, very sadly)

http://lists.w3.org/Archives/Public/www-tag/2010May/0015.html

Personally, I don't follow why JS running in a user agent should have 
completely different access rules to the rest of the web, primarily 
because a few site admin's feel it's a good idea to expose sensitive 
data via IP-based auth on intranets / on the web via stateful sessions 
on a stateless protocol.

It troubles me tremendously to realise that we have a virtually 
universal web application language (JS) on billions of web enabled 
machines, running inside a web browser, yet it doesn't have access to 
the web - (???!!) I've published my data publicly, why has it been 
dictated that in the context of JS only, where it's needed most, it's 
not public?

It troubles me even more to realise I'm just one little voice that will 
have ~0 impact on such a huge issue - and am probably wasting char's.

Best,

Nathan

> 3) UMP appears to be nearly a subset of CORS, and does have a lot of
> nice properties for security and simplicity. We support UMP and would
> like to see the syntax continue to be unified with CORS so that it is
> in fact a subset (I believe this is already happening). We also
> (mostly) support UMP being a separate spec so that web authors can
> read it without being bogged down by the additional complexity CORS
> offers. If there is a good editorial way to handle this in a single
> spec, that would probably be fine.
> 
> 3) We acknowledge that CORS can fall prey to confused-deputy style
> attacks, although they can be mitigated, as Maciej demonstrated a few
> months ago. However, it appears that there are certain use cases for
> CORS that are safe that can be easily deployed, and it is unclear if a
> UMP-style solution will be as easy to use for web authors.
> Accordingly, we are reluctant to remove support for CORS altogether
> until we can better answer (2). Assuming (2) shows that people are using
> CORS, then, for compatibility reasons, we will not really be in a position to
> disable it.
> 
> Thanks,
> 
> -- Dirk
> 
> [1] http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/4ffa158e71ec4613/5751f9bed8fe7128?lnk=gst&q=Implementor+interest+in+a+W3C+WebApps+proposal#5751f9bed8fe7128
> 
> [2] I am referring to the usage statistics we gather on an opt-in
> basis, as documented here:
> http://www.google.com/support/chrome/bin/answer.py?answer=96817&hl=en-US
> 
> 
>

Received on Monday, 10 May 2010 23:55:39 UTC