[cap-talk] Fwd: [cors] TAG request concerning CORS &Next Step(s)

[Adam Barth]

On Mon, Jul 6, 2009 at 11:19 AM, Dave Chizmadia -
Gmail<davechiz at gmail.com> wrote:
> Adam,
>
>> > Wouldn't it be much simpler for this scenario if Google
>> > Finance would provide an API with what Acme Finance
>> > could create and manage proxies at google.com to
>> > delegate to individual users?
>>
>> How would this work without leaking Acme Finance cookies/
>> passwords to Google?  In other words, how could we secure
>> such a system against a malicious data provider?
>
>    I outlined the basic structure of such an API in
> message (albeit, not for the Acme/GoogleFinance problem):
>  http://www.eros-os.org/pipermail/cap-talk/2009-June/012860.html

If I understand this proposal correctly, this requires the browser to
contact Acme.com for each request it wants to send to
finance.google.com.  That kind of defeats the point of talking to
finance.google.com directly from the browser.

>    However, given that the basic concern in the problem
> statement for CORS is accountability rather than one of the
> harder protection concerns (confidentiality, integrity,
> or availability) it would be easier and more consistent
> with existing web architecture to simply use the approach
> I suggest in message
>  http://www.eros-os.org/pipermail/cap-talk/2009-June/012894.html
> I go on to explain the principle of this approach using
> a physical-world analogy in
>  http://www.eros-os.org/pipermail/cap-talk/2009-June/012923.html

If I understand this correctly, this optimized the original design by
a factor of N (the number of requests the token is good for).
Essentially, the browser has to contact acme.com every N requests.
Unfortunately, Bob gets the same N-fold reduction in proxying by just
proxying the N-powerful token instead of the data.

Adam