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

[Dave Chizmadia - Gmail]

Adam,

> 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.

    You don't understand the proposal correctly, but that 
may be because of my unstated assumption that the actual
accesses to finance.google.com are being generated by 
Javascript code in the form of the stockTicker widget.

    With that assumption clarified, the short story is that
Acme calls upon finance.google.com **once** - before it
responds to the browser's request - to request a single use
Javascript library instance that will be unique to that
browser. Finance.google returns an (unguessable) URL that
Acme then inserts into a load statement in the stockTicker
Javascript code before sending it to the browser. During 
stockTicket initialization, the browser loads its unique 
instance of the finance.google API library and then merrily
starts doing its thing - with no additional contact with
Acme.

    Since the unique library instance was requested by Acme,
all use of that instance is charged to Acme. To provide a
slight additional level of protection, finance.google could
introduce a policy to only repond to calls on the unique
library instance URLs from a single IP address. This would
prevent Bob from getting a unique library instance from Acme
and then passing out to Bob's clients. Another attack would 
have Bob calling Acme for each of its clients to get a unique 
library instance to pass onto Bob's clients, but Acme could 
mitigate this by monitoring the IP addresses from which 
requests are coming and blacklisting any IP address that 
makes "too many" calls for Acme's comfort.

> >    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.

    This is actually a completely different design, since it isn't 
necessarily a token to a unique library instance, but could be 
access directly to a data retrieval feed. But it does have the 
weakness that you identify in the last sentence - though it will 
require that Bob go fetch the new promise after N uses by 
(nominally) N-1 different browsers that have retrieved the token 
from Acme (or Bob).

-DMC