On Wed, Dec 16, 2009 at 9:25 PM, Ian Hickson <[email protected]> wrote: > A concrete example of the example I was talking about is Google's Finance > GData API. There's a fixed URL on A (Google's site) that represents my > finance information. There's a site B (my portal page) that is hard-coded > to fetch that data and display it. I'm logged into A, I'm not logged into > B, and I've told A (Google) that it's ok to give B access to my financial > data. Today, this involves a complicated set of bouncing back and forth. > With CORS, it could be done with zero server-side scripting -- the file > could just be statically generated with an HTTP header that grants > permission to my portal to read the page. > > ... > > As a user, in both the finance case and XBL case, I don't want any UI. I > just want it to Work. >
Yet you must go through a UI on site A to tell it that it's OK to give your data to B. Obviously this step cannot be altogether eliminated. What I am suggesting is a slightly different UI which I think would be no more difficult to use, but which would avoid the need to hard-code. In fact, I think my UI is easier for users, because in all likelihood, when you decide "I want site B to access my data from site A", you are probably already on site B at the time. In your UI, you have to navigate back to A in order to grant permission to B (and doesn't that also require copy-pasting the host name?). In my UI, you don't have to leave site B to make the connection, because the browser remembers that site A provided the desired capability and thus can present the option to you directly. The down side is that I don't know how to implement my UI in today's browsers.
