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

[Adam Barth]

On Tue, Jul 7, 2009 at 6:38 AM, Sandro Magi<naasking at higherlogics.com> wrote:
> Adam Barth wrote:
>> 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.
>
> Yes, but note that Acme need not manage a single powerful token. It
> could manage multiple use-limited tokens, and if some of them expire
> more quickly than others, it can generate new ones and assign specific
> tokens to specific clients to check for abuse, then blacklist those
> clients [1]. Bob will quickly find himself shut down.

How will Acme distinguish between a user who keeps the Acme home page
open for a long time and Bob who farms out the tokens to his clients?
Perhaps Acme's page will ping Acme for each request so Acme can
decrement some internal counter and know when the token is supposed to
expire?

> The point is, Acme has more control with tokens, and tokens solve more
> than just this single case where the incentives just happen to be
> aligned just right [2,3].

The system you describe is much more complex than the CORS way of
addressing this use case, and it's not clear that you've actually
solved the use case.  You've just reduced Acme's proxying overhead by
a factor of N (compared to zero by CORS), and you've also reduced
Bob's proxying overhead by a similar amount.

Adam